任务:实施测试套件
此任务描述了如何确定应一起执行的测试。
用途

此任务的目的是执行以下操作:

  • 将要执行的测试组成集合,以实现测试日志的价值
  • 通过试验令人感兴趣的测试组合,帮助确定测试覆盖率适当的广度和深度
关系
步骤
检查候选测试套件
目的: 理解测试套件,并选择将实施哪些候选者

通过复审任何现有测试套件概述开始,并确定哪些测试套件当前是好的实施候选者。使用迭代测试计划、测试构想列表和任何其他测试定义工作产品作为制定决策的基础。

检查相关测试和目标测试项
目的: 理解计划的测试和目标测试项之间的关系

对于您为实施选择的每个测试套件,识别哪些目标和相关测试是包含在测试套件范围内的候选者。

识别测试依赖关系
目的: 识别测试对其他测试,以及通常对系统状态的依赖关系

以考虑测试环境配置和特定的系统启动状态开始。考虑将存在哪些特定的设置需求,例如从属数据库的启动数据集。如果一个测试环境配置将用于各个不同的测试套件,请识别任何需要为每个测试套件进行管理的配置设置,例如视频显示的屏幕分辨率,或者区域性操作系统设置。

现在确定测试之间的任何特定关系。寻找这样的依赖关系,其中一个包含在 测试套件中的一个测试的执行将导致系统状态的更改,而该更改是另一个测试必需的前置条件。

一旦您识别了相关的依赖关系,请确定这些依赖测试正确的执行顺序。

识别重用机会
目的: 通过重用现有资产和合并新的资产,改善测试套件的可维护性

维护测试套件(尤其是自动测试套件)中的主要挑战之一在于,确保很容易进行正在进行的变更。建议您在可能的情况下或认为有用的时候,为用在多个地方的元素维持一个修改中心点。如果那些相同的元素可能变更,更建议您这样做。

尽管这些测试本身形成了天然的模块性单元,将这些测试组合到一个测试套件常常会在多个测试之间标识重复的过程元素,这多个测试如果进行合并的话,对它们的维护会更有效。抓住机会标识测试的任何一般机制,这些测试可能会重构到标准例程中,以协助正在进行的维护。

应用必要的基础结构实用程序
目的: 抽出复杂的实施细节,该细节对于支持将测试作为简化的实用程序功能是必需的

大多数测试工作需要使用一个或多个“实用程序”,它们生成、收集、诊断、转换和比较在测试执行过程中使用的信息。这些实用程序通常简化复杂和费力的任务,这些任务如果手动执行的话,很容易出错。此步骤关于应用测试套件内的现有实用程序功能,并识别需要的新实用程序函数。

一个好主意是简化这些实用程序的接口,在实用工具的私有实施中包含尽可能多的复杂性。另一个好主意是以这样的方式开发实用程序,即使其在需要的场合可重用于手动和自动测试工作。

我们建议您不要隐藏体现这些实用工具中个别测试的特征的信息,而是在可能的情况下,将实用程序限制到收集信息或将实际值与预期结果相比较等的复杂机制,传入每个个别测试的特定特征作为控制测试或测试套件的输入,并返回个别实际结果作为控制测试或测试套件的输出。

确定恢复需求
目的: 使测试套件能被恢复,而不需要对测试套件进行完整的再次执行

确定测试套件内的合适点,以在测试套件执行期间发生故障的情况下提供恢复。此步骤在以下情况下很重要:测试套件包含大量测试,或者将运行相当长的时间(常常是无人看管运行)。尽管一般是标识为自动测试套件的需求,但对于手动执行的测试套件,考虑恢复点也是重要的。

除了恢复或重新启动点之外,在自动测试套件的情况下,您可能还想要考虑自动测试套件恢复。自动恢复的两种方法是:1)基本恢复,其中现有测试套件可以从发生于它的一个测试中的小错误中自我恢复,通常在测试套件中下一测试处恢复执行;或者 2)复杂恢复,该恢复在失败的测试之后进行清理,在必要时对相应的系统状态进行复位,包括操作系统重启和数据复原。在第一种方法中,测试套件接下来确定失败的测试,并选择要执行的下一测试。

实施恢复需求
目的: 实施恢复进程,并验证其是否按照需要工作

根据需要的复杂程度,它将需要工作实施并稳定恢复处理。您将需要允许有足够的时间来模拟大量可能(以及少数不可能)的故障,并证实恢复处理工作。

对于自动恢复的情况,先前步骤中概述的两种方法都有其优点和缺点。您应仔细考虑复杂自动化恢复在初始开发和持续维护工作两方面的成本。有时候手动恢复就已足够好了。

稳定测试套件
目的: 在系统状态方面和测试执行顺序方面解决所有依赖关系问题

在可能的情况下,您应耗费时间,通过一个或多个试验的测试来稳定测试套件。达到稳定性的难度随测试套件的复杂度成正比增长,且在不相关测试之间有过于紧密的耦合,而相关测试之间的附着性较低时,难度也会增长。

当测试在给定的测试套件内一起执行时,会存在发生错误的可能性,而在个别测试独立执行时未遇到这些错误。这些错误常常是最难以跟踪到并进行诊断的错误,尤其是它们是在冗长的自动测试运行的中途遇到时。实际情况中,一个不错的建议是在添加其他测试时定期返回测试套件。这将有助于您隔离少数要诊断的潜在候选测试,以识别问题。

维护可跟踪性关系
目的: 支持对所跟踪的项进行影响分析和评估报告

通过使用在测试计划中概述的可跟踪性需求,在必要时更新可跟踪性关系。可能会将测试套件跟踪到定义的测试用例或测试构想。(可选),可以将它们跟踪到用例、软件规范元素、实施模型元素以及测试覆盖的一个或多个度量。

评估并验证结果
目的: 验证任务已恰当地完成,生成的工作产品是可以接受的

既然您已完成了该工作,那么最好验证该工作是否有足够的价值,而且您并不是简单地消耗大量纸张。您应评估您的工作质量是否适当,是否完整得足以让其他团队成员觉得您的工作很有用,并随后将它们用作他们自己工作的输入源。在可能的情况下,请使用 RUP 中提供的核对表验证质量和完整性是否都“足够好”。

让执行下行任务(根据您输入的工作信息)的人员参与复审您的过渡工作。请在您还有时间针对他们的意见采取行动时让他们参与复审。 您还应针对主要输入工作产品评估您的工作,以确保您已精确并充分地展示了它们。让输入工作产品的作者以此为基础复审您的工作,这可能很有用。

请记住,RUP 是一个迭代式的交付流程,并且在许多情况下工作产品是随着时间而演进的。所以,通常没必要完全形成将在近期的后续工作中只部分使用或根本不用的工作产品,并且这通常对生产力有副作用。这是因为很有可能在使用工作产品前,工作产品周围的情况会发生变化(并且在创建工作产品时作出的假设也会证明是不正确的),从而带来工时的浪费和高成本的重复工作。同时也要避免在展示内容值的危害方面花费过多周折的陷阱。 在展示作为项目可交付件有很大的重要性而且有经济价值的项目环境中,您可能希望考虑使用管理资源来执行展示任务。



属性
多次出现
事件驱动
正在进行
可选
已计划
可重复
更多信息