线上出了问题就一定是测试工程师的问题么

性能大白Blaine 9
2022-08-29 21:59:21 未知地区 1F
回复

当测试工程师测试的版本上线后，这个责任就会转嫁到运维手中，所以学会甩锅也是一种能力的体现线上环境出现的问题，在测试环境中遇到过，测试就可以躺平了。如果没有发现过，测试就需要上点心 55 开吧，不然你还想一点锅都不背？除非开发自己悄悄改代码那测试不背锅线上出了问题需要确定具体原因，如果是测试执行漏测，那就是测试的问题。如果是测试设计还可以用评审分下锅，如果是极端异常场景或极复杂场景可以体谅，其他原因则直接刚正面！
帖子内容就没看明白啥意思了，自己环境是什么环境？你这句话实在让我费解啊灵魂三问：

测了吗？
谁测的？
测了为啥测不出来？
简单地把线上 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、找到根因后，讨论解决方案，并严格落地执行，防患未然。无论是开发还是测试的原因，或是都有，一起优化流程或改进方法。
至于一定是测试或是开发的问题，复盘后大家都很清楚的，领导更清楚。重点还是解决问题。现在是甩锅局，能推就推，他们可不管是不是你的责任