任务:定义可测性元素
此任务描述了如何确定将支持和启用测试的元素。
用途

此任务的目的是:

  • 确定支持目标测试项所需的元素
  • 确定在每种测试环境配置下启用测试所需的测试实施基础结构的实际元素
  • 定义使软件可以进行实际测试所需符合的软件设计需求
关系
步骤
对于每个必需的目标测试项,确定与测试机制的关系
目的:  理解目标测试项所需要的测试机制支持。

对于每个目标测试项,复审测试机制的列表并确定可提供支持的测试机制。分析所选的测试机制有多么接近提供完整的测试解决方案以及可如何改编它们以提高适用性。如果找不到任何候选项或改编工作量很大,则定义新的测试机制并尝试在专用性和可重用性之间寻求平衡。

确定系统的动态元素和事件
目的:  理解系统的动态和运行时方面。 

使用可用的软件需求和设计信息,确定系统的动态元素和事件。使用用例、设计、实施和部署模型,您可以确定诸如控制类、流程、线程和事件之类的相关项。首先研究构造型为 <<control>> 的类、用例实现和流程体系结构视图中描述的元素,或构造型为 <<process>> 或 <<thread>> 的实施模型。

对照测试环境强加的约束,定义实际需求

确定系统边界和接口
目的:  理解系统作为服务供应者的职责以及系统作为客户端的依赖关系。 

要检验的另一组有用元素是系统的接口,最重要的是与系统边界以外的参与者相关的那些接口。使用设计模型和实施模型,查找使用构造型 <<interface>> 定义的元素。同时检查模型中是否存在构造型为 <<boundary>> 的类。

作为测试人员,探索过去的这些系统边界以理解相关系统(既是客户端又是服务供应者)的期望是很有用的。这将使您更彻底地理解在接口验证方面以及在测试和可能模拟这些接口所需的测试基础结构方面需要什么。

确定测试基础结构元素
目的:  确定将使所需测试得以执行的测试工作基本元素。 

要使迭代测试工作取得成功,重要的是确定并维护适当的基础结构。 如果没有基础结构来帮助维护,测试工作很快就会变得无法维护并无法使用。尽管测试基础机构与自动化测试工作的相关性更明显,但它对手动测试工作也是一个重要问题。

考虑系统中的动态元素和事件;它们将对各个测试的实施造成哪些影响?寻机分解各个测试之间的依赖关系,并通过提供间接层的公共控制点来管理它们。可探索依赖关系的常见领域包括测试导航、测试数据使用和系统状态变化。

使用您已收集的信息,考虑哪些需求将控制测试基础结构,以及它将需要提供哪些工具来实现成功的测试方法。

子主题:

促进公共测试场景 回到页首

当执行测试时,有些测试对遵循的场景或过程有一个公共结构,但同一过程需要针对不同测试目标项执行多次。在测试自动化的情况下,创建可在许多不同环境中重用的公共测试脚本或实用程序功能以高效执行这些公共测试场景可能是很有用的。如果测试场景需要改变,这可以提供一个中心修改点。示例包括对适当的接口元素类执行标准边界测试,以及验证 UI 元素是否服从 UI 设计标准。

促进测试数据依赖关系 回到页首

当要在给定的测试环境配置下执行测试时,使用的测试数据值中可能会发生冲突。当环境由多个测试团队成员共享时,这个问题就更严重了。考虑使用数据驱动法将测试数据值与使用它们的测试脚本分开,并提供一个测试数据收集和修改中心点。这会提供两种主要好处;它使所有测试团队成员都可看见测试数据,允许他们避免测试数据使用中的潜在冲突,并且在数据需要更新时,它为测试数据提供一个中心修改点。

促进测试状态依赖关系 回到页首

多数测试执行之前都要求系统处于特定的给定状态,并应在完成之后使系统回到特定的已知状态。常见的依赖关系包括安全权限(功能或数据)、动态数据或环境相关数据(例如,系统日期、订单号、用户标识首选项等)、数据有效周期(例如,安全密码、产品过期等)。有些测试是彼此高度相关的;例如,一个测试可能创建唯一的订单号,随后的一个测试可能需要分派同一个订单号。

常见的解决方案是使用测试套件以正确的系统状态顺序将相关的测试排序。然后,测试套件可以与相应的系统恢复和设置实用程序配合使用。对于自动测试工作,一些解决方案可能包括使用集中的动态系统数据存储和在测试脚本中使用那些引用集中化信息的变量。

Facilitate derived test data values To top of page

测试有时需要从运行时系统状态的一个或多个方面计算或推导相应的数据值。这同时适用于输入和预期结果的测试数据值。考虑开发实用程序来计算得出的数据值,简化测试执行并消除因人为错误而造成的潜在错误。在可能的情况下,开发这些实用程序以使它们可供手动和自动测试工作运用。

促进公共测试导航路径 回到页首

对于测试自动化,您应考虑分离出共有的导航顺序并使用集中的实用程序功能或测试脚本实施它们。然后这些共有导航顺序就可以在多处重用,如果随后发生导航更改时,这些顺序就提供了一个中心修改点。这些共有的导航辅助功能只是点到点地导航应用程序;它们自己通常不执行任何测试,而是验证它们的开始状态和结束状态。

确定特定于测试的设计需要
目的:  确定可能会限制软件工程流程、软件体系结构和相应的设计与实施的测试规程需求。 

尤其在涉及测试自动化时,测试实施和评估需求可能会限制到开发团队制定软件工程流程的方式以及软件的体系结构和设计。重要的是软件开发团队不会过分纠缠于核心开发工作,并且测试团队有能力执行必要的测试。关于向开发团队展示测试团队需求的信息,以及关于查找满足所有规程需要的有效解决方案的信息,请参阅任务:获得可测性承诺

使用您已收集的信息,考虑测试工作将对开发工作提出哪些需求。

子主题:

确定测试接口 回到页首

考虑确定的接口;是否有测试工作需要的其他需求包含在了软件设计中并且在随后的实施中公开出来?在有些情况下,将特别需要其他接口来支持测试工作,或者现有的接口将需要其他操作模式或修改过的消息属性符(更改输入参数和返回参数)。

对照目标部署环境(在测试环境配置中所捕获的)和开发时间表本身,确定对测试工作产生的约束和依赖关系。为了测试起见,这些依赖关系可能需要提供存根以模拟那些将不提供或由于过于限制资源而无法建立的环境元素,或提供机会较早地测试部分完成的系统的组件。

确定内置测试功能 回到页首

有些测试可能很有价值,但实施起来过于昂贵,如同真正的黑匣测试。 而且,在高可靠性环境中,重要的是能够尽快测试和隔离故障以快速解决故障。在这些情况下,将测试直接构建到可执行软件本体内可能很有用。

可以采取不同的方法实现这一任务;两种最常见的方法包括:内置自测试,其中软件使用多余的处理周期执行完整性自测试;还有诊断例程,可以在向软件发送诊断事件消息时执行,或当系统配置为启用诊断例程后运行时执行。

确定测试设计约束 回到页首

开发团队的有些设计和实施选择将会支持或禁止测试工作。尽管其中有些选择不可避免,有许多较小的决策(尤其在实施领域)对开发团队影响很小,但对测试团队则影响很大。

要考虑的领域包括:使用经认可的标准通信协议;使用可由测试自动化工具识别的 UI 实施组件;服从 UI 设计规则,包括 UI 元素的命名;统一使用 UI 导航约定。

定义软件可测性需求
目的:  指定支持测试实施和执行所需要的软件功能的需求。 

使用先前对该任务执行的工作,定义软件设计和实施中应考虑的、特定于测试的需求和约束。

向开发团队说清楚为什么要将测试特定功能构建到软件中的原因,这很重要。主要原因通常将归为以下方面:

  • 通过在目标测试项和手动或自动测试之间提供一个接口,使测试得以实施(手动或自动)。通常作为一个测试自动化问题,这是最为相关的,可帮助克服测试自动化工具在访问软件应用程序以获得信息输入或输出方面的局限性。
  • 使开发的软件本身可以执行内置自测试。
  • 使目标测试项可以从所开发系统的其余部分中隔离出来并得到测试。

内置在软件中的测试特定功能需要在内置测试功能的价值及实施和测试它所需的工作之间努力寻求平衡。内置测试功能的示例包括生成审计日志、自诊断功能和用以查询内部变量值的接口。

另一种测试特定功能的常见使用是在集成工作过程中,这种情况下需要为尚未实施或合并的组件或子系统提供存根。用于存根的实施风格主要有两种:

  • 只作为“哑元”,并且除了能够提供特定的预定义值作为输入或返回值之外没有任何其他功能的存根和驱动程序。
  • 更加智能并可“模拟”或接近更复杂行为的存根和驱动程序。

存根的这第二种风格还提供将组件或组件组与系统其余部分相隔离、从而灵活地实施和执行测试的强力方式。与较早时候关于测试特定功能的说明一样,需要考虑复杂存根的价值与实施和测试存根所需工作之间的平衡。请谨慎使用第二种风格,这有两个原因:其一,实施起来需要更多资源;其二,更容易忽视存根的存在并忘记在随后删除它。

直接根据设计和实施模型的测试特定需求、或使用一个或多个测试接口规范来记录调查结果。

定义测试基础结构
目的:  指定支持测试实施和执行所需的测试基础结构。 

使用先前对该任务执行的工作,定义支持测试实施和执行所需要的测试基础结构。

记住,您正在定义基础结构的实施特性;主要目标是定义解决方案中将实施该基础结构的各个部分。

子主题:

测试自动化元素 回到页首

测试自动化基础结构的主要需求或功能包括:

  • 导航模型:常见方法是往返式、分段式或混合方法。其他备用方法包括使用“操作/单词”框架或屏幕导航表
  • 外部数据访问:一种从外部访问测试指令的数据的方法
  • 错误报告和恢复:常见的错误处理例程和测试套件恢复执行包装器
  • 安全和访问概要信息:自动测试执行用户标识
  • 软件执行自测试的能力

将您的决策作为定义记录在“测试自动化体系结构”的实施部分,作为流程指导信息记录在一个或多个“测试指南”中,或记录为测试脚本、测试套件或测试库实用程序例程。关于进一步的建议,请参阅工作产品:测试自动化体系结构

手动测试元素 回到页首

手动测试基础结构的主要需求或功能包括:

  • 测试数据存储库:测试数据定义的一个公共存储库。
  • 复原和恢复:一种将测试环境配置恢复为已知状态的方法。
  • 使目标测试项可以从所开发系统的其余部分中隔离出来并得到测试。

将您的决策作为流程指导信息记录在一个或多个工作产品:特定于项目的指南中。

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

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

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

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



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