分类：
2008-10-15 16:42:59
您的团队已经非常成功了。您已经对自动化大量投资，并且因生成大型且全面的集而著称 —— 您可以无可非议地为之自豪！在整个开发过程和多个环境中，这些组合为您很好地服务。因此现在是您休息一会，并且收获您所劳动的好处的时候了，对吗？或者，您将成为您自己的自动化测试集的牺牲品？
也许，像许多团队一样，您已经达到饱和点，现在您有太多的测试，以至于不能说明。也许运行测试的团队已经不再是撰写它们的团队了，并且知识是稀少的。或者也许您受困于对大量所支持的环境和代码流不断地重复运行同样的测试的工作。对于那些您不能运行的测试，或者您没有时间运行的，您对您所带来的风险进行过观察吗？
无疑地，如果您只运行少量的测试，并且仍旧在代码中找到一样的缺陷，这是更好的。通过运行可能的测试尽可能快地找到第一次出现的缺陷不同样是更好的吗？
不能达到的目标
甚至是出于一片好心，每个测试人员在他或她的工作生涯中，都将撰写一个根本不测试所打算测试内容的测试。这可能是由于缺乏经验，对产品功能设计的变更，因为测试人员做出关于产品或其预期使用价值的无效假设，或者只是因为测试人员用尽了时间。总而言之，最终结果是由于与产品缺陷不相关的原因而失败的测试。
这些失败测试的累积效应创造了回归套件中的灰色区域，您的回归测试的 5％ 到 15％是困难的、不可靠的或不可能成功地运行完成的。这些阻塞的或不可靠的测试消耗了宝贵的测试时间，并且混淆了测试人员对真实的产品缺陷的观察，这导致了在回归测试循环末尾的测试进度中的指数的缩小。虚幻的所有可用测试的100％ 的运行目标常常看起来非常接近，但是却难以达到。
自动化陷阱
也许您已经落入了严重依赖于您的测试自动化基础架构的陷阱了。这里有一些您可能考虑的问题。您是：
您可能需要的是，不再瞄准任意数量的测试，而着眼于从上次测试以来在产品中实际变更的功能是什么，以及测试此变更所需要的是什么。总而言之，您需要转移到更深思熟虑的“目标”测试的方法。
停止运行测试，开始寻找缺陷
通常所说的累积测试分析（Cumulative Test Analysis，CTA）方法是基于五个基本原则的：
让我们按顺序讨论这些原则。
原则 1：定期地运行自动化的测试
CTA 方法着重于通过在整个的开发循环中运行自动化的测试将“发生缺陷的时间” 1 最小化。任何回归类型的缺陷都可以很早发现，并且与在循环的末尾运行单个的长期回归运行相比使用了最小量的测试。
此测试的目标是提供对所有驱动程序的功能质量的一个观察，作为进一步测试和最终向市场发布的基础。此回归测试减少了进入最终产品的缺陷数量，以及在这期间，减少可能防止新特性的更复杂的测试的基础功能问题。由此可见，这些回归类型的缺陷需要在其最方便确定的时候尽可能快速地清理掉。
原则 2：了解回归测试套件中现有测试材料的质量和覆盖
如早先讨论的，包含于回归套件中的许多测试在任何规模的测试操作中可能不能生成可靠的结果。为了完全了解产品的质量，事实上，根据潜在的产品缺陷，您在观察的结果意味着什么，您必须首先了解测试实际上测试的功能是什么。
为此，我们求助于代码覆盖的使用。对于外行来说，这实际上是所有方法、类和测试从开始到结束所经过的代码途径的细微痕迹。这种在一个测试接一个测试的基础上的运行时度量提供了对测试做什么的观察，并且比起在实际的测试运行过程中的运行时收集信息时依赖于测试计划或测试文档来说，是一种了解要测什么内容的更精练的方法。当然，对于此途径存在着由，例如，寻找缺陷并执行异常路径的测试引起的偏差。总的来说，尽管，如果代码覆盖数据是在成功的测试运行过程中收集的，那么此信息可以起来随后作为测试的功能的指示。
有许多可用的工具可以提供代码覆盖率。它们都典型地使用被测代码的某种形式的装置，这将钩子（hooks ）加入了产品代码中。当测试材料遇到这些钩子时，代码覆盖工具使用这些钩子来记录每个测试在其执行时所经历的过程。最终结果是一个表示与特定的产品驱动程序冲撞的所有测试的完全覆盖的数据库。因为回归测试材料随着时间的推移变化得不大，那么此数据仍旧相对静态。然而，如果产品或测试材料随着时间的推移变化很大，那么就需要重复实施装置。
原则 3：尽可能少地运行：关注于您的测试
该标题可以等同于这样措辞，“不要浪费时间运行您与先前的驱动程序冲撞的测试，除非它们测试的功能已经变更了。”减少测试运行的数量可能对那些使用回归套件作为获取回归网的许多团队来说需要信仰上的飞跃，但是这种飞跃将节省数不尽的不必要的回归测试时间。
实际上，实现确定目标的测试需要两件事：
1）了解在测的产品驱动程序中确切变更了什么，以及
2）了解您的测试材料（如前面部分中讨论的）。
上面中的第一个在产品代码处于某种库控制形式时相对容易获得。库系统，例如 CMVC、CVS 或 Rational ClearCase 提供创建逻辑变更或截然不同的层次集合的机制。对于这些层次，个别的工具能够提供某种粒度上的一系列变更，不论是文件、包、类或某些更细粒度的类别。有了这两项信息，确定将在最少的时间内，达到变更功能的最大代码或路径覆盖的现有测试记录的子集是可能的。
如果没什么发生变更 —— 或者，更可能的是，您没有对发生变更的功能进行测试 —— 您只是不运行任何东西！这样做是对您可以花费在其他地方的宝贵时间的浪费。
此处给出一个警告：如果回归测试套件是范围非常广泛的，那么这将有极好的效果。但如果覆盖很低，那么有时候，目标测试可能使您得出结论，您没有合适的测试值得运行。记住，在这一点上，用回归测试的标准方法，团队会盲目地运行整个回归套件。这几乎不会增加价值，但确实会花费很多时间。通过使用 CTA 方法，您可以利用节省的时间来撰写新测试增加您的覆盖率（参见在下面的原则 5 中的讨论）。
[1]
