2.7　测试套件和类型

最后，我们用这个工具批准开发人员代码检入：在允许提交新的或者修改后的代码之前，他们必须在三个不同平台上运行一个最小的验收测试套件（Minimum Acceptance Test Suite, MATS）来测试其代码。通过实验，我们选择这些平台来发现特定的或者罕见的故障。这一步骤有利于在变更被引入源代码之前，减少回归测试和失效的数量。这些测试的运行时间被控制在最短时间内，所以这些测试是有用的，在时间上并没有成为影响进一步开发的障碍。【真知灼见】提供及时的反馈，并且将日常开支减少到最小，为开发人员提供最好的支持。该工具用作夜间的回归测试，这样开发人员白天一上班就能获得关于他们代码变更的反馈信息。这个测试套件包括大部分运行时间稍短的回归测试，并运行在有限选择的平台上：一般是在3 ~ 5个平台，并且运行时间为将近12小时。我们通常还在3个不同的平台上进行每周测试，每一个测试套件运行4 ~ 5天。这些回归测试具有很高的优先级，并获得了管理层的大力支持。这里出现的故障必须尽快修复。除了这些回归测试外，其他测试是在候选批次中运行的。这些测试，是对新版本中新功能或者已变更功能的典型测试，具有更低的优先级，因为它们往往是由负责的开发人员和测试开发人员进行监控的。候选批次也包括夜间和每周运行的批次。项目团队可以根据需要定义更适合自己团队需求的测试套件。这些测试在我们的内部测试工具上运行，性能测试与它们并行运行，并且与基准线进行对比。由于它们对测试和结果的特殊需求，它们都有自己的框架。这些测试通常仅在一个平台上运行。发布测试一般包含以上描述的所有类型的测试，但是在至多22个不同的平台上运行。如图2-3所示。此外，发布测试还包括在测试工具上运行的其他非功能性测试，比如：长时间测试：不同的场景下运行时间至少为10天的测试。扩展性测试：通过增加硬件来减轻负荷的测试，一般采用24台服务器和12台客户机来运行测试。

图2-3　发布测试的内容