加快回归测试的步伐：累积测试分析和目标测试入门(3)

　　图 4：每此构建的变更以及所完成的测试

　　通过传统的回归测试的观点查看该数据，可以看到，对构建 3 的测试是有效的，但是构建 4 到 8 中对产品类的附加的功能变更(显示为“新的”或者“非常新的”项)，直到构建 11 才完全测试完成。上面较早描述的其它提示点：

　　构建 1 中出现的大量变更，并且几乎所有这些都对构建 3 充分测试了。

　　在构建 3 之后，许多未测试的变更从一个构建带到了下一个中，使“确定缺陷的时间”拉得更长。

　　在构建 4 和 5 中出现的大量变更，可能已经否定了早先执行的测试的某些好处。更重要的是，对构建 3 运行的并且随后不在循环中重新运行的测试可能会错过构建 4 或之后引入的缺陷。

　　我们管理了对每个构建运行的少量测试，我们将提供所引入变更的最有效的覆盖。

　　利用目标测试使效果最大化

　　指出了老方法中的不足，我们现在使用新的方法。假设相同的环境，通过 CTA 可以完成什么?要论证这点，如先前一样，我们使用同样的两个图表，图 5 和 6 中分别显示出结果和变更。

　　图 5：利用目标测试方法的 CTA 累积测试结果

　　图 5 和 6 中的数据是基于已经部署了累积测试分析和目标测试的测试团队，在需要覆盖每次构建中的变更时只运行那些确定出来的测试。

　　从此结果数据中看，第一件要注意的事情是采用了较少的测试 —— 实际上，相比使用传统方法的 3000 个，运行了大约 1700 个测试。这在图 5 中显示为较少的“新的”或“重新运行的”测试，这可以折合为相对短的时间间隔内的重要的时间节省。

　　图 5 和 3 中第二个明显的差别是构建 3 之后没有橙色的“遗漏”条了。在这种情况下，测试团队利用许多构建来测试构建 1 中引入的所有变更，而在很短的一段时间内，运行了所有确定的测试。即使有这一点延迟，确定缺陷的时间比传统方法减少了。更重要的是，在测试循环中出现的测试中，不再存在对最终构建质量上的观察的 11 天的延迟。这极大地降低了一个已被交付的未测试的变更风险。

　　图 6 中还说明了效率，这显示出更少量的从一次构建到下一次的未测试的或“带过来的”变更。通过在引入了缺陷的构建中找到这些缺陷，可以尽可能低成本地进行确定，并且减少了相互依赖的缺陷修复的复杂链的风险。对一次构建启动测试，并在随后的构建中偿还债务的方法，只要在后继的构建中相同的功能没有变更时都会有效。

　　最后的重点是相同的缺陷 —— 也就是，图 5 中的失败测试 —— 用新的和旧的方法都找到了。

　　图 6：利用目标测试方法，每个构建的变更和完成的测试

　　原则 4：考虑对所有构建执行的所有测试

　　CTA 的第四个基本原则依赖于这样的事实，每个对软件的测试都提供一个质量指数。该测试可能延伸到基本的产品安装、单元测试、简单的配置，或正式的 FVT 或 SVT 活动。类似的，如果在不同的环境中运行同样的或相似的测试(举例来说，在不同的操作系统上)，那么结果应该包含于质量说明中。

　　此原则的一个扩展是这样一个事实，对一个没有变更的功能执行的测试可能仍旧认为是有效的。如图3 和 图5 中所示，允许收集累积的结果。同样的，如果新的区域内的后继测试提供了一个存在测试问题的指示，那么这也应该包含于质量评估中。因此在提供已知构建的质量投影的时候，工具考虑了所有测试。

　　原则 5：利用节省的时间来提高质量、撰写新的测试

　　利用 CTA 和目标测试意味着您不再有 100% 执行的目标了。确切地说，目标随着对产品做出的变更日复一日的改变。问题出来了：人们如何知道什么时候回归测试完成了?回答很简单：直到所有变更都停止了，并且覆盖所有的变更 —— 那些由分析过程所确定的 —— 的测试都运行了，测试才完成。在这一点上，团队利用回归套件几乎完成了每件可能的事情，以确保不会引入额外的缺陷。

　　注意我们说过“团队几乎做了每件事情”，因为方法将只瞄准那些已经包含于回归套件中的测试。如果因为出现了变更，当您没有对变更进行测试，那么您将会无法查看到您仍旧具有的风险。

　　使用此新方法，您可以确信的是，您已经运行了您现有的测试组合中可能的每个测试，来确保最低可能的风险。图 7 例举了这一点，基于每个变更类型中方法的唯一覆盖率，显示出测试套件和它们所覆盖的变更之间的关系。

　　图 7：测试套件和它们所覆盖的变更之间的关系

　　在图 7 中的实例中，组 S3、S4 和 S5 不唯一地覆盖 S1 和 S2 所覆盖的任何方法，然而，通过运行它们，团队可以确定它们可以运行触及部分变更的每一个测试。

　　最显著的是，橙色区域 —— 没有被绿色覆盖的部分 —— 在图中表示根本没有被回归套件中的测试覆盖到的变更。因此团队需要将他们工作的重点集中于撰写提供此覆盖的测试，为了完全测试变更并且将错过潜在缺陷的风险减少到其最低可能的值。幸运的是，CTA 方法给团队时间来开发这些所需的测试。

　　心理转变

　　这不是新技术或一种根本的新样式。背后的思想在最初设想代码覆盖时就出现了。技术提供的东西，尽管，从测试团队的观点来看是一组直觉上正确的思想，但这仍旧表示对许多内容强调的基本变化。只运行测试的子集去掉了“做一些有价值的事情”的兴奋感觉，这是运行整个回归套件的传统实践提供的感觉。该新方法还需要来自于项目管理团队对不再朝着基于风险的 100%的运行目标，而只对每次构建运行恰当的测试的了解和支持。这没有去掉将团队着重于调试测试失败或撰写新测试的需求，但这样做可以为做重要的工作赢得额外的时间!

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