缺陷生命周期(2)

发表于:2015-12-07来源:uml.org.cn作者:不详点击数: 标签:软件测试
记录:在缺陷总结阶段,需要对一些支持数据信息进行记录,例如:缺陷关闭时间、文档更新完成时间等。 分类:针对缺陷进行确认测试和相关的回归测

  记录:在缺陷总结阶段,需要对一些支持数据信息进行记录,例如:缺陷关闭时间、文档更新完成时间等。

  分类:针对缺陷进行确认测试和相关的回归测试以后,就可以将缺陷的状态进行分类,例如:关闭状态、延迟状态或者合并到其他项目中去等。

  确定影响:对在缺陷识别阶段、缺陷调查阶段和缺陷改正阶段中得到的影响分析进行合适的检查,并在需要的时候进行更新。

  表5列出了缺陷总结阶段的分类数据。

  表4 缺陷总结阶段的分类表

  5、案例

  本节介绍一个根据IEEE Std 1044-1993制定的缺陷生命周期案例,如图2所示。

  图2 缺陷状态转换图

  图2是某项目的缺陷生命周期中的缺陷状态转换图。下面分别从角色、状态、严重程度和优先级四个方面阐述该项目使用的缺陷生命周期。

  (1)相关角色

  测试人员:主要是指发现和报告缺陷的测试人员。通常情况下,测试人员需要对该缺陷后续相关的状态负责,包括回答相关人员对这个缺陷信息的询问,以及在正式版本上进行再测试和回归测试。

  开发人员:主要指对缺陷进行调查和修复的开发人员。注意在提交测试人员正式再测试之前,需要对修改后的缺陷在开发环境上进行验证。

  缺陷评审委员会:主要由项目经理、测试经理、质量经理、开发经理以及资深的开发人员、测试人员等组成。他们对缺陷进行确认,并将其分配给相应的开发人员进行修复,同时对有争议的缺陷进行仲裁。

  版本经理:负责将已经解决的缺陷相关的配置信息合并到新的版本。

  (2)缺陷状态

  新缺陷(New):软件中新发现的缺陷通常由测试人员提交。当然也可能是开发人员自己在组件测试或代码走读过程中提交,还有可能是从软件使用的最终用户或使用现场反馈得到的缺陷报告。具体缺陷发现的阶段包括:

  需求和设计阶段:文档评审过程中发现的缺陷。

  编码阶段:代码评审和代码静态分析过程中发现的缺陷。

  测试阶段:动态测试过程中发现的缺陷。

  使用阶段:用户反馈的缺陷。

  接受(Accepted):相关人员提交的缺陷报告,需要经过缺陷评审委员会的评审。缺陷评审通过后,将缺陷状态置为接受。缺陷评审委员会评审的主要内容包括:

  报告中描述的问题是否确实是一个缺陷。

  提交的缺陷报告是否符合要求。

  分配(Assign):将缺陷状态为接受的缺陷分配给相关人员进行问题定位和修复。相应的缺陷状态被置为分配。

  打开(Open):当缺陷处于打开状态时,说明开发人员已经开始对该缺陷进行修复。

  交付(Deliver):解决缺陷的方法已经找到,并且已经将修改后的代码等打上标签,交付给版本经理。

  解决(Resolved):版本经理将相关的标签等合入某个版本,交付给相关的开发小组进行验证,测试通过,则缺陷状态置为解决。

  已修改(Fixed):版本经理将已经解决的缺陷标签合入某个版本,交付给相关的测试小组进行确认测试,测试通过,则缺陷状态为已修改。

  结束(Closed):缺陷状态处于已修改后,缺陷评审委员会对整个缺陷修复过程进行评审,评审通过后将缺陷状态修改为结束状态。

  上面介绍的缺陷状态是在缺陷管理过程中主要的状态,或者是在缺陷处理顺利时所经历的状态。实际上,缺陷还有一些其他的状态,分别是:

  研究(Investigate):当缺陷分配给开发人员时,开发人员并不是都能直接找到相关的解决方案。开发人员需要对缺陷和引起缺陷的原因进行调查研究,这时候可以将缺陷状态改为研究状态。

  询问和回答(Query&Reply):假如负责缺陷修复的人员认为缺陷描述的信息不够明确,或希望得到更多与缺陷相关的配置和环境条件等,可以将缺陷状态改为询问和回答。

  拒绝(Declined):缺陷评审委员会通过讨论研究,认为提交的问题不是缺陷;或通过开发人员的研究分析,认为不是缺陷,开发人员可以将具体的理由加入到缺陷描述中,缺陷评审委员会据此将缺陷状态修改为拒绝。

原文转自:http://www.uml.org.cn/Test/201405223.asp