用例驱动的迭代方法生成了新的机会和新的负担。因为我们将已经限制阻碍完全测试的资源，所以我们应该根据以下优先级顺序执行测试：

　　运行“冒烟测试”。如果冒烟测试通过了，那么： 
　　测试那些在此迭代中分辨出的缺陷。 
　　测试那些在此迭代中实现的新场景。
 
　　上面的三项应看作是绝对极小值，并且不能实现它们的应该看作是测试过程的主要失败。我们应该继续三个步骤：

　　维护和执行的自动化测试 
　　维护和执行的手动测试 
　　人造量度集合 

　　当然，应该优先选择不需要维护当前连编的自动化测试。随着时间的推移，我们应该能够收集从中可以预计测试工作的量度，例如，维护自动化测试要多少工作，运行手动测试要多少工作，等等。

　　每个项目团队必须分辨的一个问题是测试活动与开发活动并行的方式。从某种意义上讲，一旦对开发人员来说迭代结束了，对于测试人员迭代就开始了。

　　测试优先的方法

　　测试优先的方法在最近五年内受到了相当大的推动。简单地说，开发人员在撰写代码之前要撰写一个测试。每个分支、循环，或其他逻辑在加入源代码之前都要写出将要执行结果的自动化测试。

　　测试优先主要在构建阶段，主要由开发人员执行，而不是测试人员。可以将其尽早地引入精化阶段，但如您所见到的，强调的不是功能的完整性。

　　产品化（Transition）阶段：管理可接受的风险

　　验收测试应该已经是所有测试人员都熟悉的，因此此讨论将只涵盖验收的重点。

　　总体上我将定义验收活动包含部署，以及因此发现的所有问题和缺陷。这是 RUP 在产品化阶段所描述的内容，并且测试人员将其理解为验收的评估。

　　测试人员在支持项目经理达到项目阶段目标上起着关键作用。无疑会有大量增加的请求以及低优先级的缺陷，无论哪里，只要可能，这些都应当延迟到新的维护项目中。

　　评估可接受性

　　产品化阶段中强调的是分辨缺陷并停止项目。不允许新的功能。开发人员有时候称项目中这一点为“代码烂泥” —— 换句话说，还没有“代码冻结”，因为某些类型的变更还允许出现。

　　测试人员在发布计划中起很大作用。这包括测试工作和进度（应该源于最近的构建迭代中获得的测试工作量度）。预先应该已经确定了，构成缺陷级别和其他量度的可接收的门限是什么。这可能意味着（例如），零关键缺陷，只有一个工作区至多一个“高优先级”缺陷，五个“中等”，及许多“低级”的。因此，测试人员可以指定并跟踪版本候选是否具有适当的质量。

　　产品化阶段将构建阶段“开发的”缺陷跟踪与外部的面对客户的及服务台的缺陷跟踪连结起来。测试版程序的许多优势之一是该支持及跟踪机制可以实行。

　　从理论上讲，如果对可交付内容做出了任何变更，都应该执行完整的测试集合。在安全至上的系统中，这很可能成为一个需求，甚至是一个规章。在一般的商业环境中，测试人员可以帮助项目经理决定运行哪个测试子集。这可能包含所有自动化测试、一些手动测试，再加上，比方说，在“实验室”中的五天时间（也就是，在 MTBF 环境中）。测试人员将使用在其上测试最可能产生失败的量度。当创建软件“补丁”时，测试人员履行类似的职责。

　　数据格式支持、数据转换，及数据迁移是产品化阶段和客户部署中的重要活动。这些都在测试人员的职责范围内。有时候，测试人员回顾用户指导和其他文档。技术作者执行此任务。

　　测试、编码、迭代，和量度

　　量度已经在我们的讨论中表现显著。测试是量度重要的来源和用户。当测试进展量度结合开发进展量度时，我们获得项目状态及其可能道路的引人注目的全面指示。这些客观的预测是管理用户期望，及能够精确地估算、请求，并防御额外的进度或资源所必要的。