2.6　管理自动化测试

　　我们的测试过程在持续改进，并且我们为测试设计了一个可记录的生命周期，如图2-2所示。

　　测试被开发出来之后，会进行评审，如果审查通过，这个测试就会被包含到候选队列中（一个测试集合用来尝试是否应该包含到整个自动化套件中）。如果一个候选测试在一行中有4天都失败了，那么它会被提取出来重新进行开发。在测试本身没有任何失效一周之后，这个测试会设置为“有效”状态，并可以包含到每晚的或者每周的测试套件中。

图2-2　测试的生命周期

　　如果产品的功能改变了但是其测试没有更新，测试可以“挂起”。根据挂起的原因，测试将来可能会成为“有效”状态或者候选测试状态（故障的原因被修复之后）。

　　不同测试套件的内容会进行周期性分析。度量指标用来衡量运行这些特定测试的收益。根据这一过程的结果，一个测试可以从一个测试套件移到另一个测试套件（依据测试的运行频率），或者在某些情况下转移到“退出”状态。如果某一个测试可能不会再用到了，团队就会考虑删除它。

　　我们制定了很多度量标准，都使管理层非常满意，而且非常关注我们，并提高了团队的优先级。毫无疑问，相比于之前，他们对产品审批过程的信任有了大幅提升。

　　2.7　测试套件和类型

　　最后，我们用这个工具批准开发人员代码检入：在允许提交新的或者修改后的代码之前，他们必须在三个不同平台上运行一个最小的验收测试套件（Minimum Acceptance Test Suite, MATS）来测试其代码。通过实验，我们选择这些平台来发现特定的或者罕见的故障。这一步骤有利于在变更被引入源代码之前，减少回归测试和失效的数量。这些测试的运行时间被控制在最短时间内，所以这些测试是有用的，在时间上并没有成为影响进一步开发的障碍。

　　【真知灼见】

　　提供及时的反馈，并且将日常开支减少到最小，为开发人员提供最好的支持。

　　该工具用作夜间的回归测试，这样开发人员白天一上班就能获得关于他们代码变更的反馈信息。这个测试套件包括大部分运行时间稍短的回归测试，并运行在有限选择的平台上：一般是在3 ~ 5个平台，并且运行时间为将近12小时。

　　我们通常还在3个不同的平台上进行每周测试，每一个测试套件运行4 ~ 5天。

　　这些回归测试具有很高的优先级，并获得了管理层的大力支持。这里出现的故障必须尽快修复。

　　除了这些回归测试外，其他测试是在候选批次中运行的。这些测试，是对新版本中新功能或者已变更功能的典型测试，具有更低的优先级，因为它们往往是由负责的开发人员和测试开发人员进行监控的。候选批次也包括夜间和每周运行的批次。项目团队可以根据需要定义更适合自己团队需求的测试套件。

　　这些测试在我们的内部测试工具上运行，性能测试与它们并行运行，并且与基准线进行对比。由于它们对测试和结果的特殊需求，它们都有自己的框架。这些测试通常仅在一个平台上运行。