一、文档目的

作为质量管理体系的一部分，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所产生的环境，期望结果及预期结果。