测试建模：Google ACC(2)

　　Capabilities通常是面向用户的(user-oriented)，反映了用户视角的产品行为。测试人员也应该保持Capabilities矩阵的简洁，他们应该关注对用户而言最有价值、最有吸引力的能力，并在合适的抽象层次(right level of abstraction)记录Capabilities。最重要的是，Capabilities应该是可测的(testable)，测试人员能够设计测试来检查产品实现了预期的Capabilities。

　　有了Capabilities矩阵，测试团队就完成初始的测试计划。这就是前Google测试总监James Whittaker所说的10分钟测试计划(The Ten Minutes Test Plan)。其基本思路是专注于核心属性、核心功能和核心能力，而省略一切不必要的细节。之后，测试团队会利用矩阵去指导测试设计，通常矩阵中的一条Capability就是一个测试对象、测试策略或测试情景，而复杂的Capability会演化出更多的测试设计。

　　Google所提供的开源Web应用可以分析项目信息，包括测试用例、代码变更、产品缺陷等，以确定Capabilities矩阵中的高风险区域。下图引用自James Whittaker在GTAC 2010的闭幕演讲的幻灯片，是Chrome OS的Capabilities矩阵的热点图(heap map)。图中绿色表示低风险区域，红色表示高风险区域，粉红色和橙色则表示风险居于前两者之间。测试人员可以根据热点图，更好地确定测试优先级，将有限的资源运用在最需要的地方。

　　许多团队的风险分析依赖于测试人员的经验和猜测，Google的ACC工具则通过分析项目元素(测试用例、代码变更、产品缺陷等)来识别风险。这些被分析的元素位于HTSM->Project Environment，是项目环境的一部分。即便不使用Google的工具，测试人员也可以利用电子表格记录Capabilities矩阵，并自行计算各个条目的风险(一些Google的测试人员也是这么做的)。在评估风险时，他可以考虑如下因素：

　　自动化测试用例：该区域有自动化测试用例吗?测试在定期运行吗?测试通过率是多少?测试用例覆盖了哪些方面，没有覆盖哪些方面?

　　手动测试：有人手动测试该区域吗?经过测试，他们对该区域有信心吗?如果满分是10分，他们会打几分?

　　代码变更：该区域近期存在代码变更吗?变更频繁吗?变更是新增功能、代码重构、还是缺陷修复?

　　代码复杂度：代码的规模是多少?代码是否复杂?如果复杂度的满分是10分，该区域的代码能得几分?

　　产品缺陷：该区域的缺陷多吗?有哪些典型缺陷?哪些缺陷已经被修复?哪些缺陷还没有被修复?活跃的缺陷是在快速增加还是稳步下降?

　　在计算此类风险因素时，测试人员可以采用尽可能简单的度量方法。一方面，简单的方法更容易解释度量值的含义，从而有助于针对度量值采取相应的行动。另一方面，复杂的方法增大了分析的难度，却往往不能提供更多的收益。通过测试去获得直接的反馈，并定期重新度量风险因素，是更注重实效的方法。这也符合ACC的风格：快速的前进，持续的迭代。在测试计划时，测试人员只要快速地确定Capabilities矩阵，而不必担心遗漏。随着测试的进展，他会对矩阵做出必要的调整，以优化测试的价值。

原文转自：http://www.ltesting.net