测试上线后,生产环境有 Bug 这到底是谁的锅?

本贴最后更新于 626 天前,其中的信息可能已经事过景迁

做测试的童鞋应常遇到系统在测试环境测试通过后上UAT环境产品验收没问题,但是一上生产就出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、问题的复盘,针对该问题的线索过程,以及解决的过程和解决方案、具体原因分析,各项要优化的工作落地。

回帖
请输入回帖内容 ...