测试人员对 RUP 四个阶段的贡献：另一种观点(二)

 

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

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

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

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

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

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

·                      回归和测试脚本维护
迭代开发的一个明确的任务是需要为每个新的迭代再次运行旧的测试。这种对现有测试集的重复执行称为回归测试，是一个显露出自动化测试的好处和负担的活动。好处：因为另一种是手动测试，很明显的耗费时间的活动。负担：因为自动化的脚本经常需要仔细的修改来服务于下一个构建。测试脚本维护，和脚本回放调试器，对测试人员来说将会是非常熟悉的。测试人员将会及早并且使用减少脚本退化的测试工具，了解如何减少维护工作。

·                      缺陷跟踪和分辨
缺陷跟踪和分辨活动是测试人员都知道的。测试行为总是揭示缺陷或问题，并且必须勤奋地跟踪每个事故来进行分辨。首先，分辨通常需要在实验室中复制的错误，但至少是处于这个原因，即 SEI Capability Maturity Model Integration (CMMI) 要求项目团队实现配置管理以达到有威信的“可重复级别, 级别 2”。只有通过将所有开发文件置于该控制下，并且用材料清单描述每个构建，开发人员才可能有许多机会重复所有已知的事件并因此能够满足该标准。

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

针对进展的量度

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

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

表 1 ：测试流中的检查点
检查点	描述
被识别的场景	放弃用例分析。被识别的可选流和例外流的有趣的组合。在精化阶段的末尾完成 80 ％。
详细的场景	使对象与所描述的事件顺序协作。
被识别的测试用例的数量	该数字经常是 1 ，但是每个场景有多个测试用例是可能的。应该包含每个测试用例的原因或目的。
定义的测试用例	测试用例与相关的文当工作一起产生。这包括到驱动需求的链接、测试方法、前置和后置条件、测试数据及可观察的结果。
实现的测试脚本	特定的初始条件，将应用程序导航到测试位置的指导，输入测试数据的顺序，观察结果的方法，结果值的设置。
执行的测试	至少已经执行一次测试脚本。
曾经通过的测试	先前测试执行已经通过了所有构建。可选择地，最近通过的时期。
通过的测试	测试执行通过了最近的迭代。

我们确定表 1 中每个场景和测试中所描述的每个检查点。不论完成或是没完成，它们的值都严格地报告为是或不是的值。我们合计每一层并将其表示为前一个层的某个百分比。目标是达到每一层的 100％ 覆盖。总的结果相当粗略，但针对达到最高百分比的工作带来了提前测试工作的非常有意义的副加作用。

·                      缺陷趋势
每个迭代将拥有一个开发包，一些新的特性或场景加入其中并且根据现有场景的缺陷也得到修复。当然有一个趋势，即实现新的而不修复老的，但是明智的项目经理将注意缺陷趋势并强调，至多一两个以缺陷形式的未解决的迭代工作的价值将保留。

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

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

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

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

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

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

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

这些量度证明测试人员应该看作是项目经理重要的数据来源。

构建迭代测试优先级

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

1.    运行“冒烟测试”。如果冒烟测试通过了，那么：

2. 测试那些在此迭代中分辨出的缺陷。

3. 测试那些在此迭代中实现的新场景。

上面的三项应看作是绝对极小值，并且不能实现它们的应该看作是测试过程的主要失败。我们应该继续三个步骤：

4.    维护和执行的自动化测试

5. 维护和执行的手动测试

6. 人造量度集合

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

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

测试优先的方法

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

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

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

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

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

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

评估可接受性

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

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

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

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

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

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

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

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

总结：摇尾巴的狗是好狗

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

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

注释

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

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

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

 

 

 

 

更多精彩内容请访问         www.17testing.com