测试人员对 RUP 四个阶段的贡献[1] 软件测试
本文来自于 Rational Edge：在对软件迭代开发生命周期中的测试人员的作用进行探讨的同时，作者考虑，除了 RUP 测试规程中提供的描述，测试人员还能如何对项目做出广泛的贡献。
从测试工程师那里听到的最普遍的抱怨是直到过程中很晚的时候才能有效地参与到软件开发项目中。此外，测试通常是在开发人员在抗争损坏一个接一个版本候选的很晚出现的缺陷时所逼出的行为。到一个合适的候选版本出现的时候，测试人员已经成为瓶颈，显然，要对进一步的延迟负责。
Rational Unified Process®，或 RUP®，广泛地概括了测试规程(Test Discipline)，并介绍了测试角色如何及早地参与项目生命周期。
我希望在本文中介绍另一种观点。代替由测试规程开始，我将依次考虑每个 RUP 阶段的风险管理原则，并询问经验丰富的测试人员，为了促进那些目标他们可能会做些什么。虽然测试工程师不能估算总的项目成本，但是他们的确可以评估对成本的测试贡献，并且提出测试风险和可行性。虽然他们不应该计划解决方案架构，但是他们可以帮忙度量。虽然测试人员不构建一系列可执行程序，但是他们可以评估每个可执行程序如何表示一个从前一个而来的进展。虽然测试人员不构建最终的候选版本，但是他们可以确保具有可接受的质量。
我相信在 RUP 的每个阶段，测试人员都有机会对项目做出大量贡献。该贡献远远地扩展了，例如，要求更早地测试交付内容 —— 或者更早地执行一组标准的测试 —— 比传统的瀑布驱动过程中。本文应作为面向开发团队中的测试人员的 RUP 原则的激励说明来阅读。它不应该作为 RUP 测试规程的概要或初级读物。虽然我相信许多测试人员会觉得该信息很有用，但是我还相信管理人员将会对看到测试人员的能力和经验如何在 RUP 项目的所有阶段中更有效地应用感兴趣。
初始(Inception)阶段：管理业务风险
RUP 的初始阶段是对准业务风险的管理。为了制定出自该阶段的可行或不可行的决策，我们需要了解
待解决问题的性质。
解决方案的价值，不论是就节约或收益而言，还是以一些其他的业务价值，如质量或时间性而言。
潜在的解决方案，因此我们至少知道问题是可解决的。
对解决方案的粗略成本估算。
危害解决方案的风险。
带着此信息，涉众被聚集到生命周期目标(Lifecycle Objectives，LCO)会议上。如果项目被视为是可行且值得做的，那么项目会继续进入精化阶段。
评估成本
可行性和成本是 LCO 会议上的重要因素，并且测试人员无疑可以为该决策贡献重要的数据。测试人员可以估算对成本的测试贡献，甚至有时候可以有助于可行性问题。记住，在初始阶段中，尽管我们只对球场的数字感兴趣。过高的精确度将给我们带来不真实精确度的不适当安全感。
文章来源于领测软件测试网 https://www.ltesting.net/
