任务:确定测试目标
此任务描述了如何确定需要测试的个别系统元素,包括硬件和软件。
规程:测试
关系
步骤
确定将实施什么软件
目的 了解开发团队在即将来临的调度中的主要可交付件。 

通过使用迭代计划和其他可用源,确定开发团队计划为即将来临的迭代生成的个别软件项。如果开发工作分发到位于不同位置的团队,则您可能需要直接与每个团队讨论开发计划。请进行检查,以查明是否有任何转包的开发,并使用任何对您可用的渠道收集转包商开发工作的详细信息。

对于新软件,还应注明基础结构和共享组件的更改。这些更改可能影响在先前的开发周期内生成的其他从属的或关联的软件元素,从而有必要测试这些更改对上述元素的影响。出于类似的原因,对于开发工作打算利用的第三方组件,您也应确定任何更改或添加。 这包括共享组件、库或公用代码库、GUI 窗口小部件、持久性实用程序等等。 复审软件体系结构,以确定使用中的什么机制可能受到第三方组件更改的影响。

确定要测试的候选系统元素
目的 确定测试工作应试验的目标项。 

对于每个已确定的测试激发因素,检查要作为此开发周期的一部分交付的软件项列表。生成一份初始列表,其中排除在满足测试激发因素方面不能被证明为有用的所有项。请记住包含商业软件,以及要直接由项目开发小组开发的软件。

您还需要考虑各种不同的目标部署环境对于要测试的元素的影响。您的候选系统元素列表应扩展为包含正在开发的软件和目标环境的候选元素。这些元素将包含硬件设备、设备驱动程序软件、操作系统、网络和通信软件、第三方基本软件组件(例如电子邮件客户端软件、因特网浏览器等)。它们还包含与所有这些元素的可能组合相关的各种配置和设置。

如果您已确定了重要的目标部署环境,您应考虑通过创建或更新一个或多个概述的测试环境配置来记录此信息;该概述应提供名称和简要描述,并枚举配置的主要需求或特性。避免在这些概述上耗费太多时间;需求和特性列表随后将在任务:定义测试环境配置中详述。

优化候选目标项列表
目的 从测试工作计划中删除不必要的目标,以及向该计划添加遗漏的元素。 

通过使用与评估项目干系人达成一致的测试工作的评估任务和范围,检查目标项列表,并确定不满足评估任务并明显位于测试工作范围之外的项。

作为相对性检查,以批评的眼光再次检查各项,并质问优化的目标项列表是否真的满足评估任务和测试工作范围。可能需要向目标项列表添加其他元素,以确保完成评估任务所需的适当范围和能力。

定义目标项列表
目的 传达就将要开展的工作的目标测试项所制定的决策。 

决定了目标测试项之后,您需要将自己的选择传达给测试团队和测试工作中的其他项目干系人。可以论证,最常见的方法是将关于测试项的决策记录在迭代测试计划中。

备选方法是简单地将此信息记录为某种格式的表或电子表格,并利用它管理工作和职责分配。在测试实施和执行期间,个别测试员将利用此信息来制定战术决策,这些决策关于要实施的特定测试,以及要捕获与这些目标项相关的哪些测试结果。

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

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

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

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



更多信息