前言
Google所提供的开源Web应用可以分析项目信息，包括测试用例、代码变更、产品缺陷等，以确定Capabilities矩阵中的高风险区域。下图引用自James Whittaker在GTAC 2010的闭幕演讲的幻灯片，是Chrome OS的Capabilities矩阵的热点图（heap map）。图中绿色表示低风险区域，红色表示高风险区域，粉红色和橙色则表示风险居于前两者之间。测试人员可以根据热点图，更好地确定测试优先级，将有限的资源运用在最需要的地方。
风险分析
影响软件风险的因素有很多，试图精确、定量的计算风险可能比降低风险还有困难。但软件风险基本在于“失败频率”和“影响”两个重要因素。 比如： 影响 那些事件需要担心？ 一旦发生，对产品、公司、客户有多大影响？处理这些失败的成本多大？ 失败频率 那些区域容易出现问题？ 相同问题在持续构建时，是否重复出现？
许多团队的风险分析依赖于测试人员的经验和猜测，Google的ACC工具则通过分析项目元素（测试用例、代码变更、产品缺陷等）来识别风险。这些被分析的元素位于HTSM->Project Environment，是项目环境的一部分。即便不使用Google的工具，测试人员也可以利用电子表格记录Capabilities矩阵，并自行计算各个条目的风险（一些Google的测试人员也是这么做的）。在评估风险时，他可以考虑如下因素：
- 自动化测试用例：该区域有自动化测试用例吗？测试在定期运行吗？测试通过率是多少？测试用例覆盖了哪些方面，没有覆盖哪些方面？
- 手动测试：有人手动测试该区域吗？经过测试，他们对该区域有信心吗？如果满分是10分，他们会打几分？
- 代码变更：该区域近期存在代码变更吗？变更频繁吗？变更是新增功能、代码重构、还是缺陷修复？
- 代码复杂度：代码的规模是多少？代码是否复杂？如果复杂度的满分是10分，该区域的代码能得几分？
- 产品缺陷：该区域的缺陷多吗？有哪些典型缺陷？哪些缺陷已经被修复？哪些缺陷还没有被修复？活跃的缺陷是在快速增加还是稳步下降？
在计算此类风险因素时，测试人员可以采用尽可能简单的度量方法。
一方面，简单的方法更容易解释度量值的含义，从而有助于针对度量值采取相应的行动。 另一方面，复杂的方法增大了分析的难度，却往往不能提供更多的收益。
通过测试去获得直接的反馈，并定期重新度量风险因素，是更注重实效的方法。这也符合ACC的风格：快速的前进，持续的迭代。在测试计划时，测试人员只要快速地确定Capabilities矩阵，而不必担心遗漏。随着测试的进展，他会对矩阵做出必要的调整，以优化测试的价值。
风险缓解
风险分析完成后，该考虑如何降低风险。风险理论上是不可能完全消除的。
-
分析风险大的功能点，一方面从产品定义上进行合理的规避。一方面反馈到开发团队，请他们增加约束。
-
编写回归测试用例，确保问题重现时能够捕捉到
-
编写和运行引发故障的测试用例，推动开发实现恢复和回滚的特性
-
插入对应的监听代码，以便更早的检测故障
-
插入代码监听软件，发现新旧版本间的行为变化以发现回归问题
以下是一些风险缓解的有用指南：
(1) 对于能力矩阵中显示为红色的高风险的功能点，一定要编写对应的测试用例或有针对性的测试指定。
(2) 认真了解之前已经完成的前期测试或开发人员自测的情况，评估一些功能区域的风险级别，判断这些测试是否足够，是否需要额外增加测试？
(3) 分析每个高风险区域相关的bug，保证回归测试用例的存在。
(4) 仔细思索高风险的区域，咨询可能的回滚和恢复进制。
(5) 推动开发人员对高风险区域的识别和测试，毕竟他们是最了解的一群人。
(6) 时间存在限制时，要优先进行重要特性的测试
总结，测试建模、风险分析、风险缓解都应该建立在对产品的详细了解的基础上。对产品的了解不应只留在产品需求定义和外部表现上，也要深入到产品的内部，对其内部实现上也要做到深入了解。只有做到这点，才能够创建准确、全面的测试计划、编写出可操作的测试用例、识别出产品的风险、提出合理的风险缓解的策略。
