任务:定义评估和可跟踪性需要
此任务描述了如何定义评估和可跟踪性需求,以及将遵循的整体策略。
规程:测试
关系
步骤
确定评估和可跟踪性需求
目的 了解软件评估流程的可交付件,并抽出关联的需求。 

复审迭代计划并确定这个即将来临的工作主体的特定评估需要。向项目干系人询问他们的评估和可跟踪性要求。

同时,考虑是在测试工作期间还是在测试工作结束时正式审计测试工作。正式的审计需求可能需要保留附加的文档和记录,以证明已经进行了足够的测试。

考虑约束
目的 确定将影响实施需求的能力(或必要性)的约束。 

尽管通常会有无尽的“需求”吸引您将其作为可跟踪性和评估策略的需求,但重要的是您应该注重最重要的“需求”:a)向项目团队提供基本信息;b)可以实际跟踪与评估。您的策略不太可能有足够的可用资源,来满足超过基本需要的需求。

子主题:

可接受的质量水平 回到页首

确定何等质量水平将被视为“足够好”并制订适当的评估策略,这是很重要的。请注意,在整个项目生命周期内,通常质量维度在重要性方面是有起伏的,并且项目干系人会看到质量水平有起有落

复审 QA 计划,复审软件开发计划并直接与重要的项目干系人本人会谈,以确定他们所考虑的将是可接受的质量水平。

流程和工具支持 回到页首

尽管您可能设想在低级别细分情况下毫不费力的跟踪和评估的世界,但现实是,实施此类方法是困难的,而且通常是不经济的。尽管有完善的工具支持,管理低级的跟踪方法仍可能是困难而耗时的;如果没有支持的工具,那几乎是不可能的。软件工程流程本身可能对可跟踪性有约束:例如,如果需要通过测试可跟踪性来激发需求,但是这些需求本身未受到细心管理,那么就可能无法实施此可跟踪性。

考虑软件工程流程和工具的约束和局限,并相应地选择适当的、可行的跟踪和评估方法。

考虑可能的策略
目的 确定并概括将促进所需评估流程的一个或多个策略。 

既然您更好地了解评估和可跟踪性需求,并更好地了解所需的质量水平以及可用的流程和工具支持对这些需求的约束,您就需要考虑可能采用的可能评估策略。关于可能策略的更详细论述,建议您阅读 Cem Kaner 发表于 2000 年 10 月的论文“Measurement of the Extent of Testing”。(获取 Adobe Reader

子主题:

测试覆盖率分析 回到页首

有许多测试覆盖的不同方法,没有一个覆盖度量可以自行提供组成测试工作范围或完整性评估所需要的所有覆盖信息。请注意,实施不同的覆盖策略所需要的精力也是不同的,使用任何特定的度量类别,通常会有某个覆盖分析深度,在该深度记录更详细的信息将变得不经济。

某些类别的测试覆盖度量包括:需求、源代码、产品声明和标准。建议您考虑在您的测试评估策略中纳入多个覆盖类别。在多数情况下,测试覆盖指的是第一种情况下特定测试的计划和实施。但是,测试覆盖度量值及其分析也可用于与测试结果或缺陷分析一起考虑。

测试结果分析 回到页首

测试结果分析的一个常用方法是简单地引用正面或负面的结果数(作为所运行的测试总数的一部分)。我们的观点和测试团体中其他工作人员的观点是,这是一个分析测试结果的过分单纯化且不完整的方法。

相反,建议您根据相对趋势随着时间的变化来分析您的测试结果。在每个测试周期中,考虑测试故障的多维相对分发,如正在测试的功能领域、正在探索的质量风险类型、测试的相对复杂性和应用于每个功能领域的测试资源。

缺陷分析 回到页首

尽管缺陷本身显然与测试工作的结果相关,缺陷数据的分析并不提供关于测试工作进度或该工作完整性或全面性的任何有用信息。但是,有些测试团队和项目经理所犯的错误是,使用当前的缺陷计数来度量测试的进度或作为度量所开发软件的质量的标尺。我们的观点和测试团体中其他工作人员的观点是,这是一个毫无意义的方法。

相反,建议您分析缺陷计数随时间变化的相对趋势,以提供相对稳定的度量。例如,假定测试工作保持相对稳定,您通常会在迭代过程中看到针对固定时间段“钟形曲线”度量的新缺陷发现率;发现率增长到峰值,然后随着迭代结束而下降。但是,您将需要结合对其他缺陷度量值的分析来提供这些信息,例如:缺陷解决率(包括对解决类型的分析);缺陷的严重性分发;缺陷的功能领域分发。

在完善的工具支持下,您可以比较容易地执行对缺陷数据的复杂分析;没有适当的工具支持,这个事情就困难多了。

与项目干系人讨论可能的策略
目的 通过初始项目干系人复审来收集反馈,并在必要时调整策略。 

向各个项目干系人展示可能的策略。通常,您希望这会包括一个由以下角色组成的小组:项目经理、软件设计人员、开发经理、系统分析人员、配置与变更经理、部署经理和客户代表。 这些角色中的每一个都对如何评估有项目干系人行为。

根据项目的文化,您应选择适当的形式展示可能的策略。其范围可以是一次或多次非正式会议到正式的展示或小组研讨会。

定义评估策略并达成一致
目的 就即将使用的策略与项目干系人达成共识。 

采纳从讨论中得到的反馈,并将评估策略优化为针对所有项目干系人的需求的单一策略。

展示评估策略,以获得最终同意和批准。

定义工具需求
目的 定义将实现评估流程的支持工具配置需求。 

如上所述,在完善的工具支持下,您可以比较容易地执行对度量数据的复杂分析;没有适当的工具支持,这个事情就困难多了。

对于以下类别,考虑您将需要什么工具支持:覆盖和可跟踪性、缺陷分析。

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

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

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

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



更多信息