累积测试分析和目标测试入门[2]

　　累积测试分析和目标测试入门[2]    软件测试

　　在不了解那些测试的价值的情况下，花费您大部分的时间来确定坏掉的测试吗?

　　瞄准 100% 运行您所有的测试的目标吗?在质量和风险方面您了解此目标吗?

　　您可能需要的是，不再瞄准任意数量的测试，而着眼于从上次测试以来在产品中实际变更的功能是什么，以及测试此变更所需要的是什么。总而言之，您需要转移到更深思熟虑的“目标”测试的方法。

　　停止运行测试，开始寻找缺陷

　　通常所说的累积测试分析(Cumulative Test Analysis，CTA)方法是基于五个基本原则的：

　　定期地运行自动化的测试。

　　了解现有测试材料的实际覆盖和质量。

　　运行尽可能少的测试。将测试关注在只运行那些覆盖了发生变更的功能的测试。

　　在做出评估时考虑所有的测试活动。

　　由四个较早的步骤所节省下来的时间可以用于增加测试套件的质量，或者执行额外的测试。

　　让我们按顺序讨论这些原则。

　　原则 1：定期地运行自动化的测试

　　CTA 方法着重于通过在整个的开发循环中运行自动化的测试将“发生缺陷的时间” 1 最小化。任何回归类型的缺陷都可以很早发现，并且与在循环的末尾运行单个的长期回归运行相比使用了最小量的测试。

　　此测试的目标是提供对所有驱动程序的功能质量的一个观察，作为进一步测试和最终向市场发布的基础。此回归测试减少了进入最终产品的缺陷数量，以及在这期间，减少可能防止新特性的更复杂的测试的基础功能问题。由此可见，这些回归类型的缺陷需要在其最方便确定的时候尽可能快速地清理掉。

　　原则 2：了解回归测试套件中现有测试材料的质量和覆盖

　　如早先讨论的，包含于回归套件中的许多测试在任何规模的测试操作中可能不能生成可靠的结果。为了完全了解产品的质量，事实上，根据潜在的产品缺陷，您在观察的结果意味着什么，您必须首先了解测试实际上测试的功能是什么。

　　为此，我们求助于代码覆盖的使用。对于外行来说，这实际上是所有方法、类和测试从开始到结束所经过的代码途径的细微痕迹。这种在一个测试接一个测试的基础上的运行时度量提供了对测试做什么的观察，并且比起在实际的测试运行过程中的运行时收集信息时依赖于测试计划或测试文档来说，是一种了解要测什么内容的更精练的方法。当然，对于此途径存在着由，例如，寻找缺陷并执行异常路径的测试引起的偏差。总的来说，尽管，如果代码覆盖数据是在成功的测试运行过程中收集的，那么此信息可以存储起来随后作为测试的功能的指示。

　　有许多可用的工具可以提供代码覆盖率。它们都典型地使用被测代码的某种形式的装置，这将钩子(hooks )加入了产品代码中。当测试材料遇到这些钩子时，代码覆盖工具使用这些钩子来记录每个测试在其执行时所经历的过程。最终结果是一个表示与特定的产品驱动程序冲撞的所有测试的完全覆盖的数据库。因为回归测试材料随着时间的推移变化得不大，那么此数据仍旧相对静态。然而，如果产品或测试材料随着时间的推移变化很大，那么就需要重复实施装置。

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