当测试工程师测试的版本上线后，这个责任就会转嫁到运维手中，所以学会甩锅也是一种能力的体现

线上环境出现的问题，在测试环境中遇到过，测试就可以躺平了。如果没有发现过，测试就需要上点心

55 开吧，不然你还想一点锅都不背？除非开发自己悄悄改代码那测试不背锅

线上出了问题需要确定具体原因，如果是测试执行漏测，那就是测试的问题。如果是测试设计还可以用评审分下锅，如果是极端异常场景或极复杂场景可以体谅，其他原因则直接刚正面！
帖子内容就没看明白啥意思了，自己环境是什么环境？你这句话实在让我费解啊

灵魂三问：

1. 测了吗？
2. 谁测的？
3. 测了为啥测不出来？

简单地把线上 BUG 分成三个等级，便于分析。
简单易现的问题：如果是比较简单就复现的问题，那作为测试人员就要反思下为什么了，这个锅跑不了，还是要有对自己的工作负责的态度。如何避免这类问题的出现呢？有几个小办法：

注重测试策略的设计（好多人都忘记这件事了，后面会专门谈谈测试策略的问题），对于每个迭代（版本）的测试重点和测试方法做一次梳理。
测试用例设计更全面些，多考虑一些业务场景，更多的确认手段，而不仅仅只停留在页面的操作上。
测试用例评审，避免自己陷入测试盲区，让产品和研发一起来确认场景覆盖是否充足。
认真执行测试用例，这点很简单，但是很重要。因为人都会情绪低潮，在某些情况下，心存侥幸，可能用例直接就 Pass 了。
特定场景或者数据才会出现的问题：这种情况，遇到一次，就完善一次用例（如果能自动化，就最好了），同时思考为什么只有这种情况才会出现，类似的还是不同环境配置引起的问题。这类问题需要注意平时的积累，形成自己的经验，这类 “锅”，可以团队一起背，但要给出改进方案，不能多次在同一个地方跌倒。

深层次的偶发问题：这类问题其实是提升团队技术能力很好的试验场，集中力量解决掉就是了，更能激发技术宅男们的热情。这类问题，一般情况下做好线上监控，能及时预警，比客户更早或者不能落后太多发现，就可以的，让团队有缓冲解决问题的时间就好（准备好相关的话术，安抚客户也是 OK 的）。
你看，这么一分，是不是心理负担就少很多了，有些 “锅” 也不是什么坏事。不是么。

你的质量观在哪里‍
最后，再聊聊测试人自己的质量观。每个人走上测试这条路的理由五花八门，也导致了大家对质量这件事本身的看法也有很大的不同。

看法一：把测试这个职业定义为仅仅是保证系统不出重大事故，一点就蹦的情况出现，其它交给开发，出现 BUG 就是开发能力不足。因为他们对测试的理解就出现了偏差，所以遇到比较复杂的，难以测到的问题，就放弃努力，给自己找借口。比如自己薪资就那么点，因为能力有限啊，发现不了还能怎么办？比如你行你来测试啊？谁家软件还没有个 BUG 呢。凡此种种，肯定不会觉得自己应该背这个锅的。

看法二：从自己手中出去的产品，要有最低的质量保证，如果出现问题，及时反思，寻找解决办法，什么 “Bug 藏得太深”、“测试环境无法复现” 等理由都不是借口，总结经验教训，努力提升自己。真正把测试当做职业来对待，一定会想到办法解决或者规避此类问题的再次发生。在做好自己的同时，给团队带来正面影响，逐渐影响到其他人。

看法三：通过更好的实践方式，提前预防问题的发生。单测、静态分析、自动化测试，还有现在比较流行的混沌测试，都会帮助我们及早的发现问题。在适当的机会引入敏捷理念，通过自己的能力和实践，协助团队内建质量，培养全员质量意识。

参考：https://testerhome.com/topics/32230

是在自己的测试环境中发现的问题，然后就背锅了啊

这灵魂三问给我唬住了，大家线上肯定都出过问题，我先说下我的 生产出问题没有追过责，但是那次在自己测试环境追责给我惊到了 生产都是能解决立马解决，因为都是周末出的问题，不然就推到周一，毕竟开发们不带电脑回去

对，测试环境遇到过，还好。没遇到过的话就几乎归到测试这边了

你还真别说 运维还真出过问题，让我们搞到凌晨两点多，结果是运维那边把 api 搞错了

这个我会好好膜拜一下 谢谢

这东西放到每个人身上肯定是能推就推 推不了就是五五开了

测试环境发现的问题能叫问题？那叫 bug！追责是什么鬼？让他打开麦克风与我交流
延伸下，如果是测试环境搭建不合规导致与线上不一致进而出现线上 bug 就有点问题了

就是一个无知的产品， 他以为上线了，其实还在自己测试环境啊 第二天闹到老板那了 也说清楚了啊 就非得追责，结果就是追责啊 不同意有什么办法

真实

公司总共几个人？搁我直接干他

这个话题上次在广州的沙龙微信群里有讨论过，众说纷纭。
我们的做法：线上问题都会做复盘，各个角色拉到一起，把事情产生的来龙去脉弄清楚，找到哪些环节出现了问题导致了故障的出现。然后定下来针对性的改进项。
故障就代表着质量问题，那我们测试作为质量保障的重要一环，特别是最后的把关，肯定多少都会有责任。只是看这个责任的大小。
但是责任就是代表锅吗？其实未必。每个问题都会暴露流程的缺少，我们勇于承担责任把这个缺口给补上，其实就是把我们的分量和话语权提升上去了。都在讲左移右移，如果你平时得不到老板的支持，那么这些教训出现的时候你顺势提出来，说不定也能得到更多的支持。
当然，如果纯粹是测试用例少了关键场景导致的漏测，那就没什么好说的，该挨打的时候就乖乖挨打。只要态度端正，勇于认错和积极提出针对性的改进项，老板也不会怪太多。

我就怼她了啊，但是老板在哪说这个事情要有个解决，最后就是开发跟测试背锅

这 tm 都是脑子有泡吧，那以后发现的 bug 是不是都得追责，直接别测了，测出来的不是 bug 是锅。

话是这么说啊 但是有的人他就直接推出去了把问题，你的话语权没有人家重啊 人家是经理 领导不会听你的

这种就有点涉及办公室政治了。
1、团队的 leader，日常需要和业务方打好关系，多吃吃饭啥的，普及一下这方面一些基本知识（至少测试环境和线上环境分开下）。至少有问题先反馈给技术去处理，小问题内部解决掉，别啥问题直接怼给最大的领导。
2、如果真闹大，闹到领导那，也叫上你自己的领导过去，和产品那边把问题怼到领导那边的至少同级的，杠到底。角色不对等的话，会天然弱势
3、看清下在这个公司的业务形态下，技术到底是辅助角色还是核心角色。如果技术本身就是辅助角色的话，要获得话语权非常难，而你又比较在意这个的话，建议考虑换个公司，避免老是气到自己。

#6 楼@CKL 回复很细了，建议补充几点
1、线上出了问题，首先咱们想到的应是客户，判断对客户使用的风险，及如何快速解决客户的问题，如是发补丁版本，还是如何。有些问题还会影响公司的经济效益或声誉，都需考虑。
2、必要时组织团队的复盘会，需求、开发、测试所有相关人员一起思考、复盘（建议可用多嵌套的根因分析法，直到找到根因）
3、找到根因后，讨论解决方案，并严格落地执行，防患未然。无论是开发还是测试的原因，或是都有，一起优化流程或改进方法。
至于一定是测试或是开发的问题，复盘后大家都很清楚的，领导更清楚。重点还是解决问题。

现在是甩锅局，能推就推，他们可不管是不是你的责任