BUG处理流程图

流程描述：

一、 测试人员发现bug提交给开发。

二、 开发人员判断是不是bug。

三、 若是是bug，进行修改，修改完成后更改bug状态为已解决。

四、 若是不是bug，退回给测试人员并描述退回缘由，或为设计如此，或为外部缘由，或者不能重现。

五、 开发人员修改完成的bug，由测试人员进行验证，确认修改正确，关闭bug。

六、 验证未经过的bug从新激活，开发人员继续修改，直至验证经过，关闭bug。

七、 测试人员须要对开发人员退回的bug进行确认。

八、 确认不是bug关闭。

九、 如与开发人员意见不一致，认为是bug，需提交项目负责人仲裁。

十、项目负责人确认是bug由开发人员修改，不是bug由测试人员关闭。

注：除提交项目负责人仲裁环节外，其余环节均可以在禅道上完成。

2、 各角色应关注的状态

1. 开发人员：激活、从新打开

激活：开发人员要对处于激活状态的bug进行处理，处理后将其状态置成“已解决”、“设计如此”、“没法重现”、“外部缘由”、“重复bug”或“延期处理”。

从新打开：从新打开的bug是已解决的bug通过测试人员验证，未修改正确，须要继续修改。

1. 测试人员：已解决、没法重现、设计如此、外部缘由、延期处理

已解决：测试人员发现状态为“已解决”的BUG，要及时验证，若是确实已解决，要将其置为“关闭”。不然“从新打开”

没法重现：测试人员发现状态为“没法重现”的BUG，要及时修改，把步骤描述清楚，并将其状态置为“从新打开”。

设计如此：测试人员发现状态为“设计如此”和“外部缘由”的BUG，要及时通知项目经理，由项目经理来决定是否修改；对“延期处理”的问题要进行按期跟踪，如发现问题没有按注释进行修改要及时通知开发人员或汇报给相关负责人。

1. 项目经理：设计如此、外部缘由、延期处理

设计如此：由于这些BUG都是测试人员和开发人员有争议的BUG，所以项目经理必须及时关注这些BUG，及时给出合理的定夺，若是不需修改把状态置成“关闭”，若是须要马上解决置成“从新打开”，不然置成“之后解决”。同时，项目经理也要关注“延期处理”的BUG，以避免其被漏掉或遗忘从而影响到项目上线。

3、 缺陷严重级别及类型定义

u 致命错误包括：

1． 形成系统崩溃、死机

2． 形成程序非法退出、死循环、通信中断或异常

u 严重错误包括：

1. 功能不符

2. 数据流错误

3. 程序接口错误

4. 密码明文显示

u 通常错误包括：

1. 界面错误

2. 打印内容、格式错误

3. 输入限制未放在前台进行控制

4. 删除操做未给出提示

5. 辅助说明描述不清楚

6. 显示格式不规范

7. 长时间操做未给用户进度提示

u 建议（非缺陷）

1． 修改后可得到更好的用户体验

4、 缺陷优先级定义

一、 高：致使测试暂停，没法进行；必须当即解决，优先级高于开发工做。

二、 中：致使部分功能没法测试；须要优先解决，解决周期2天。

三、 低：不影响测试的进行；可在方便时解决，解决周期3-5天。

5、 必须注意的问题

1. 开发人员不能直接关闭bug，关闭bug必须由测试人员完成。

2. 在进行问题处理的时候必需要添加注释，描述不是问题的缘由、之后解决的计划版本时间等等。

3. 你们在处理本身的问题时，即便这个问题不是本身的程序引发，也最好不要把问题置之不理，由于这个问题是在你这块表现出来的，到底哪里出问题应该比较清楚，跟其余相关人沟通相对比较容易，这样能够下降沟通成本，劲量作到“首位责任制”或“问题到此为止”

项目线上Bug处理流程