任务:定义测试明细
此任务描述了如何详述由目标测试项驱动的特定环境中的测试构想。
规程:测试
用途

此任务的目的是:

  • 定义在特定环境中实现某一测试构想所需的各个条件
  • 确定相关测试项的潜在观察点和控制点
  • 确定促进观察点的潜在预测
  • 提供用于支持测试的可消耗资源
关系
步骤
检验目标测试项和相关的测试构想列表
目的 基于可能的测试构想,更详细地理解“目标测试项”。 

使用测试观点列表作为环境,检验关于目标测试项的可用信息。除了任何补充规范、业务规则和设计工作产品之外,用例和相关的工作产品(例如,用例实现、用例故事板和用例场景)通常都是很好的开头来源。

可用的信息有限时,您可能需要直接与开发人员讨论目标测试项。

选择测试构想的一个子集进行详述
目的 确定要定义的可管理测试(这些测试在当前环境中最有益处)子集。 

复审测试观点列表并选取一些测试观点,您将针对这些测试观点设计详细的测试。在多数情况下,您将基于时间约束、测试观点与当前测试周期的相关性、目标测试项的完整性等等来选取一部分测试观点。根据您所处情况的特定环境,在当前测试周期内,您实际放入设计中的测试观点数是因案例而异的。

建议您避免为第一次从给定的测试观点列表中设计的所有测试观点进行设计。相反,采用递增和迭代法处理测试观点列表,将您的精力专注于您认为最可能对给定测试周期产生有用的评估信息的少数观点。这有助于减少将过多时间花在一个目标测试项而疏忽其他测试项的风险,并使为稍后可能证明没什么人关注的测试观点进行设计耗费精力的风险降至最低。

对于每个测试构想,设计测试
目的 定义要从“测试构想”列表得出的每个测试的关键特征。 

使用您至今为止收集到的信息,通过确定和定义实现测试所必需的主要特征来设计测试。请注意,生成的测试设计可以不同方式捕获:
  • 传统上,测试设计是作为工作产品:测试用例捕获的。
  • 工作产品:工作负载分析模型在概念上是特别与系统性能测试相关的一种专门而更复杂的测试用例形式。
  • 根据测试的复杂性和项目文化,直接将测试作为工作产品:测试脚本来实现可能是合适的,如果您可以接受不创建“测试用例”工件,则应考虑使用此方法。如果您采用此方法,则务必在字面上使用有用信息注释您的测试脚本,说明该测试有用的原因。使用这些注释可充当非正式的、直接插入的测试用例。

使用您已收集的信息,考虑该测试的以下每一方面。

确定输入、输出和执行条件

从“黑匣”角度考虑测试,确定定义测试的主要外部可视特征。确定促进测试将需要哪些输入信息,以及预期生成哪些输出信息。同时枚举主要执行条件 - 对于该步骤,不必说明或理解执行条件的“具体方式”。

请注意,输入信息和预期输出信息的范围将(取决于特定测试)从简单的数据类型值(例如,“A”、“1”)到复杂的多维数据(例如,声音剪辑、对象)。最好在特定输入或预期输出信息背后定义一个限定符,而不是只给出具体的值。这就使随后实施或执行该测试者有必要地理解测试数据背后的推理,允许他们选择在任何给定的执行中改变测试的替换值和替代值。

确定候选观察点

观察点是测试执行期间您想用以观察测试环境状态的某一方面的一个点。假设您了解执行条件及输入和预期输出信息,则确定在测试执行期间应观察哪些特定点,并确定应观察数据的什么性质。

确定候选控制点

控制点是测试执行期间您想要就测试的控制流从多个选项中做出决定的一个点。 调查可用的测试场景,并针对每个场景考虑在多次执行测试时控制变化的点。整理所有不同的控制点,并将列表缩减为当前测试周期所需要的那些控制点。

确定适当的测试预测

测试预测将要测试的预期输出值与这些值的拆分方式组合起来:它既是给出的响应,也是给出响应的介质。例如,要验证某一字处理软件包中使用的字体的精确表示,可以使用打印预览为介质来验证字体样式。测试预测确定了对照预期结果来验证测试实际结果所需要的形式方面和功能方面。

定义所需的数据源、值和范围
目的 定义所需的“测试数据”值,包含该数据的相应数据源。 

如前所述,测试数据有许多外形和形式。

当出现数据互相依赖的复杂情况时,尝试使用“领域专家”来指定适当的测试数据条件。有些测试生产力工具提供了支持简化生成测试数据集的功能或实用程序。

获得消耗型测试数据的充足来源
目的 获得用于支持测试的有效测试数据的充足来源,并记录这些数据。 

精确生成或整理适当的测试数据,这是定义测试时最辛苦也最耗时的任务之一。当系统为数据密集型系统时,尤其如此。

建议使用 Microsoft® Excel® 或具有表格式数据管理界面的其他产品(例如 Microsoft® Access®)记录“测试数据”。

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

通过使用在测试计划中概述的可跟踪性需求,按照需要更新可跟踪性关系。

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

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

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

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



更多信息