BUG修复流程

整个流程分为两大类：测试环境和线上环境。

把两种环境又分为两种情况：web和Java、APP。

所有bug，被指派的开发人员在两个小时确定。不是自己的bug，找各组leader，另行指派。

线上发现Major以上bug，停下手头工作，两个小时以内进行解决。

若bug3天之内没有修复完成，请点解决，解决方案选择“延期处理”，并备注原因，说明解决时间。

bug级别

严重程度由高到低依次为：

1.critical

2.block

3.major

4.normal

5.minor

critical：是说项目中某一块功能因为这个bug而导致测试无法进行下去，此critical级别，该等级问题出现在不影响其他功能测试的情况下可以继续该版本

block是说项目中有闪退情况，崩溃情况。此为block级别，出现这种级别的问题此版本停止测试

major：是说一些功能没有实现，但是不影响使用，功能菜单缺失，但不会影响系统稳定。此为major，这种问题应该合理安排时间进行修改

normal：是说界面等UI问题显示错误，比如字体大小，颜色，间距等问题。此类问题在测试初期较多，优先程度较低；在测试后期出现较少，应及时处理）

minor：是说界面、性能缺陷，建议类问题，不影响操作功能的执行，可以优化性能的方案等。

测试环境

web、Java

1、测试人员发现bug

2、测试人员确认bug

3、测试人员提交bug（major以上@相关人员）

4、相关开发人员禅道确认bug

5、开发人员对bug进行修复

6、开发人员点击已解决

7、开发人员把修改的问题给测试人员进行演示

8、开发人员发申请测试环境的邮件，说明修改了哪些问题，邮件写明WIKI网址，通知相关人员，并登记WIKI----（201X.XX测试）

9、相关的运维人员部署测试环境，并回复邮件，登记WIKI----（201X.XX测试）

10、测试人员复测bug

11、测试人员关闭bug，并在WIKI“测试人员确认”进行登记----（201X.XX测试）

12、测试人员有问题重新激活。

13、重新激活后从第4条继续走流程。

线上环境

web、Java

1、测试人员复现bug

2、测试人员提交bug

3、开发人员确认bug

4、开发人员修复好后，点击已解决

5、开发人员把解决的bug给测试人员进行演示，演示无误后。

6、修改bug的开发人员写申请发布测试环境的邮件，并将相关内容登记到WIKI----（201X.XX测试）

7、相关的运维人员部署测试环境，并回复邮件，并在WIKI登记----（201X.XX测试）

8、测试人员test环境复测bug，复测无误后，在WIKI“测试负责人”进行登记----（201X.XX测试）

9、测试人员test环境进行回归测试

10、回归测试无误后，测试人员在WIKI进行发布线上登记，等周二、周五正常流程，发申请线上的邮件，告知相关运维人员，并在WIKI登记----（201X.XX线上）

11、运维人员发布线上，回复邮件，并在WIKI登记----（201X.XX线上）

12、测试进行线上测试，回复邮件说明结果，并在WIKI“测试人员确认结果”进行登记-----（201X.XX线上）

13、如需紧急发布，测试人员发布申请线上紧急发布邮件，并说明紧急发布原因，同时WIKI登记----（201X.XX紧急发布）

14、相关的运维人员回复邮件，并在WIKI登记----（201X.XX紧急发布）

15、测试人员进行线上测试，回复邮件说明结果，并在WIKI“测试人员确认结果”进行登记-----（201X.XX紧急发布）