任务:执行测试套件
此任务描述了如何执行对于评估产品质量所必需的相应测试的集合,以及如何捕获可辅助正在进行的产品评估的测试结果。
规程:测试
关系
角色主执行者: 其他执行者:
输入必需: 可选:
输出
流程使用情况
步骤
将测试环境设置为已知状态
目的: 精确地建立测试环境,为测试套件的执行作准备。

对测试环境进行设置,以确保建立了所有必需的组件(硬件、软件、工具、数据等),且这些组件在测试环境中以正确状态的可用和就绪,以便能够开始进行测试。通常这将涉及到某种形式的基本环境复位(例如注册表和其他配置文件),将底层数据库复原到需要的状态,以及所有外围设备的设置(例如将纸张装入打印机)。尽管一些任务能自动执行,但某些方面通常需要人员参与。

环境支持工具(例如启用硬盘映像捕获和复原的工具)的使用在有效地管理此工作非常有价值。

设置执行工具选项
目的: 适当地配置在测试套件执行中使用的工具。

设置支持工具的执行选项。根据工具的复杂性,可以考虑许多选项。如果不适当地设置这些选项,可能会减小生成的测试日志和其他输出的有用性和价值。如有可能,您应尝试存储这些工具选项和设置,以便能根据一个或多个预先确定的概要文件方便地重新装入它们。对于自动测试执行工具的情况,可能要考虑许多不同的设置,例如执行的速度。

对于手动测试的情况,常常仅需要将问题或变更请求记录到跟踪系统中,或者对支持系统中的新的唯一条目进行分区,以记录结果。对于要作为写入目标的测试日志,您应考虑诸如名称、位置和状态之类的问题。

调度测试套件执行
目的: 确定测试执行适当的开始时间。

在许多情况下,在可以参与测试执行的场合,测试套件可以相对地按需执行。在这些情况中,调度时将可能需要考虑诸如其他测试员的工作、其他团队成员的工作,以及共享测试环境的不同测试团队的工作之类的注意事项。在这些情况中,测试执行通常需要解决很少发生的环境复位问题。

但是,对于需要无人看管执行自动测试的情况,或对于必须协调在不同的机器上并发运行的许多测试的情况,可能需要某种形式的自动调度机制。请使用您的自动测试执行工具的特性,或开发您自己的实用程序函数以启用必需的调度。

执行测试套件
目的: 进行测试套件中包含的测试,并监视其完成情况。

测试套件的执行情况会有所不同,这取决于测试是自动进行还是手动进行。对于每种情况,在测试实施任务期间开发的测试套件用来自动执行测试,或者指导测试的手动执行。

评估测试套件的执行
目的: 确定执行的测试套件是已完成还是异常中断,并进行评估,以确定是否需要纠正操作。

测试的执行在以下的任一情况下结束或终止:

  • 正常:所有测试按照计划执行完成。 
  • 异常或不成熟:测试未完全按计划执行。当测试异常结束时,从中得出后续测试结果的测试日志可能不可靠。需要确定异常终止的原因,并在必要时纠正故障并重新执行测试。
从中断的测试恢复
目的: 确定用于从中断的测试套件执行进行恢复的适当的纠正操作,并在需要的时候纠正问题,恢复和重新执行测试套件。

要从中断的测试恢复,请执行以下操作:

检查测试日志和其他输出 至“恢复中断的测试”

在测试日志和其他输出中检查完成度和精确度。标识已出错的地方,并检查它们。

当测试自动化正在部署时,要明确两类中断的测试,这很重要:

  • 致命错误 - 系统失败(网络失败、硬件崩溃等)
  • 测试失败 - 测试套件中测试的某部分不能按计划执行。

在测试执行期间发生任何一类异常行为时,它们可能呈现以下症状:

  • 测试套件正在执行时,出现大量(正在发生的)意外操作或意外窗口。
  • 测试环境显示为不响应、很缓慢或处于不希望出现的状态(例如挂起或崩溃)。

处理这些症状,直到您可以确定问题的根本原因。

纠正错误 至“恢复中断的测试”

错误可在测试消耗的输入数据中、测试本身中或测试的其他方面(例如测试环境或运行时工具设置)中找到。要对测试的某个方面的错误进行修正,通常需要提供测试所有常见方面的正确状态。

一旦完成了问题的调查,您可能会发现一个或多个需要纠正的故障。要对环境进行永久纠正,对数据或测试本身进行测试,一个不错的做法是在应用任何永久性纠正之前,将测试的每个方面再次复原到已知状态。这确保了没有其他不希望的或无效的更改能进入已知状态环境。

在进行了必要的更改之后,按需要保存测试和备份,或者保存伴随的输入数据和测试环境。

再次调度和执行测试套件 至“恢复中断的测试”

重新调度和执行测试套件。根据可用的恢复进程(如果存在),您能从中间某点重新启动测试套件,而不是一定要从开始启动。请注意,要从测试运行中途的某点恢复测试执行,通常需要某种类型的部分恢复过程的实施和持续维护。

重新评估测试套件的执行 至“恢复中断的测试”

确认测试套件现在朝着完成的方向运行。如果仍存在问题,则请对照组成“从中断的测试恢复”的子节再执行一遍,直到解决所有问题。

在测试日志中检查完成度和精确度
目的: 确定测试套件执行是否生成了有价值的测试信息,如果为否,则确定适当的纠正操作。

当测试执行首次完成时,应复审测试日志,以确保日志可靠,且(对测试目标的)外部影响(例如测试的不正确的环境设置或无效的数据输入)未造成报告的故障、警告或意外结果。

对于 GUI 驱动的自动测试,常见测试故障包括:

  • 测试验证故障 - 它发生于实际结果和预期结果不匹配时。请验证所用的验证方法只关注基本的项和/或属性,并在必要的时候进行修改。
  • 意外的 GUI 窗口 - 发生此情况有一种原因。最常见的原因是意外的 GUI 窗口是活动窗口,或者显示的 GUI 窗口的数目大于预期值。 确保测试环境已按计划进行设置和初始化,以正确地执行测试。
  • 遗漏 GUI 窗口 - 当 GUI 窗口预期会出现(但不一定是活动的)而又没有出现时,注明此故障。确保测试环境已按计划进行设置和初始化,以正确地执行测试。验证实际遗漏的窗口是否从/已从测试目标除去。

如果报告的故障是由于在测试工作产品中识别的错误引起的,或者是由于测试环境的问题引起的,则应采取相应的纠正操作,并应重新执行测试。

如果测试日志使您能确定故障原因是目标测试项中的真实故障,那么任务的执行部分已完成。

将测试环境复原为已知状态
目的: 确保测试套件执行之后正确地对环境复位。

(请参阅第一步)接下来您应将环境复原回其原始状态。通常除了诸如将纸张装入打印机之类的任务以外,这还将涉及到某种形式的基本环境复位(例如注册表和其他配置文件),将底层数据库复原到已知状态等等。尽管一些任务能自动执行,但某些方面通常需要人员参与。

维护可跟踪性关系
目的: 使得能对跟踪的项执行影响分析和评估报告。 

通过使用在测试计划中概述的可跟踪性需求,按照需要更新可跟踪性关系。一个不错的开始点是在度量特殊范围或测试覆盖方面考虑可跟踪性。作为一般规则,我们建议您将测试范围的度量基于您在测试计划活动期间发现的激发因素。

测试套件还可能跟踪至它们实现的已定义测试用例。它们还可能跟踪至需求元素、软件规范、设计或实施。

无论您已确定的要跟踪的重要关系是什么,您将需要更新在测试套件实施期间建立的关系的状态。

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

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

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

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



更多信息