这个问题在日常测试中挺常见的,首先要做的就是暴露风险,将问题暴露给产品研发测试三方以及leader,三方评估影响范围以及修复成本。

接口从三个方面来考虑进一步处理:

一. 评估Bug的影响范围

二. 解决线上问题

三. 复盘线上问题

1.评估Bug的影响范围是处理线上Bug的第一步，通常需要根据评估的结果来决定下一步的处理方案。

1.1 分析bug影响的用户数量

检查bug是否业务核心环节的功能问题，是的话则影响的用户量比较多

1.2 分析bug影响的严重程度

检查bug是否涉及到用户的个人信息泄露、资金财产损失等比较敏感的功能，涉及的话则认为bug比较严重

2.我们通常会根据bug的影响范围来分别处理

2.1 影响范围比较小的bug

bug影响范围比较小时，一般都会通过修复bug的方式来解决，方法如下：

了解bug出现的场景，业务操作，努力复现bug,开发人员结合bug出现时的各种日志（系统日志、数据库日志、操作日志、debug日志），定位bug产生的原因,开发人员修改完成bug后，由测试人员进行回归测试，保证bug已被修复,按照项目规划的发布/升级的时间节点，将bug修复的代码发布到线上，bug解决.

如果开发修复缺陷的影响范围可控(测试要参与影响评估,掌握代码review能力是必备技能,关键时候能“保命”),则测试加班加点回归测试,保证问题修复验证通过的同时未产生新缺陷。当然如果测试过程又产生新缺陷,则考虑项目延期吧。

2.2 影响范围比较大的bug

如果开发修复缺陷的影响范围较大且不可控。则考虑项目延期,让开发给岀详细修复方案作为紧急fix版本,三方评估开发/测试工作量,保证问题修复后上线.

想都不要想赶紧去着手安排做规避：

1.无法明确问题原因时，可以通过回滚版本的方式来规避

2.部分用户功能可以通过后台配置的方式将功能降级或关闭

3.如果是资源不足等性能问题时，可以通过重启系统或者扩容的方式解决，再进一步观察

4.以上几种规避问题的方法只是帮助我们争取到时间，规避问题后还是要按照之前修复bug的方式来定位问题，修复问题，并将修复的代码发布线上，将bug彻底解决。

5.做好备份，及时发出上线公告，产生bug的功能暂且不上线，其他功能继续上线

3.当线上问题解决后，我们还需要对问题进行复盘，避免同样的问题再次发生：

线上问题复盘主要从如下几个方面进行：

1.检查其他的业务是否有同类型的问题,有问题的话提前解决，避免遗漏上线

2.分析bug的根本原因，考虑如何避免此类问题再次发生

分析bug是在哪个阶段引入？是设计阶段、开发阶段、测试阶段？

分析bug引入的原因是什么？是流程问题、技术问题、管理问题？

处理问题的流程是否合理？是否有问题预警、是否有紧急上线规范。