知识点：

1.缺陷生命周期中各角色的职责

2.缺陷的严重程度分类

3.缺陷优先级分类

4.缺陷的状态

什么是缺陷生命周期

缺陷从最开始被发现并提交，到缺陷被修复，最后被验证和关闭的过程称为缺陷生命周期。

缺陷生命周期中各角色的职责

测试人员：负责测试执行及缺陷跟踪，执行测试发现缺陷后提交到缺陷管理工具中，开发人员修改后需验证缺陷，确认缺陷修改是否正确，一般缺陷由谁提交就由谁来验证，因为提交缺陷的人最了解该缺陷被发现的过程，能更全面的验证该缺陷是否被修复。

测试组长：除了负责测试执行和缺陷跟踪外，还需要对测试人员提交的缺陷进行初步审查，保证提交的缺陷都是有效缺陷。

项目经理：对新建和重新打开的缺陷进行审核和分配，包括判定缺陷是否有效，设定缺陷解决的时效，给出修复方案的建议和意见。

开发人员：对分配给自己的缺陷进行判定及修复，同时对提交错误的缺陷具有拒绝修改的权限。

缺陷评审委员会：主要由项目经理、测试经理、质量经理、开发经理、资深开发人员和测试人员组成，他们主要对每一轮测试结束后遗留的缺陷进行确认，将其分配给相应开发人员进行修复，对有争议的缺陷进行仲裁.

缺陷的严重程度分类

缺陷严重程度：用于说明缺陷对软件系统的影响程度(站在用户的角度)，它和缺陷发生的可能性没有直接关系，缺陷影响程度越大，严重程度就越高。

缺陷严重程度分类：

致命：系统无法为用户提供服务，系统崩溃或意外退出，蓝屏，造成资源严重不足，数据丢失，或者软件失效造成人身伤害；

重大：会影响系统提供给用户的服务，比如系统重启或挂起，功能失效且没有其他可替代的方案，其他严重错误；

一般：功能已实现，但存在明显的错误；

微小：操作不方便，易使用户误操作，描述有歧义，显示格式不规范等；

建议：使用过程中可以提升用户体验的问题，或者后续可以新增加的功能；

缺陷优先级分类

缺陷优先级：用来评估缺陷处理的先后顺序，会随着项目的进展发生变化，通常是站在开发和测试人员角度进行考虑，确定优先级需要考虑技术问题、缺陷修复难度和风险、缺陷发生的频率、对最终用户的影响。

一般严重程度越高的缺陷优先级越高，严重程度越低的缺陷优先级越低；有时虽然缺陷严重程度高，但它只在某些特殊情况出现，或者修复该缺陷需要修改软件整体架构，从而引发更多缺陷，或者软件须尽快发布，此时该缺陷的优先级可能不高，甚至不需要处理；有时缺陷严重程度很低，如软件中出现的公司名称拼写错误，但也须立即修复，因为它关系到公司的形象，此时缺陷优先级就比较高。

缺陷优先级分类：

最高：业务流程阻塞，测试无法进行下去，这种缺陷必须立即修复；

高：缺陷严重，需要优先考虑的；

正常：缺陷正常等待修复；

低：缺陷可以在开发人员有时间时再修复；

最低：缺陷不影响软件的发布，但在发布前必须确认解决、推迟或不解决；

缺陷的状态

open：测试人员发现缺陷，确认该缺陷没有提交过(以免造成重复提单)，新建缺陷，状态为open，并指给项目经理(如果测试人员清楚该模块的开发人员，则可直接指给相应开发人员)；

assigned：项目经理将新建状态的缺陷分配给开发人员，状态为assigned；

not a bug：开发人员收到缺陷后检查该缺陷是否有效，若无效，则修改该缺陷的状态为not a bug，在comment中注明原因并返回给测试人员，测试人员确认后选择重新打开或关闭该缺陷；

won't fix：若开发人员认为该缺陷不需要修复，则修改状态为won't fix，注明原因并返给测试人员，测试人员确认后选择重新打开或关闭该缺陷；

duplicate：若开发人员认为该缺陷是一个重复缺陷，则修改状态为duplicate，关联重复缺陷返给测试人员，测试人员确认后选择重新打开或关闭该缺陷；

can't reproduce：当开发人员无法重现该缺陷时，则修改状态为can't reproduce，注明原因并返给测试人员，测试人员确认无法重现则关闭，否则需在comment中详述重现的环境、条件及步骤，必要时提供能复现该缺陷的环境给相应的开发人员，并修改状态为reopen；

pending：如果开发人员确认是问题，但因为它可能只在极端情况才出现，或需要对系统架构进行改动，或优先级低而暂时不需要修复，则可将状态改为pending，等待后续版本修复；

invalid：后续版本可能因为需求变更导致某些功能或模块不存在，或者之前的缺陷不存在了，则可修改状态为invalid；

need more info：如果该bug描述不完整，需要提供更多的信息进行定位，则修改状态为need more info，在comment中注明返回给测试人员，测试人员提供相应信息后reopen；

in progress：当开发人员认为该缺陷有效，需要修复，则修改状态为in progress，并开始分析缺陷，进行修复；

fixed：开发人员修复完缺陷后，修改缺陷状态为fixed，在comment中描述缺陷出现的原因，修复方法，影响范围，并指给测试人员或测试负责人；

wait for verification：测试负责人将缺陷指给测试人员时修改状态为wait for verification；

reopened：测试人员对已修复的缺陷进行验证，验证不通过，则修改状态为reopened，开发人员重新修复，直到缺陷验证通过；

closed：测试人员对已修复的缺陷进行验证，验证通过后，修改状态为closed。

免责声明：内容和图片源自网络，版权归原作者所有，如有侵犯您的原创版权请告知，我们将尽快删除相关内容。