BUG处理流程图

流程描述：

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

2、开发人员判断是否是bug。

3、如果是bug，进行修改，修改完成后更改bug状态为已解决。

4、如果不是bug，退回给测试人员并描述退回原因，或为设计如此，或为外部原因，或者不能重现。

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

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

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

8、确认不是bug关闭。

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

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

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

二、各角色应关注的状态

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

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

  测试人员：已解决、无法重现、设计如此、外部原因、延期处理

已解决：测试人员发现状态为“已解决”的BUG，要及时验证，如果确实已解决，要将其置为“关闭”。否则“重新打开”

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

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

  项目经理：设计如此、外部原因、延期处理

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

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

u 致命错误包括：

1．造成系统崩溃、死机

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

u 严重错误包括：

u 一般错误包括：

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

   长时间操作未给用户进度提示

u 建议（非缺陷）

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

四、缺陷优先级定义

1、高：导致测试暂停，无法进行；必须立即解决，优先级高于开发工作。

2、中：导致部分功能无法测试；需要优先解决，解决周期2天。

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

五、必须注意的问题

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

   在进行问题处理的时候必须要添加注释，描述不是问题的原因、以后解决的计划版本时间等等。

   大家在处理自己的问题时，即使这个问题不是自己的程序引起，也最好不要把问题置之不理，因为这个问题是在你这块表现出来的，到底哪里出问题应该比较清楚，跟其他相关人沟通相对比较容易，这样可以降低沟通成本，劲量做到“首位责任制”或“问题到此为止”

项目线上Bug处理流程

巴特西