8.1项目团队
语境驱动测试认为“人，团队协作，是项目语境中最重要的部分”。测试人员需要了解项目团队的成员，并知晓团队的运作方式。只有如此，测试人员才能有效地运用测试资源，为团队提供高质量的测试服务。
8.1.1了解团队组织
大型项目往往由多个团队共同完成，测试人员需要掌握团队之间的协作关系。测试人员应该掌握团队的人员组成和角色职责。测试人员需要了解项目的组织流程。测试人员应该知晓测试小组的组织流程。
应该从多个渠道收集信息，如下：
首先，他应该向测试经理询问团队组织的问题。其次，他可以在日常工作中向团队成员请教。更重要的是，他应该通过工作来获得答案。
8.1.2语境独立的启发式问题
一组语境独立的启发式问题。所谓
语境独立是指这些问题不局限于特定的软件项目；所谓
启发式是指它们有助于挖掘信息，但需要测试人员
评判性地思考。
8.1.3了解团队成员
人是项目语境中最重要的部分，测试人员需要了解与他一起工作的同事，才能有效地协作、自如地发挥。研究
人类性格和思维习惯模式的方法有很多。其中迈尔斯-布里格斯性格分析法是一种著名的性格测试方法。测试人员可以借用性格分析法的4个基本问题，来分析同事的风格，从而以恰当的方式与之合作。
问题1：在使用心理能量时，他是
外向还是内向？
问题2：在认识外在世界时，他是依赖
感觉还是直觉？
问题3：在作出决定时，他利用
思考还是感觉？
问题4：在处事风格上，他是
决断还是体察？
8.2面向测试的项目分析
8.2.1软件缺陷
坚持每天或每周
阅读他人提交的缺陷报告。可以使用
度量方法来分析缺陷状况，并为深入研究提供
线索。
度量1：统计缺陷提交、解决和关闭的数目
度量2：统计员工提交、解决和关闭的缺陷数目
度量3：统计每个模块的新增缺陷数
度量4：统计缺陷解决方案的分布
可以从不同角度分析已提交的缺陷报告，可为进一步的技术调查提供线索。
8.2.2源代码
研究源代码的基本思路仍是用
简单的
度量获得代码的基本信息，再通过代码阅读去产生测试
想法。
测试人员可以定期
运行代码
度量，以持续
监控代码的变化。通过比较当前的度量值和之前的度量值，他可以
识别出代码行数和复杂度增幅较大的文件与目录。基于该信息，他会
调查代码变动的原因，并
评估风险。这为及时
调整测试重点提供了支持。
8.2.3构建
大多数团队都部署了专门的
构建服务器，实施持续的自动化构建。因为
源代码和构建是软件研发的工作核心。测试人员应该了解代码签入的构建的规章流程，从而更好地为项目团队服务。
首先需要了解基本流程，之后测试人员可以考虑如何利用源代码服务器和构建服务器为测试服务。
8.2.4自动化测试
许多团队都使用自动化测试来检查构建的质量，典型的工作流程如下：
1、
构建系统生成新的构建，然后通知自动化测试系统；
2、自动化测试系统
配置测试
环境，并部署新构建；
3、自动化测试系统从自动化测试仓库获得
BVT集合；
4、自动化测试系统
运行测试集合，并将结果存入测试结果仓库；
5、如果BVT结果显示新构建质量良好，可以进一步测试，自动化测试系统获得
其他可用的测试集合；
6、自动化测试系统
运行测试集合，并将结果存入测试结果仓库。
为了更好的维护测试用例集合，测试人员应该
周期性地调查几个基本问题，并根据调查结果制定相应的
行动方案。
问题1：自动化测试的反馈
频率如何？
需要调查几个问题，如自动化测试拥有哪几个测试
集合？每个测试集合以什么
频率运行？每次运行多长
时间？在自己负责的测试用例中，哪些应该以
更高的频率运行？哪些可以以
较低的频率运行？
问题2：自动化测试
覆盖了哪些测试点？没有覆盖哪些测试点？
常见的测试方案：补充自动化测试用例以提高测试
效率；补充自动化测试用例以提高测试
能力；补充自动化测试以弥补测试
漏洞；补充手工测试或半自动化测试以确保在产品发布前测试相关
内容。
问题3：有哪些测试用例需要
重构？有哪些测试用例可以
退役？
测试人员应该严肃对待不良测试代码，尽可能将其重构为稳健的代码。在不显著降低覆盖率的情况下，一个稳定且快速的测试用例集要明显优于一个缓慢且脆弱的测试用例集。
问题4：除了定期运行的自动化测试，还有哪些
测试用例和测试工具？
他们通常切合软件产品或技术平台的特征，能够帮助测试人员高效地完成配置环境、部署产品、运行测试、调试诊断等任务。有些工具虽不常用，但对于解决特定类型的问题，是不可或缺的利器。
8.3基于风险的测试
聚焦风险是一种基本的测试策略，而风险是大多数测试活动需要考虑的基本元素。基于风险的测试是针对特定风险设计并运行测试，以暴露导致项目失败的问题。
8.3.1通过测试
调查风险
测试人员在考虑测试活动的优先级时，要分析相应风险的暴露概率和损失大小：风险暴露的
概率和风险暴露的
损失。
风险测试的主要任务是分析项目风险，然后设计相应的测试来暴露失败。这并不是一个线性的过程，它是随着项目进展而迭代展开的。测试人员应该通过风险测试去迭代地评估风险的概率、损失和优先级。
8.3.2
失败模式
风险列表是测试设计的重要参考，它记载了产品可能存在的问题。其核心是描述产品失败方式的失败模式，它刻画了失败的情景和特征。
快速测试是一种典型的基于风险的测试技术，它由一组测试想法构成，每个测试想法都针对某个风险。
测试专家Cem kaner认为失败模式是一种
通用的风险测试技术，可以有效地产生大量的测试
想法。为此，他提供了一组问题，帮助测试人员发掘失败模式。
针对产品的每个模块或功能，测试人员思考其失败模式和测试方法：
该功能可能会触发哪些失败，即包含哪些失败模式？对于特定的失败，它具有哪些外部特征？如何检测该失败？检测该失败需要多少测试资源？
在获得失败模式后，测试人员可以评估其影响，即执行影响分析：
该失败可能有哪些影响？其影响包含哪些变化因素？该失败的最重损失是什么？平均损失是什么？修复导致该失败的缺陷需要多少资源？综合考虑失败损失和检测失败的成本，该失败模式值得被测试吗？
利用以上问题，测试人员可以获得初始的失败模式列表。也可以参考其他测试文档，补充更多失败模式和测试想法。
随后，测试人员将失败模式列表作为风险列表，用来指导风险测试。设计并执行具体的测试来发掘缺陷，在此过程中，他不但会发现新的软件缺陷，还会学习到新的业务知识、产品知识和技术知识。
经过短回路的反复锤炼，在项目结束时，测试人员可以获得一份针对当前领域和产品的失败模式列表。不但是测试计划的重要参考，还是很好的培训资料。
阅读它，测试小组新成员能够了解产品特征，实施快速测试，通过测试，他们可以更好学习产品，初步体会当前领域的主要风险。
8.3.3
项目级别的风险
除了软件缺陷，测试人员还需要考虑项目级别的风险。
在项目之初，根据该列表研究项目和团队，分析出值得持续监控的风险，并将相应的测试想法写入测试计划。在项目过程中，他需要持续监控项目的风险，并适时地调整风险列表和测试策略。
8.4小结
如何从测试的角度来研究项目和团队，介绍了一些实践方法。
测试人员应该主动了解项目团队的使命、目标和运作方式。
研究项目团队的最佳方法是执行具体的测试任务，并积极地咨询和反思。
使用语境独立的启发式问题可以多角度地研究项目语境。
人，在一起工作的人，是项目语境中最重要的部分。
为了更好地与同事协作，测试人员需要了解他们的思考风格。
积极主动的讨论是良好协作的基础。
从软件缺陷、源代码、构建、自动化测试等项目元素中，能够获得许多有益的测试信息。
利用简单的度量就可以获得许多有价值的情报。
基于风险的测试针对项目风险设计并运行测试 ，以发掘可能存在的问题。
测试本身就是风险分析，它是一个迭代过程。
在测试实践中积累失败模式可以帮助测试小组更好地测试。
测试人员有责任监控和报告项目级别风险。