做测试的同学应常遇到系统在测试环境测试通过后上UAT环境产品验收没问题，但是一上生产就出bug，更严重的情况是弄得大家通宵加班测试修bug；而且还会开发和测试，乃至运维，产品相互甩锅！
为了改善开会就是大型甩锅现场的现状，所以有一天领导宣布：每个人写的代码超过十个 bug 就开除！
开发立马把所有测试人员拉到一个小微信群，开始商量对策。
测试：我们也没办法呀，你们把代码写好点？
开发：写再好写不可能不超过 10 个呀，而且你们想想，如果我们不写 bug，你们测什么？你们测不出 bug，会不会被炒掉？你们自己想想吧！
测试：你说的有道理，那我们怎么做啊？
开发：好做啊，我们只需要「计划 bug」即可，就跟「计划经济」一样。今天提测了，三天后上线，一共只能有 9 个 bug。你们只要每天定好只提三个 bug 就行。
开发：不错不错，就这么办。
一段时候之后，领导发现系统的 bug 数量明显降低，于是觉得自己的领导能力一级棒，整天沾沾自喜。
看，领导、开发、测试都没有任何损失（也没有任何改进），公司又变成了一个其乐融融的大家庭（上下沟通变得更难），而且公司的 bug 跟踪系统再也不能有效反映 bug 的真实情况了（白白浪费了一个系统）。
上有政策，下有对策。领导也许还有后续政策，但是下面一定会想出后续对策。
一个公司如果不改进生产效率和沟通方式，只是拍脑袋瞎定政策，那么就什么都不会改变。
那么，测试上线后
生产环境有 Bug 这到底是谁的锅？
我们先来了解一下，生成环境bug主要来源有哪些？
1、用户反馈
用户使用过程中通过意见反馈后台、微博、APP Store商店等渠道反馈自己的意见，以及遇到的问题；
2、内部反馈:
各条业务线钉钉/微信/QQ群反馈的线上版本产生的问题，以及内部人员使用中反馈的线上问题；
3、监控后台收集：
各种运营平台/监控后台收集到的用户使用中的问题。
锅的质量分析
现在团队得到了线上bug，为了更好的进行锅的责任划分，以及接下来处理线上bug，我们需要认真分析下BUG的质量和等级。
为了方便分析，我们可以简单地把线上BUG分成三个等级：
1、简单易现的问题：
如果是比较简单就复现的问题，那作为测试人员这个锅跑不了。因为这是基本的工作态度的问题了。
如何避免这类问题的出现呢？有几个小办法：
1）注重测试策略的设计，对于每个迭代（版本）的测试重点和测试方法做一次梳理。
2）测试用例设计：熟练使用各种用例设计方法去设计和编写测试用例，这样才能保证用例的覆盖率。
3）测试用例评审，避免自己陷入测试盲区，让产品和研发一起来确认场景覆盖是否充足。
4）认真执行测试用例，这点很简单，但是很重要。因为人都会情绪低潮，在某些情况下，心存侥幸，可能用例直接就Pass了。
2、特定场景或者数据才会出现的问题
这种情况在测试环境里考虑可能真的考虑不到，所以这种问题的锅测试其实不用太担心背，因为情有可原。
我们主要做到每次在线上环境里遇到，我们就一定要补充到测试用例库中；如果公司有自动化测试框架，那么也要补充自动化测试用例库中；
当然，同时思考为什么只有这种情况才会出现，做好测试环境和测试是数据的对比。这类问题需要注意平时的积累，形成自己的经验，这类“锅”，可以团队一起背，但要给出改进方案，不能多次在同一个地方跌倒。
3、深层次的偶发问题：
这种bug在测试环境发现的可能性也是比较低的；一方面偶发，另外一方面测试深度比较考究，所以这种bug的锅也不用太有负担。
而且这种问题我们要转变心态对待，因为这其实是提升团队技术能力很好的试验场，集中力量解决掉就是了。
这类问题，一般情况下做好线上监控，能及时预警，比客户更早或者不能落后太多发现，不要给用户造成严重的业务或者经济损失和影响，就可以的；可以提前准备好相关的话术，安抚客户，同时能够让团队有缓冲解决问题的时间就好。
如此将线上bug分类这么一分类，其实测试的心理负担就少很多了，有些“锅”也不是什么坏事吗，而且也并不一定都会被领导严厉追责。
树立正确的质量观
通过以上对线上bug的分析，我们发现需要给每个测试员和测试员身边的人树立正确的质量观。
相关从业者都知道测试的使命是要找出产品的bug，保证软件的质量，并且为之而奋斗终身；但是其实保证质量到底到什么程度？有没有可能发现所有bug？是不是只要出了问题就是测试的责任？这个是需要摆正观念的。
认识到一点：测试无法发现软件的所有bug
这个点是我们需要认清的，就跟没有任何一个开发敢说自己开发出来的代码没有bug一样，也没有一个测试敢说自己测试完的软件没有一个剩余bug了。
我们作为测试的职责是尽可能的去发现软件的bug，但是总是有些bug还是无法被全部挖掘出来，这种就会留到线下环境里去，被用户遇到。这是一种自然的正常现象。
所以，总结一下一个优秀的测试应该做到如下几点：
1）测试首要保证系统不出重大事故，要有最低的质量保证，而且不出现低级错误；
2）如果出现问题，及时反思和寻找解决办法，并总结经验教训，想办法解决或者规避此类问题的再次发生；
3）尽最大的努力去攻克难以测到的问题；在攻克的过程中不断的提示自己的技能，在提高测试效率 + 加深测试深度的路上努力成长！
4）通过更好的实践方式，提前预防问题的发生。比如单元测试、代码走读测试，接口测试，埋点测试，混沌测试等都会帮助我们及早的发现问题。
线上bug处理总结
线上出问题进行责任划分虽然也是有必要做，可以按照以上分析的bug的质量类型进行责任划分，因为责任到人可以更好的规避下次同样的问题再次出现。
同时，更重要的是做好线上问题的处理:
1、先排查测试环境是否也存在这样的问题，如果存在，那就很明显是测试环境没测试出来；
此时一定要分析测试环境没有发现的原因分析，优化测试流程和用例库，比如加强用例的评审，以及交叉测试，还有测试结果的审查等；
2、如果测试环境不存在但是线上环境存在问题，那么很可能就是线上某些组件的配置文件导致了该问题，比如涉及redis，多实例服务等各种配置导致了问题；
此时要优化测试环境，尽可能贴近线上环境，才能在测试环境里发现更多的bug。
3、如果问题解决了，就做好总结和完善目前工作内容和流程的工作。
如果没有解决就得评估本次上线该问题带来的风险，判断本次是否需要回滚，以及如何安抚用户。
4、问题的复盘，针对该问题的线索过程，以及解决的过程和解决方案、具体原因分析，各项要优化的工作落地。