原则 3：尽可能少地运行：关注于您的测试

　　该标题可以等同于这样措辞，“不要浪费时间运行您与先前的驱动程序冲撞的测试，除非它们测试的功能已经变更了。”减少测试运行的数量可能对那些使用回归套件作为获取回归安全网的许多团队来说需要信仰上的飞跃，但是这种飞跃将节省数不尽的不必要的回归测试时间。

　　实际上，实现确定目标的测试需要两件事：1）了解在测的产品驱动程序中确切变更了什么，以及 2）了解您的测试材料（如前面部分中讨论的）。

　　上面中的第一个在产品代码处于某种库控制形式时相对容易获得。库系统，例如 CMVC、CVS 或 Rational ClearCase 提供创建逻辑变更或截然不同的层次集合的机制。对于这些层次，个别的工具能够提供某种粒度上的一系列变更，不论是文件、包、类或某些更细粒度的类别。有了这两项信息，确定将在最少的时间内，达到变更功能的最大代码或路径覆盖的现有测试记录的子集是可能的。

　　如果没什么发生变更 —— 或者，更可能的是，您没有对发生变更的功能进行测试 —— 您只是不运行任何东西！这样做是对您可以花费在其他地方的宝贵时间的浪费。

　　此处给出一个警告：如果回归测试套件是范围非常广泛的，那么这将有极好的效果。但如果覆盖很低，那么有时候，目标测试可能使您得出结论，您没有合适的测试值得运行。记住，在这一点上，用回归测试的标准方法，团队会盲目地运行整个回归套件。这几乎不会增加价值，但确实会花费很多时间。通过使用 CTA 方法，您可以利用节省的时间来撰写新测试增加您的覆盖率（参见在下面的原则 5 中的讨论）。

　　累积观点：沿用先前的测试结果

　　除了确定测试目标，CTA 还利用另一个关键的概念减少了所需的测试运行的数量：累积的结果分析。一旦确定了测试的目标是只覆盖变更的功能，那么来自于未变更代码区域的结果就可能从一次构建转移到下一次。

　　此方法的重要好处是允许使用最少的测试数据进行质量评估。这对于发布循环的末期是特别有用的，此时要做出少量的变更，并且大范围的运行测试会过高地耗费时间。最终的决策可以根据实际上许多星期或月之前的测试数据做出，而产品仍旧保持一段时间的功能稳定。

　　通过将目标测试和累积结果分析两条原则组合起来，在测试循环早期运行的测试可能不再需要再次运行了，它们的结果将保留到最后。类似地，任何覆盖不稳定的代码区域的测试可能需要每天都重新运行。通过采用此方法，可以将测试着重于产品的那些携带最高风险缺陷的区域。

　　实例：传统测试与目标测试

　　下面的一系列图表显示了一个来自于典型的回归测试执行的可能输出的人为实例。我们首先使用传统方法，然后对这个系列的构建使用目标方法，以及累积结果分析。

　　考虑下面图 1 中显示的场景，这可能是导致输出一般利用率（GA）的开发循环的一部分。测试团队已经利用了由构建 3 和构建 11 获得的最重要的结果数字对连续的构建尝试许多回归执行。

图 1：每次构建的测试完成百分比，使用传统的回归测试方法

　　利用传统的分析方法并研究图 1 中的图表，我们只能得出以下有限的结论：

• 没有一次回归达到 100％ 完成 —— 不可能说出余下的测试对整个质量陈述是否重要。
• 很可能的是对构建 4 到 8 的小百分比的测试，要么为测试的确定重新运行，要么新的测试是覆盖没有为构建 4 的额外功能 —— 不论发生哪种情况，都不可能在不进一步分析的情况下确定地知道。
• 此图表中不清楚的是为什么对构建 9 执行如此多的测试。
• 不可能从图 1 中的得知的是，回归套件中的所有测试是否在某一处都运行了。对此，我们求助于图 2 中显示的图表。

图 2：利用传统回归测试方法的累积测试完成百分比。

　　图 2 显示了对构建 11 收集的一段时间的测试的累积结果。此处，很可能看到的是团队计划运行大部分可用的测试，并且发现许多测试失败，然而，运行这些测试所花费的时间意味着在产品发布的时候这些中的许多仍旧存在。

　　让我们为该虚拟场景填充一些背后细节。设想构建 3 是最初的 GA 候选，差不多 80％ 的可用测试生成了好的结果。其间，缺陷确定和其他变更慢慢地进入到由于工作都集中于构建 3 而很少测试到的后继构建中。构建 9 宣布为新的 GA 候选，并且测试再次开始。当构建 11 成为最终的 GA 构建时，测试工作再次重新开始。如在图 2 中可以看到的，此次对构建的测试直到 GA 驱动程序生成之后 11 天才能完成。