（1）相关角色

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

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

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

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

　　（2）缺陷状态

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

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

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

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

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

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

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

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

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

　　打开（Open）：当缺陷处于打开状态时，说明开发人员已经开始对该缺陷进行修复。

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

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

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

　　结束（Closed）：缺陷状态处于已修改后，缺陷评审委员会对整个缺陷修复过程进行评审，评审通过后将缺陷状态修改为结束状态。

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

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

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

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

　　重复（Duplicated）：缺陷评审委员会认为该缺陷和某个已经提交的缺陷描述的是同一个问题，可以将该缺陷状态设置为重复。

　　延期（Deferred）：缺陷不在当前版本解决。

　　无计划（Unplanned）：在用户需求中没有要求或计划。

　　（3）严重程度

　　缺陷的严重程度指的是假如缺陷没有修复时，软件缺陷对软件质量的破坏程度，即此软件缺陷的存在对软件功能特性和非功能特性产生的影响。缺陷的严重程度关注的是缺陷引发的问题对客户的影响程度。在给缺陷确定严重程度的时候，应该从软件最终用户的角度进行判断，即根据缺陷会对用户使用造成的影响程度来确定。软件缺陷的严重程度和缺陷发生的可能性没有直接的关系。一般而言，缺陷的影响越大，缺陷的严重程度越高。下面是该项目的缺陷严重程度的分类，缺陷的严重程度被分为四个等级。