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

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

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

初始（Inception）阶段：管理业务风险

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

• 待解决问题的性质。
• 解决方案的价值，不论是就节约或收益而言，还是以一些其他的业务价值，如质量或时间性而言。
• 潜在的解决方案，因此我们至少知道问题是可解决的。
• 对解决方案的粗略成本估算。
• 危害解决方案的风险。

　评估成本
　　可行性和成本是 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％）。此系数将具体到每个组织，并且可以通过收集一两个项目量度按经验寻找。

　系数将被平台的数量或所需的其他类型的测试工作副本所修改。

　缺陷管理、构建，发布过程
　　存在与将测试人员插入开发过程中有关的成本。测试人员共享其他项目团队使用的特定开发工具，如用于缺陷跟踪的工具，以及构建和发布工具，如用于配置管理的工具。

　精化（Elaboration）阶段：管理技术风险

　RUP 的精化阶段是对准技术风险的管理的。为了制定出自该阶段的可行或不可行的决策，我们需要论证一个对每个鉴别出的技术风险的满意解决方案。通常，最糟的技术问题由非功能需求导致。非功能需求可以造成这样的有趣断言“系统将拥有 99.999％ 的可用性，”或者“系统将支持 10,000 个同时发生的用户会话。”这些需求写起来便宜，但满足和测试起来昂贵。为了进行适当的评估，我们需要了解：

• 在完成极端的非功能目标中可能隐含的权衡。
• 当接近这些极限时各种架构退化的方式。

　因此，关键的评估需求是其中一个度量，并且这应该是此阶段测试人员主要的目标。

　量度方法的评估

　对于每个技术问题，架构团队将建立一个或多个具体表现一个解决方案方法的可执行系统。可能会有若干有竞争的解决方案（举例来说，通信中的 UDP 对 TCP）和大量的对于每个解决方案的可配置选择（举例来说，进程架构中的 10 线程 对 50 个线程）。测试人员执行对生成架构的度量所必需的步骤。

　度量强调的是是否对解决方案有了成熟的考虑而不是功能是否被正确的实现了，因为没有人会期望生命周期中早期就实现完全正确的功能或者甚至花费大量的精力去雕琢还不成熟的系统的功能。初始阶段中指定的许多实验室环境将在精化阶段中被需要。我们将度量性能和可伸缩性，跨过通信链接和出自数据库的数据速率，随负载变化时的响应时间，并且我们将生成需求所要求的其他度量。根据所有的架构原型执行这些测试，并且测试团队将与架构师携手工作，共同设计确认或驳斥每个设计决策的测试。

　当传统测试人员可能会参与整个基于文档的活动时，测试团队在此阶段的行为与瀑布过程中所做的惊人地不同。当项目从一个危机牵绊到下一个时，许多工作都不相关了。相反，在迭代的项目的精化阶段，测试人员在起劲的行动着，被闪光灯和不停的拨号所围绕。测试人员赞成相关的且实际的测试，使它们与架构师保持一致，并且评估并解释结果。

　当然这是富有挑战的工作，但同时还是要大量参与的、有价值的，并令人满意的。如果对于小型的团队环境及上千行的代码的情况建立这些测试都是棘手的，那么设想一下对上百万行的代码项目的大型团队来说所受到的阻碍。

　虽然这个阶段执行测试设计和实现，但是我们应该记住，重要的是测试结果而不是测试文档。由于将会抛弃许多架构的提议，所以相关的测试也一样。我们仅需要做足够的测试设计和实现，用以获得必需的度量。我们不像细化提议那样做太多测试，随着最主要的架构候选的出现，我们可以添加严密，如可溯性和其他文档。

　测试设计
　　作为并行活动，精化阶段表现出一次方便的时机来考虑技术架构中的小变更如何能够更好的帮助测试设计和测试自动化。

　通过测试自动化，我的意思是使用记录键盘和鼠标事件的 GUI 记录或回放工具，可以回放来重复测试。经验丰富的测试人员知道自动化尤其要求重要的脚本维护工作。值得考虑一下允许脚本构造的“测试架构”，这与设计人员创建“软件架构”来简化应用程序构造具有同样意义。

　测试人员应该考虑解决方案，特别是测试可能参数化的方法或映射到需求所暗示的“组合爆炸”的结合方法的复杂性维度。例如，考虑一个指定某个需要支持的平台组合的非功能需求。根据一个平台撰写脚本，在所有平台上“回放”是有利的。这同样可以应用到数据库后端、应用程序服务器、Web 服务器和环境基础架构的其他元素，并且特别是对于这些的排列组合。手动测试每个组合将是不能忍受的痛苦。测试自动化是唯一经济的解决方案。

　大多数应用程序为测试人员的专长提供许多应用程序专用的机会。设计人员将找到“用参数表示”问题领域的方法，并且这些经常成为类似地用参数表示测试所沿着的维度。例如，在我所工作过的一个应用程序中，有许多看起来一样的屏幕上的表格，因此设计人员将列参数化为通用的小部件，这给予测试人员类似的能力来用参数表示它们的测试。

　针对测试的设计在精化阶段如此重要的一个原因是在构建阶段很难找出时间来适当处理这一活动。但是有一个甚至更好的理由：通过测试人员和设计人员之间的良好对话，架构中的小让步可以给测试设计添加一个大好处。总而言之，精化阶段是针对测试而设计的适当时机。

构建（Construction）阶段：管理进度风险

　RUP 的构建阶段瞄准进度风险的管理。如果应用了 RUP 首选的基于用例的方法，就可以比利用传统的（瀑布）方法更快地集中于可用的（尽管不完全）系统。当达到这一可用地不完全层次，剩下的路也就不远了。

　该方法生成了一系列客观的改进的可执行系统，并且拥有重要的优势：

• 在尽可能最早的时候给客户展示系统的功能。
• 团队可以及早地获得部署经验。生成的可执行系统可以转化为产品化阶段的子集（部分部署）。这使我们获得产品化阶段问题的经验 —— 例如，验收测试所需要的是什么，如何为部署而打包，以及一百个其他的问题（参见下面的产品化阶段）。
• 我们收集量度，这使得在迭代开发中可以立即看到项目进展。在瀑布过程中，不太可能直接比较分析活动量度和设计活动量度或编码活动量度，因为它们是完全不同的活动。但在迭代过程中，比较迭代 1 的量度与迭代 2 的量度更加容易，因为我们在重复同一组活动。

　评估进展

　RUP 提到的迭代节奏到构建阶段还是活跃着的，并且该频率与测试人员有特别的关系。测试人员的主要目标是能够客观地描述系统的当前状态，并且能够将该状态与以前的状态进行比较。这两个状态之间的区别，简单地说，就是进展。

　测试人员的“节奏”源于以下活动。

• 测试设计和实现
  　　测试人员的一项主要任务是测试脚本的设计和实现。在迭代开发中，这是由为当前迭代安排的场景所驱动的。测试脚本必须开发成能够将应用程序推到正确的“屏幕”或其他应用程序模式。测试数据必须开发成可以在此处执行应用程序，并且验证必须设计成可以核对应用程序的行为。

　如果使用了自动化的测试工具，那么此时会提出某种考虑，关于该测试用例是否是好的自动化候选或者是否应该手动执行。

• 测试执行
  　　执行测试来确定每个验证点的通过或失败状态。执行手动测试意味着有方法地遵守测试实现提示并适当地观察和注意结果。

　执行自动化的测试意味着安排正确的系统初始条件，然后调用脚本回放工具。在控制初始条件时，我们希望管理测试过程中什么数据处于什么状态。该需求也适用于手动测试，区别在于测试人员可以“照顾”交互并且经常让测试不工作来工作于未初始化的开始条件周围。

• 回归和测试脚本维护
  　　迭代开发的一个明确的任务是需要为每个新的迭代再次运行旧的测试。这种对现有测试集的重复执行称为回归测试，是一个显露出自动化测试的好处和负担的活动。好处：因为另一种是手动测试，很明显的耗费时间的活动。负担：因为自动化的脚本经常需要仔细的修改来服务于下一个构建。测试脚本维护，和脚本回放调试器，对测试人员来说将会是非常熟悉的。测试人员将会及早并且使用减少脚本退化的测试工具，了解如何减少维护工作。
  
• 缺陷跟踪和分辨
  　　缺陷跟踪和分辨活动是测试人员都知道的。测试行为总是揭示缺陷或问题，并且必须勤奋地跟踪每个事故来进行分辨。首先，分辨通常需要在实验室中复制的错误，但至少是处于这个原因，即 SEI Capability Maturity Model Integration (CMMI) 要求项目团队实现配置管理以达到有威信的“可重复级别, 级别 2”。只有通过将所有开发文件置于该控制下，并且用材料清单描述每个构建，开发人员才可能有许多机会重复所有已知的事件并因此能够满足该标准。

　为了提高项目角色之间缺陷信息的共享，用开发人员使用的同样的配置管理和缺陷跟踪环境来装备测试人员是合理的。
针对进展的量度

　我们已经回顾了测试人员在构建阶段所做的事情。我们如何将其转化为进展的量度呢？有多种描述恰当的技术， 3 以下的处理是可以借鉴的。

　完成百分比
　　度量进展的一个过分简单但特别实际的方法是利用“完成百分比”作为量度。如果有人考虑通过测试的场景的流程，我们可以考虑构造一组检查点，表 1 中所显示的一个实例。

　无论如何，分辨缺陷无疑可以看作进展。与缺陷相关的量度也能够以有趣的方式得来，包括：

　每个缺陷的工作、每行源代码的缺陷、每个模块或组件的缺陷、按照注入点的缺陷、按照时间的缺陷、按照状态的缺陷。

　　使用时间图表 —— 根据时间所有这些量度都可以画为图表趋势，例如，应该积极地调查表示修复缺陷工作稳定增长的趋势。

　　我们还能够通过余下的迭代的数量和平均的缺陷分辨工作来增加每个迭代的预期缺陷。这指示了显著的缺陷负担，包括在还没撰写的代码中没有发现的缺陷！这些是粗略的数字，但是是要求全部的完成百分比的重要基础。

　　对于测试人员的缺陷趋势
　　虽然上面的缺陷趋势不是具体到测试规程的，但是存在重要的缺陷量度来指导测试人员，包括每个找到的缺陷的测试工作、每个测试用例的缺陷、每个场景的缺陷，及每个迭代的缺陷。

　这样的量度是有效的，不仅从历史的观察，还从预言能力上讲。例如，如果我们的测试揭示了一个突然的且出乎意料的缺陷密度，我们可能宣称该构建是不健全的，放弃测试，并让架构团队检查此构建。测试一个糟糕的构建以致精疲力尽，从中得不到一点好处。

　MTBF
　　平均故障时间（mean time between failure，MTBF）是重要的“人造”量度 —— 也就是，我们不得不捏造定义，为了能够生成受控条件下的客观度量。MTBF 通常作为非功能需求出现。为了验证我们的系统，我们必须在实验室设置在测的应用程序，利用事件进行干扰，并且当不能适当处理事件时进行监测。我们将其记录为一个失败，并且继续测试或者（如果不幸的话）重新启动应用程序。我们能够以快于真实情况的节奏来生成事件流。这些手段的净效应是能够在几个星期内生成几年中才能度量出的 MTBF 数字。 因为明显的理由，可以将其认为是人造的量度。
　　这些量度证明测试人员应该看作是项目经理重要的数据来源。

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

1. 运行“冒烟测试”。如果冒烟测试通过了，那么：
2. 测试那些在此迭代中分辨出的缺陷。
3. 测试那些在此迭代中实现的新场景。

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

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

　测试优先的方法

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

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

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

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

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

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

　评估可接受性

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

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

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

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

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

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

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

　像这些量度在传统的瀑布过程中是很难收集的。它是迭代生命周期与使收集和应用成为可能的适当测试过程的交汇点。

总结：摇尾巴的狗是好狗

　在传统的开发模型中，直到预定的交付之前的最后“失败”时刻，测试人员经常作为二等公民。然后，他们成为关键的瓶颈，在其中会出现无休止的挑挑拣拣。

　RUP 为测试人员提供了另一种观点。您在其中可以在整个项目中立即做作出贡献，并且减轻每个人的负担。

注释

　1 ISO 是国际标准组织（International Organization for Standardization）的名称，SEI 是卡内基梅隆大学的软件工程学院，IEEE 是电子及电气工程师协会，它为计算行业颁布了多种标准。

　2 参看 COCOMO II，了解在估算中应用系数的技术。

　3参见 Walker Royce，Software Project Management: A Unified Perspective，Addison-Wesley 1998 年。