软件测试人员对 RUP 四个阶段的贡献：另一种观点

　　本文内容包括:

　　初始(Inception)阶段：管理业务风险

　　精化(Elaboration)阶段：管理技术风险

　　构建(Construction)阶段：管理进度风险

　　产品化(Transition)阶段：管理可接受的风险

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

　　总结：摇尾巴的狗是好狗

　　注释

　　本文来自于 Rational Edge：在对软件迭代开发生命周期中的测试人员的作用进行探讨的同时，作者考虑，除了 RUP 测试规程中提供的描述，测试人员还能如何对项目做出广泛的贡献。

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

　　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)的困难。在软件开发项目中，这种情况发生于格外昂贵的硬件不能为了测试很容易地重新执行任务的时候，或者当独特的环境因素使测试的安排变得困难时。

　　准备测试实验室

　　通过“实验室”，我的意思是一个环境，在其中有我们测试每个需求所需要的东西，一个被提供但与产品环境有很难区分的不同。即使我们在早期的需求发现阶段，仍有可能估算您很可能需要的资源。

　　资源可能包括 1) 硬件、计算机、网络，以及由慢速管道或很长的往返传递，及防火墙所引起的瓶颈，2) 软件，包括测软件及其他必需或采用的软件，所有的都处于已知版本层(或根据所有版本进行测试!)，3) 测试软件，如测试经理，测试自动化软件，如记录或回放 GUI 测试人员，以及用于可伸缩测试的用户虚拟化，4) 数据，包括用于冒烟测试和功能测试的小型数据集，以及用于可伸缩性测试的大型数据集。

　　注意到尽管潜在的实验室特性的列表很长，我们还必须在存在相应的实际需求的地方指定实验室需求。例如，不是所有的系统都有可伸缩性需求，所以不是所有的实验室都将需要用户虚拟化工具。

　　估算需求或场景的整体测试成本

　　大多数需求将作为普通的功能需求出现。与测试相关的成本通常与编码或设计的成本大致成比例，因此测试工作一般来说将是编码和设计成本的某个比例(比方说 25%)。此系数将具体到每个组织，并且可以通过收集一两个项目量度按经验寻找。

原文转自：http://www.ltesting.net