研究项目
如何从测试的角度来研究项目和团队
项目团队
软件项目的主体是项目团队，他们创造了令人赞叹的功能，也引入了让人恼怒的缺陷。团队的人员构成，组织结构，运作机制将深远地影响软件的质量
主动了解项目团队的使命，目标和运作方式
可以通过调查以下问题来获得答案
大型项目往往由多个团队共同完成，测试人员需要掌握团队之间的协作关系
- 测试人员所处的项目团队负责哪些工作？
- 当前团队有哪些伙伴团队？哪些是上游团队？哪些是下游团队？
- 当前团队与伙伴团队有哪些具体的依赖关系？
- 相互依赖的团队如何协同工作？他们对于合作的内容和方式有哪些共识？
- 对于测试人员，他需要为哪些团队提供哪些服务？其他团队又会通过什么方式向他提供支持？
测试人员应该掌握团队的人员组成和角色职责
- 不同角色的职责
- 不同角色如何协同工作
- 如何解决分歧
- 其他角色对测试人员的测试服务有何期望
测试人员需要了解项目的组织流程
- 如何决定项目流程和规则？如何评估项目进度并拟定项目计划？在此过程中，测试人员可以提供哪些信息和建议？
- 项目团队如何定义“工作完成”？如何定义“测试完成”？
- 项目团队如何决定产品可以发布？其中，测试人员需要为发布决策提供哪些信息？
哪些渠道来收集信息
- 向资深测试人员或测试经理询问团队组织的问题
- 日常工作中向团队成员请教
- 通过工作实践来获得答案
语境独立的启发式问题
语境独立是指这些问题不局限于特定的软件项目，所谓启发式是指它们有助于挖掘信息，但需要测试人员批判性地思考。context free question mindmap
上面问题的动机是揭示语境，即通过调查具体问题来更全面地了解项目环境和团队组织。通过研究这些问题将帮助测试人员更好地体会他的环境和使命
了解团队成员
迈尔斯-布里格斯性格分类法 MBTI (Myers-Briggs Type Indicator)
借用此方法的4个基本问题，来分析同事的工作风格，从而以恰当的方式与之合作
问题1： 在使用心理能量时，他是“外向”还是“内向”？
- 外向型的人偏向于从外部获得能量，从讨论和互动中获得力量。测试人员可以考虑和外向型的同事当面交谈
- 内向型的人偏向于从内部获得能量，从思考和冥想中获得力量。测试人员应该用“信任并检验”的风格。首先，相信他们会利用安静的时间独自解决问题，然后，定期与他们面对面交流，同步彼此的进度，讨论一些需要协作才能解决的问题。
问题2：在认识外在世界的时，他是依赖“感觉”还是“直觉”？
- 感觉型的人偏向于“眼见为实，耳听为凭”，更多的用五官来认识世界。测试人员在交流之前应该准备好数据，图标和事实，用翔实的信息来推动讨论
- 直觉型的人偏向于使用直觉，用大脑中的非显性知识来分析具体问题。测试不但要收集事实，还要思考它们背后的理论，并给出自己的见解
问题3： 在作出决定时，他利用“思考”还是“感觉”？
- 思考型的人在作决策时，重视合理性，逻辑性，通过理性思维来得出结论。在说服他们时，测试人员需要严密地论证，用坚实的推理来构建证据链，从而让结论显得自然而合理
- 感觉型的人在作决策时，重视问题的情景，考虑相关人员的感受，并关注解决方法是否协调一致和拥有共识。在说服他们时，测试人员要使论证“合理”，还要让结果“合情”
问题4： 在处事风格上，他是“决断”还是“体察”？
- 决断型的人偏向于“快刀暂乱麻”，快速作出决定，持续推动软件高速发展，但是也引入了错误决策的风险。测试人员需要慎重思考他们的决定，发觉其中的问题和风险，其目标是确保项目团队对这些问题进行了足够的研究，并为相关风险制定了监控和缓解方案。
-
体察性的人偏向于“循序渐进”，将重大决策延后，等到拥有足够的信息再做决定。风险是不能高速地切入新领域或提出新方案，从而错失大幅度提供竞争力的机会。为此，测试人员需要密切关注项目和市场的发展，在必须时提出自己的意见，以推动项目发展。
- 人是复杂的，上面都是启发式问题，它们可以提供有参考价值的信息，但是无法承诺完美的答案。
面向测试的项目分析
分析对象：软件缺陷，源代码，构建和自动化测试。
软件缺陷
测试人员将缺陷管理系统视作项目的知识库，坚持每天或每周阅读他人提交的缺陷报告。在阅读时，他可以使用一些度量方法来分析近期提交的缺陷，以一览缺陷慨况，并为深入研究提供线索.
如果项目有专门的缺陷管理系统，还用了关系型数据库来存储缺陷报告，我们可以使用SQL来分析缺陷数据。 我们通过一些度量来进行分析：
- 统计缺陷提交，解决和关闭的数目
- 统计员工提交，解决和关闭的数目
- 统计每个模块的新增缺陷数, 许多时候，发现缺陷较多的模块还隐藏了不少尚未发现的缺陷
- 统计缺陷解决方案的分布, 比如不能重现的缺陷报告很多，意味着测试手段和缺陷报告存在改进的空间
这些度量值只反应了产品缺陷和团队工作的一小部分信息。为了获得更透彻的理解，测试人员需要仔细阅读缺陷报告，挖掘典型缺陷，测试策略和项目风险，并将研究成果分享给团队成员。
源代码
研究源代码的思路仍是用简单的度量获得代码的基本信息，再通过阅读代码去产生测试想法。
我们可以写一个脚本去分析当前目录以及其子目录下的所有代码源文件，并输出文件目录，文件名，文件行数和代码复杂度到控制台 代码复杂性的度量方法是：文件的复杂度=文件中分支与循环关键字的个数 / 文件的行数
分支与循环关键字：if else for while
Folder File LineCount Complexity
\src\A A.java 191 0.34
\src\A Aa.java 211 0.25
\src\B B.java 60 0.18
基于这样的结果表格，复杂度高的文件往往包含了复杂的逻辑，在代码修改的过程中更可能引入缺陷。因此测试人员可以浏览这些高复杂度的文件，了解它们的功能，并构思相应的测试用例
构建
源代码和构建是软件研发的工作核心，测试人员应该了解代码签入和构建的规章流程
问题
- 签入之前，产品代码需要满足什么要求？程序员需要做什么工作？测试人员需要做什么工作？
- 如果签入的代码导致构建失败，构建服务器会如何处理？谁会负责修复构建？
- 构建服务器产生新构建需要多长时间？
- 产品团队有时需要发布一个紧急的产品补丁或快速修复线上系统的缺陷。对于此类重要且紧迫的代码修改，项目团队制定了什么流程？也许，在代码签入之前，测试人员需要测试程序员提供的私有构建。
对此，测试完成的标准是什么？在签入之后，测试人员需要检验新的构建确实包含预期的修复。对此，测试完成的标准是什么？
自动化测试
问题 自动化测试的反馈频率如何？ 自动化测试拥有哪几个测试集合？
例如，一些测试小组会根据测试的性质，将测试用例划分为：BVT集合，基本功能测试集合，完整功能测试集合，性能测试集合。 每个测试集合以什么频率运行？每次运行需要多长时间？例如，在某个测试小组中，BVT每天运行多次20分钟，基本功能测试集合每天运行1次1小时，完整功能测试集合每周运行一次4小时, 性能测试集合每2周运行一次4小时
调查以上问题的目的是优化测试集合，使高频率运行的测试集合用较短的时间发现严重的缺陷，使低频率运行的测试集合用较充裕的时间发现余下的缺陷。测试人员应该检查自己的测试用例，将重要的用例移入高频率的测试集合，将不太重要的用例移入低频率的测试集合
自动化测试覆盖了哪些测试点？没有覆盖哪些测试点？
测试人员应该定期检查自己负责的自动化测试，以评估他们覆盖了哪些需求，功能，质量特性，用户场景等测试点。
有哪些测试用例需要重构？有哪些测试用例可以退役？
测试人员应该定期检查自动化测试的结果，以发现那些失败率特别高的测试用例，并分析失败的原因。许多时候，测试用例经常失败是因为测试代码不够健壮，不能够妥善处理产品运行过程中的种种情况，测试人员应该严肃对待不良测试代码，尽可能将其重构为稳健的代码。
随着产品的发展，有些测试用例的逻辑已经不能反映当前产品的状态，属于过时的测试代码。还有一些测试用例的检查逻辑已经被其他测试用例所实现，属于“冗余的”测试用例。为了提高测试集合的运行速度和稳定性，测试人员可以考虑让这些测试用例退役
除了定期运行的自动化测试，还有哪些测试工具？
除了自动化测试用例，项目团队会拥有一批实用工具来帮助特定的任务比如配置环境，部署产品，运行测试，调试诊断等。测试人员应该了解团队的测试工具及其用途。
基于风险的测试
对于产品，风险就是产品可能遭遇的失败。基于风险的测试是针对特定风险设计并运行测试，以暴露导致项目失败的问题
