从测试工程师那里听到的最普遍的抱怨是直到过程中很晚的时候才能有效地参与到软件开发项目中。此外，测试通常是在开发人员在抗争损坏一个接一个版本候选的很晚出现的缺陷时所逼出的行为。到一个合适的候选版本出现的时候，测试人员已经成为瓶颈，显然，要对进一步的延迟负责。 

　　Rational Unified Process®，或 RUP®，广泛地概括了测试规程（Test Discipline），并介绍了测试角色如何及早地参与项目生命周期。 

　　我希望在本文中介绍另一种观点。代替由测试规程开始，我将依次考虑每个 RUP 阶段的风险管理原则，并询问经验丰富的测试人员，为了促进那些目标他们可能会做些什么。虽然测试工程师不能估算总的项目成本，但是他们的确可以评估对成本的测试贡献，并且提出测试风险和可行性。虽然他们不应该计划解决方案架构，但是他们可以帮忙度量。虽然测试人员不构建一系列可执行程序，但是他们可以评估每个可执行程序如何表示一个从前一个而来的进展。虽然测试人员不构建最终的候选版本，但是他们可以确保具有可接受的质量。 

　　我相信在 RUP 的每个阶段，测试人员都有机会对项目做出大量贡献。该贡献远远地扩展了，例如，要求更早地测试交付内容 —— 或者更早地执行一组标准的测试 —— 比传统的瀑布驱动过程中。本文应作为面向开发团队中的测试人员的 RUP 原则的激励说明来阅读。它不应该作为 RUP 测试规程的概要或初级读物。虽然我相信许多测试人员会觉得该信息很有用，但是我还相信管理人员将会对看到测试人员的能力和经验如何在 RUP 项目的所有阶段中更有效地应用感兴趣。 

　　初始（Inception）阶段：管理业务风险
　　RUP 的初始阶段是对准业务风险的管理。为了制定出自该阶段的可行或不可行的决策，我们需要了解

　　待解决问题的性质。 
　　解决方案的价值，不论是就节约或收益而言，还是以一些其他的业务价值，如质量或时间性而言。 
　　潜在的解决方案，因此我们至少知道问题是可解决的。 
　　对解决方案的粗略成本估算。 
　　危害解决方案的风险。 
　　带着此信息，涉众被聚集到生命周期目标（Lifecycle Objectives，LCO）会议上。如果项目被视为是可行且值得做的，那么项目会继续进入精化阶段。

　　评估成本
　　可行性和成本是 LCO 会议上的重要因素，并且测试人员无疑可以为该决策贡献重要的数据。测试人员可以估算对成本的测试贡献，甚至有时候可以有助于可行性问题。记住，在初始阶段中，尽管我们只对球场的数字感兴趣。过高的精确度将给我们带来不真实精确度的不适当安全感。

　　也许有或也许没有实际的可执行程序作为 LCO 简报的一部分。这些可能由技术示范者、现有产品的快速出租，或者也许是更实质的东西组成。我的意见是在如此初步的阶段执行如此正式的操作是不适当的。

　　因为测试成本对总的开发成本做出贡献，所以我已经列出许多对测试成本做出贡献的行为。

　　测试风险 
　　风险需要减轻计划，减轻风险需要花费金钱。测试风险是各种各样的。例如，需求可能迅速地变更，这可能会破坏可测试性或测试成本设想。后继的精化阶段可能会利用新的测试难点的解决方案来解决技术风险。可能需要遵守 MC/DC（Modified Condition/Decision Coverage）测试、ISO 标准、SEI 标准，IEEE 标准，等等这样的标准。 1 这些标准可以减少整个业务成本，但是顺应成本在某种程度上落在测试人员上，并且应该更加明显。可能存在与数据安全相关的政府规章，如保密性规章，使对“真实”数据的测试变得困难或昂贵。

　　可测试性 
　　可测试性与可行性直接相关，并且很可能找到很难测试的高层次需求。一些需求是非可测试的，因为他们是主观的，或者不是有助于度量或量度的。一些是不可测试的，因为从技术上很难安排一个合适的测试。例如，一些战略防御计划（Strategic Defense Initiative，SDI）的批评家提到在美国执行其导弹防御的可接受性测试时，让苏联启动非武装的洲际弹道导弹（Intercontinental Ballistic Missile，ICBM）的困难。在软件开发项目中，这种情况发生于格外昂贵的硬件不能为了测试很容易地重新执行任务的时候，或者当独特的环境因素使测试的安排变得困难时。