原则 5：利用节省的时间来提高质量、撰写新的测试
利用 CTA 和目标测试意味着您不再有 100％ 执行的目标了。确切地说，目标随着对产品做出的变更日复一日的改变。问题出来了：人们如何知道什么时候回归测试完成了？回答很简单：直到所有变更都停止了，并且覆盖所有的变更 —— 那些由分析过程所确定的 —— 的测试都运行了，测试才完成。在这一点上，团队利用回归套件几乎完成了每件可能的事情，以确保不会引入额外的缺陷。
注意我们说过“团队几乎做了每件事情”，因为方法将只瞄准那些已经包含于回归套件中的测试。如果因为出现了变更，当您没有对变更进行测试，那么您将会无法查看到您仍旧具有的风险。
使用此新方法，您可以确信的是，您已经运行了您现有的测试组合中可能的每个测试，来确保最低可能的风险。图 7 例举了这一点，基于每个变更类型中方法的唯一覆盖率，显示出测试套件和它们所覆盖的变更之间的关系。
图 7：测试套件和它们所覆盖的变更之间的关系
在图 7 中的实例中，组 S3、S4 和 S5 不唯一地覆盖 S1 和 S2 所覆盖的任何方法，然而，通过运行它们，团队可以确定它们可以运行触及部分变更的每一个测试。
最显著的是，橙色区域 —— 没有被绿色覆盖的部分 —— 在图中表示根本没有被回归套件中的测试覆盖到的变更。因此团队需要将他们工作的重点集中于撰写提供此覆盖的测试，为了完全测试变更并且将错过潜在缺陷的风险减少到其最低可能的值。幸运的是，CTA 方法给团队时间来开发这些所需的测试。
心理转变
这不是新技术或一种根本的新样式。背后的思想在最初设想代码覆盖时就出现了。技术提供的东西，尽管，从测试团队的观点来看是一组直觉上正确的思想，但这仍旧表示对许多内容强调的基本变化。只运行测试的子集去掉了“做一些有价值的事情”的兴奋感觉，这是运行整个回归套件的传统实践提供的感觉。该新方法还需要来自于项目管理团队对不再朝着基于风险的 100％的运行目标，而只对每次构建运行恰当的测试的了解和支持。这没有去掉将团队着重于调试测试失败或撰写新测试的需求，但这样做可以为做重要的工作赢得额外的时间！
注释
1 发现缺陷的时间（Time to defect）：将缺陷引入到产品代码中和将缺陷报告分配给进行确定的开发人员期间经过的时间。
参考资料
- “McCabe 推荐的软件变更分析的方法，”McCabe 及其同事：http://www.mccabe.com
- A. Orso、N. Shi 和 M.J. Harrold，“Scaling Regression Testing to Large Software Systems”，College of Computing, Georgia Institute of Technology, Atlanta, GA 。
- 您可以参阅本文在 developerWorks 全球网站上的 英文原文。
