线上bug处理方案
项目上线后出现bug该怎么解决
在公司中测试人员最基本的职责就是保证项目的质量，尽可能把bug都在上线前找出来。但是实际工作时由于各种各样的原因，不可避免的会有些问题会在上线后被发现。那么如何能够快速的处理这些线上的问题，降低bug的影响范围，减少对公司的业务或者经济损失呢？在这里，我们提供给大家一个基本的处理线上问题的思路。
- 评估bug的影响范围
- 解决线上问题
- 回溯线上问题
一. 第一步 —— 评估bug的影响范围
评估bug的影响范围是处理线上bug的第一步，通常需要根据评估的结果来决定下一步的处理方案。
影响范围要从哪些方面进行评估呢？
（1）分析bug影响的用户数量
- 检查bug是否业务核心环节的功能问题，是的话则影响的用户量比较多
（2）分析bug影响的严重程度
- 检查bug是否涉及到用户的个人信息泄露、资金财产损失等比较敏感的功能，涉及的话则认为bug比较严重
对于bug影响范围的评估，必须尽可能的快速且准确，因为影响范围和程度会随着时间不断扩大，及时了解目前的bug影响，可以为后续解决问题提供最适合的指导意见。
二. 第二步 —— 解决线上问题
针对线上问题最重要的是要解决，在评估完影响范围后，就需要制定对应的措施来解决问题并恢复系统的正常使用。
解决线上问题的措施一般有哪些呢？通常根据问题的影响范围来分别处理
（1）影响范围比较小的bug
bug影响范围比较小时，一般都会通过修复bug的方式来解决，方法如下：
- 了解bug出现的场景，业务操作，努力复现bug
- 开发人员结合bug出现时的各种日志（系统日志、数据库日志、操作日志、debug日志），定位bug产生的原因
- 开发人员修改完成bug后，由测试人员进行验证，保证bug已被修复
- 按照项目规划的发布/升级的时间节点，将bug修复的代码发布到线上，bug解决
（2）影响范围比较大的bug
bug影响范围比较大时，如果还是通过修复bug的方式来解决，对用户的影响或者公司的损失无法把控，此时最重要的是：将问题范围降到最低。方法如下：
- 无法明确问题引入原因时，可以通过回滚版本的方式来规避
- 部分用户功能可以通过后台配置的方式将功能降级或关闭
- 如果是资源不足等性能问题时，可以通过重启系统或者扩容的方式解决，再进一步观察
- 以上几种规避问题的方法只是帮助我们争取到时间，规避问题后还是要按照之前修复bug的方式来定位问题，修复问题，并将修复的代码发布线上，将bug彻底解决。
在实际工作中，我们需要根据bug的影响范围来选取最适当的解决方法，目的只有一个：将问题影响范围降到最低
三. 第三步 ——回溯线上问题
当线上问题解决后，我们还需要对问题进行总结回溯，避免同样的问题再次发生。
线上问题回溯主要从如下几个方面进行：
（1）检查其他的业务是否有同类型的问题
- 有问题的话提前解决，避免遗漏上线
（2）分析bug的根本原因，考虑如何避免此类问题再次发生
- 分析bug是在哪个阶段引入？是设计阶段、开发阶段、测试阶段？
- 分析bug引入的原因是什么？是流程问题、技术问题、管理问题？
- 处理问题的流程是否合理？是否有问题预警、是否有紧急上线规范。。。？
问题的回溯对于团队整体的能力提升是非常有帮助的，通过线上问题的处理，发现在项目研发过程中的各种问题，不断的弥补这些问题并改进，提升项目组的研发能力和效率。
总结
线上问题的处理是测试工程师的一项重要的职责。测试人员要尽可能的保证问题在上线前发现并解决，万一问题遗漏上线，测试人员也要积极处理，保障业务系统的正常运行。
通过线上问题的处理，既可以让我们了解项目代码中的问题并修复，又可以让我们找到项目组的流程、管理、技术等各方面的短板来补齐，这样才能成为一名优秀的测试工程师。
必先bug处理方式
以下用禅道bug管理工具举例
一、必先bug处理方式
1.先在线上复现问题
2.找到复现步骤
3.在测试服务器复现问题
4.如果按照复现步骤，问题复现
5.找到bug对应的模块，查看是否有对应的用例，如果没有则补充测试用例，标题增加【线上】（表示线上发现的问题），验证阶段和优先级，自己定义，这里以后想在测试最后一个阶段进行验证，所有这里选择版本验证阶段，根据自己项目定，优先级定义4级，（同类的用例都这么标记，方便整合在一起）
6.然后转成bug，提交对应的开发
7.转为bug，修改标题问题，指派给前端开发抓取日志，排查问题
8.查看自己提交bug
9.之后，自己跟进bug，直到关闭
10.总结此类型用例，建立新套件，以后在测试最后一轮进行验证，防止线上问题二次出现
11.将编辑好的用例关联进来
12.到此阶段后，进行执行即可
二、其他类型bug，待补充
