任务:分析测试故障
此任务着重于有效查找、隔离和诊断测试故障,并记录这些故障。
规程:测试
用途

此任务的目的是:

  • 调查“测试日志”的详细信息,并分析测试实施和执行期间发生的故障
  • 更正因测试过程中出错而产生的故障
  • 相应地记录重要的调查结果
关系
步骤
检验测试日志
目的 整理并理解来自所执行测试的输出。 

首先收集在实施和执行测试期间的测试日志输出。相关的日志可能有许多来源,它们可能由您使用的工具(测试执行工具和诊断工具)捕获,由您的团队制定的定制编写例程生成,由目标测试项自行输出,以及由测试人员手动记录。收集所有可用的测试日志源并检验它们的内容。检查所有已安排的测试都执行完成,并且所有测试都安排在适当的时间。

捕获重要的事件数据
目的 记录后续调查中出现的所有异常的、重要的事件。 

重要的是捕获任何异常的事件,即使您现在不能复制或解释它们,随后具有类似症状的事件最终会提供足够的信息来帮助查出它们幕后的问题。

现在记录尽可能多的详细信息,但指出该事件尚未得到解决。

确定测试中的过程错误
目的 从事件日志中消除测试流程中的人为错误和其他过程及流程错误。 

许多故障都是因为在测试实施期间或测试环境的管理中发生错误而引起的,这是很普通的事。请确定并更正这些错误。

如果测试完成但有异常,阻止了其他测试的执行,您可能需要将测试恢复到靠近故障点处并继续执行剩余的测试。

查找并隔离故障
目的 确定故障发生的位置,从故障分析中消除非故障源的“目标测试项”。 

您执行的故障诊断越多,就越有可能最终确定并理解该故障。

努力通过消除不可能涉及到故障的目标测试项来查出故障,并查找剩余项中的趋势和特征、系统状态等。

如果故障不经复制就无法调查,则通过在受控情况下复制故障来开展故障分析。如有作用,则使用诊断工具和调试工具。

诊断故障症状和特征
目的 捕获有用的故障分析,以便确定和解决故障。 

尝试使用以前发生过的类似事件的经验来诊断底层故障。

如果需要并且可用,征得开发人员的援助,利用开发人员的内部软件知识改进故障分析。

确定候选解决方案
目的 使负责解决故障的人员更好地理解故障的性质和影响,并通过提供可选择实施的可行建议来协助开发人员。 

关于编写有效事件报告和“变更请求”的信息,请参阅任务:确定测试结果 - 创建和维护变更请求

相应记录调查结果
目的 以适当方式向负责解决故障的人员提出您的故障分析。 

关于编写有效事件报告和“变更请求”的信息,请参阅任务:确定测试结果 - 创建和维护变更请求

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

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

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

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



更多信息