整个流程分为两大类：测试环境和线上环境。
把两种环境又分为两种情况：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紧急发布）
