版权归作者所有，转载请注明出处
测试bug划分及处理流程
bug的修复流程：
整个流程分为两大类：测试环境和线上环境。
把两种环境又分为两种情况：web、java和APP。
正常情况下：
所有bug，被指派的开发人员在两个小时确定。不是自己的bug，找各组leader，另行指派。
线上发现Major以上bug，停下手头工作，两个小时以内进行解决。
若bug3天之内没有修复完成，请点解决，解决方案选择“延期处理”，并备注原因，说明解决时间。
测试环境：
web和java
测试人员发现bug
测试人员确认bug
测试人员提交bug（major以上@相关人员）
相关开发人员禅道确认bug
开发人员对bug进行修复
开发人员点击已解决
开发人员把修改的问题给测试人员进行演示
开发人员发申请测试环境的邮件，说明修改了哪些问题，邮件写明WIKI网址，通知相关人员，并登记WIKI----（201X.XX测试）
相关的运维人员部署测试环境，并回复邮件，登记WIKI----（201X.XX测试）
测试人员复测bug
测试人员关闭bug，并在WIKI“测试人员确认”进行登记----（201X.XX测试）
测试人员有问题重新激活。
重新激活后从第4条继续走流程。
APP
测试人员发现bug
测试人员确认bug
测试人员提交bug（major以上@相关人员）
相关开发人员禅道确认bug
开发人员对bug进行修复
开发人员点击已解决
开发人员说明修改了哪些bug，告知测试人员，把修改好的bug号列举出来。
开发人员登记WIKI---（201X.XX APP测试）
开发人员给测试人员进行演示。
开发人员给测试人员修改好的新包。
测试人员复测bug
测试人员关闭bug，并登记WIKI----（201X.XX APP测试）
测试人员有问题重新激活。
重新激活后从第4条继续走流程。
线上环境：
web和java
测试人员复现bug
测试人员提交bug
开发人员确认bug
开发人员修复好后，点击已解决
开发人员把解决的bug给测试人员进行演示，演示无误后。
修改bug的开发人员写申请发布测试环境的邮件，并将相关内容登记到WIKI----（201X.XX测试）
相关的运维人员部署测试环境，并回复邮件，并在WIKI登记----（201X.XX测试）
测试人员test环境复测bug，复测无误后，在WIKI“测试负责人”进行登记----（201X.XX测试）
测试人员test环境进行回归测试
回归测试无误后，测试人员在WIKI进行发布线上登记，等周二、周五正常流程，发申请线上的邮件，告知相关运维人员，并在WIKI登记----（201X.XX线上）
运维人员发布线上，回复邮件，并在WIKI登记----（201X.XX线上）
测试进行线上测试，回复邮件说明结果，并在WIKI“测试人员确认结果”进行登记 -----（201X.XX线上）
如需紧急发布，测试人员发布申请线上紧急发布邮件，并说明紧急发布原因，同时WIKI登记----（201X.XX紧急发布）
相关的运维人员回复邮件，并在WIKI登记----（201X.XX紧急发布）
测试人员进行线上测试，回复邮件说明结果，并在WIKI“测试人员确认结果”进行登记 -----（201X.XX紧急发布）
APP
测试人员复现bug
测试人员提交bug
开发人员确认bug
开发人员修复好后，点击已解决
开发人员说明修改了哪些bug，告知测试人员，把修改好的bug号列举出来。
开发人员把解决的bug给测试人员进行演示
前台问题，直接发包，开发人员并在WIKI进行相关内容登记----（201X.XX APP测试）
测试人员复测bug，复测无误后，在WIKI“测试负责人”进行登记----（201X.XX APP测试）
测试人员回归测试
测试人员发布“XX客户端版本号提交XX市场”申请的邮件并在WIKI进行登记----（201X.XX APP线上）
APP相关人员提交申请后回复邮件，在WIKI“项目负责人”进行登记----（201X.XX APP线上）
审核通过后告知相关人员，测试，相关leader（IOS开发人员自己跟踪，Android渠道负责人）
测试人员进行线上测试
测试人员审核无误后，回复邮件说明结果，在WIKI“测试人员确认”进行登记----（201X.XX APP线上）
如需紧急发布，测试人员发布申请线上紧急发布邮件，并说明紧急发布原因，说明“XX客户端版本号提交XX市场”，同时WIKI登记----（201X.XX紧急发布）
IOS开发人员，Android渠道负责人，回复邮件，并在WIKI登记----（201X.XX紧急发布）
审核通过后，测试人员进行线上测试，回复邮件说明结果，并在WIKI“测试人员确认结果”进行登记 -----（201X.XX紧急发布）
后端问题，修改bug的开发人员写申请发布测试环境的邮件，并将相关内容登记到WIKI----（201X.XX测试）
相关的运维人员部署测试环境，并回复邮件，并在WIKI登记----（201X.XX测试）
测试人员test环境复测bug，复测无误后，在WIKI“测试负责人”进行登记----（201X.XX测试）
测试人员test环境进行回归测试
回归测试无误后，测试人员在WIKI进行发布线上登记，等周二、周五正常流程，发申请线上的邮件，告知相关运维人员，并在WIKI登记----（201X.XX线上）
运维人员发布线上，回复邮件，并在WIKI登记----（201X.XX线上）
测试进行线上测试，回复邮件说明结果，并在WIKI“测试人员确认结果”进行登记 -----（201X.XX线上）
如需紧急发布，测试人员发布申请线上紧急发布邮件，并说明紧急发布原因，同时WIKI登记----（201X.XX紧急发布）
相关的运维人员回复邮件，并在WIKI登记----（201X.XX紧急发布）
测试人员进行线上测试，回复邮件说明结果，并在WIKI“测试人员确认结果”进行登记 -----（201X.XX紧急发布）
PS：测试是在demo通过后开始，并在测试环境工作。
bug提交：
1.创建bug的时候要选指派人，如果有需要的情况就抄送相关人员；
2.标题要表达清楚；
3.重现步骤，除了一些偶现的，请务必写上步骤以及期望结果；
4.类型/严重程度。类型是说明这个bug的类型属于简单界面，还是逻辑错误，还是其他问题。总的来说类型应该有如下这些：
代码错误
界面优化
设计缺陷
配置相关
性能问题
标准规范
测试脚本
其他
测试人员要把标题写清楚，如果测试人员不知道属于什么类型的bug时也可和开发人员或者leader商量，属于哪种类型。
bug级别：
严重程度由高到低依次为：
1.critical
2.block
3.major
4.normal
5.minor
critical：是说项目中某一块功能因为这个bug而导致测试无法进行下去，此critical级别。该等级问题出现在不影响其他功能测试的情况下可以继续该版本测试。
block：是说项目中有闪退、崩溃情况，此为block级别。出现这种级别的问题此版本停止测试。
major：是说一些功能没有实现，但是不影响使用，功能菜单缺失，但不会影响系统稳定，此为major。这种问题应该合理安排时间进行修改。
normal：是说界面等UI问题显示错误，比如字体大小，颜色，间距等问题。此类问题在测试初期较多，优先程度较低，在测试后期出现较少，应及时处理。
minor：是说界面、性能缺陷，建议类问题，不影响操作功能的执行，可以优化性能的方案等。
bug状态：
待处理（new）：测试人员或用户发现新问题后提交的状态；
已确认（open）：经测试人员及研发人员讨论后确认是BUG，提交的状态，由测试人员来设置；
已处理（fixed）：经研发人员确认是BUG后修复的状态，修改还没有验证，由开发人员来设置；
已修改（closed）：测试人员认为问题已经修改，通过验证，由测试人员设置；
仍存在（reopened）：测试人员认为BUG未修复成功，问题仍然存在，由测试人员设置；
不是问题（reject）：研发人员确认不是BUG，或者建议与意见决定不采纳；
暂不处理（hold）：当前版本不做修改，后续版本再考虑，由研发人员或测试人员设置。
此文章仅作参考，如有不同见解，欢迎评论区留言，谢谢！
