软件产品缺陷生命周期(2)

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

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

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

　　表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