任务:确定测试构想
此任务描述了如何识别每种激发因素和目标测试项组合的相关测试构想。
规程:测试
用途

此任务的目的是:

  • 识别应进行探索的测试构想,以对目标测试项的质量是否可接受进行评估
  • 识别足够多的构想,以根据测试激发因素对目标测试项进行足够的验证。
关系
步骤
识别相关测试激发因素和目标测试项
目的:  理解驱动当前迭代的测试工作的关键激发因素,并考虑它们如何与一个或多个目标测试项相关。 

通过使用迭代测试计划,复审测试激发因素。激发可能来自任意数量源中的一个:个别工作产品、一组工作产品、一个事件或活动、或者缺少任何这些事物。源可以包括:风险列表、变更请求、用例、其他需求工作产品和 UML 模型等等。

对于测试构想列表,只包含一个涉及单个源需求验证的条目是不够的。列表上当然会有一个条目,但格式良好的测试构想列表除了验证是否符合规范之外,还尝试在许多其他方面就给定的目标测试项的质量提出建议。

检查相关的可用测试构想目录
目的:  通过利用被证明当前存在的测试构想,启动测试的识别。 

使用任何可用的测试构想目录或其他已建立的指南,来识别测试的初始构想。

通过头脑风暴想出其他测试构想
目的:  生成其他测试构想。 

鼓励其他测试团队成员另外再贡献测试构想 - 可以考虑在“公务”午餐上非正式地进行此活动。为了模拟会话,您可能要阅读以下各项的选定摘要:测试日志、已出版的书籍或来自测试团体邮件列表的相关邮件。

通常这样做是有用的,尤其是在以下场合更显有用和重要,即没有现存测试构想构想目录可供参考的时候。关于进行头脑风暴活动并提炼构想的进一步指南,请参阅该页标题表的“更多信息”部分。

列出候选测试构想
目的:  从适当的候选者中进行选择,以包含在“测试构想列表”中。  

对于测试激发因素和目标测试项的每个组合,列出是潜在候选者的测试构想。

优化测试构想列表
目的:  进行进一步的修订和改进。 

收集更广泛的反馈取样是值得的。将您的列表显示给感兴趣的开发人员、客户代表和其他项目干系人,这些项目干系人可能要添加更多的构想。

在此阶段,无需担心构想太多,多要比少好。只需通过添加所有附加条目来优化列表,然后除去任何明显重复的条目。

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

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

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

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

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

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



更多信息