Bug流程管理规范

一、文档目的
作为质量管理体系的一部分，Bug管理对一个项目组是否具有规范化的流程显得尤其重要。

编写此文档的目的是为了完善项目组的Bug管理流程，提高Bug质量，帮助测试组和开发组进行更好的沟通。

此文档的阅读者包括开发人员、测试人员以及项目组管理人员。

二、Bug管理流程
为了更直观的阐述Bug管理流程，本文以流程图的方式来说明。

如下图：
Bug状态(Status)和解决状态(Resolution)的说明：
Status：
New——当测试人员新提交一个Bug, Bug的状态默认为New
Open——测试组长对新提交的Bug进行确认，如为有效Bug，Bug指给相关开发人员并且把Bug状态设置为Open
In Progress——开发人员确认为有效Bug，并且开始处理Bug时，修改Bug的状态为In Progress
Resolved——开发人员对Bug完成处理，把Bug状态设置为Check In，并且把Bug指回给开发人员进行验证
Reopen——开发人员已解决问题，测试不认同开发人员的解决方案时，将Bug重新打开Closed——当Bug已经确认被解决或者确认不是Bug的时候将Bug的状态设置为Closed Resolution：
Need More Information——需要更多信息。

当测试组长确认Bug，发现Bug描述不够详尽时，把Bug指回给Bug的Reporter，并且把Resolution项设置为Need More Information，对应的状态为Open；当开发人员处理Bug时，需要测试人员提供更多的Bug信息，把Bug指回给Bug的Reporter，并且把Resolution项设置为Need More Information，对应的状态为In Progress。

Invalid——无效。

测试组长确认Bug，发现该Bug无效时，把Resolution项设置为Invalid，对应的状态为Closed；当开发人员处理Bug，发现该Bug无效时，把Resolution 项设置为Invalid，对应的状态为Resolved。

Duplicate——重复。

测试组长确认Bug，发现该Bug和已有Bug重复时，把Resolution 项设置为Duplicate，对应的状态为Closed；当开发人员处理Bug，发现该Bug和已有Bug重复时，把Resolution项设置为Duplicate，对应的状态为Resolved。

Fixed ——已修复。

开发人员对Bug修改完成并且已经登记，等待测试人员确认，把Bug 指回给Bug的Reporter，并且把Resolution项设置为Fixed，对应的状态是Resolved；测试人员对Bug完成验证并且确认已修复，把Resolution项设置为Fixed，对应的状态是Closed。

Unable To Reproduce——无法复现。

被指派的开发人员对Bug进行修改但发现Bug始终不能再现的时候，把Bug指回给Bug的Reporter，并且把Resolution项设置为Unable To Reproduce, 对应的状态是Resolved；测试人员对Bug完成验证并且确认无法复现，把Resolution项设置为Unable To Reproduce，对应的状态是Closed。

Won’t fix——不准备修。

开发人员确认Bug有效但是不准备修改这个bug的时候，把Bug指回给Bug的Reporter，并且把Resolution项设置为Won’t fix，对应的状态是Resolved；测试人员对Bug完成验证并且确认Bug不需要修复的时候，把Resolution项设置为Won’t fix，对应的状态是Closed。

Suspended ——延期。

开发人员确认Bug有效但是在当前版本不准备修复该Bug，下个版本再提供解决方案的时候，把Bug指回给Bug的Reporter，并且把Resolution项设置为Suspended，对应的状态是Resolved；测试人员对Bug完成验证并且确认当前版本不准备修复该Bug时，把Resolution项设置为Suspended，对应的状态是Closed。

三、Bug的重要属性
每个Bug都会有相应的优先级（Priority），严重级别（Severity）和出现频率（Reproducibility），LIVE项目中所使用的级别定义如下。

Priority：
Immediate——需要立即进行修改
Urgent——紧急,一到两天之内必须进行修改
High——高优先级,将处于Immediate和Urgent优先级的bug修改完毕后要进行修改Normal——中等优先级
Low——低优先级,留到最后解决,如果项目的进度很紧张可以在产品发布以前不解决
Severity：
Blocked——系统崩溃，导致系统崩溃或死锁的错误
Serious——严重错误，严重地影响系统要求或基本功能的实现，且不能通过操作改善的（重新安装或重新启动该软件不属于改善办法）
Major——一般错误，一般影响系统要求或基本功能的实现
Minor——次要错误，使操作者不方便或遇到麻烦，但它不影响系统执行基本功能
Enhancement——建议，对某项功能点表象的修改建议，可改可不改，严重级别最低
Reproducibility：
Always——总是出现，每次尝试都会出现
Sometimes——有时出现，相对于Random的频率要高一些
Random——偶尔出现，相对于Sometimes的频率要低一些
Unable To Reproduce——不可重现，只发现一次，之后的尝试都无法再现
NOTE: 优先级与Bug自身的等级并不是完全一致的。

例如有些Bug属于严重级别的错误，但是却只是偶尔的出现一次，不影响软件的正常使用，这样的Bug的优先级可以适当的降低，而有些Bug虽然是不严重的错误，但是却是一直出现的，对软件的使用者造成比较大的困扰，这样的Bug就要根据情况适当的提高优先级。

即Bug的优先级可以认为是上面的Severity(严重等级)和Reproducibility(出现频率)的综合考虑。

四、注意事项
1. 开发人员原则上没有关闭Bug的权限，所有的Bug必须要由测试人员验证之后才能关闭，包括Won't Fix，Invalid，Duplicate，Unable To Reproduce，Suspended的Bug。

2. 开发人员把Bug设置为Won't Fix和Suspended之前，必须经过项目经确认，必要时需要和客户进行沟通。

3. 原则上允许Invalid的Bug存在，但是为了提高Bug的质量，在新建一个Bug之前，要对Bug进行充分的验证，确保其有效性。

4. 原则上允许Duplicate的Bug存在，但是为了提高Bug的质量，在新建一个Bug之前，要对已有Bug库进行检索，确保该Bug不会被重复提交。

5. 所提交的Bug必须包含必要且尽可能详细的信息，以便于开发人员更快的定位Bug及修复Bug。

包括Bug复现需要的步骤，具体的错误信息及截图，Bug所产生的环境，期望结果及预期结果。