上线后Bug的处理方式(2020-09-20)

@软件测试-上线后Bug的处理方式

#软件测试-上线后Bug的处理方式

项目上线以后,尤其是大公司的大佬们,肯定会第一时间关注,下载,安装,注册,并且操作,在这个时候大佬们第一时间找的是测试负责人。所以项目出上线,不要以为大功告成,可以长长的舒一口气。
如果出现这种情况,有领导反映说有问题,处理思路:1.不要争执对错,有无;2.问清楚是如何复现的,比如:机型,系统,做了什么操作;3.看是我们项目评估后带着的已知问题上线还是确实是问题,还是线上数据库没有这些数据,导致页面展示为空之类的问题

项目在上线之后又出现了Bug,这让很多测试人员和开发人员头痛。
但很多时候线上Bug普遍地存在,不可避免。
任何项目都存在未发现 Bug 和 已发现 Bug 两种情况,不存在没有 Bug的情况。

在公司中测试人员最基本的职责就是保证项目的质量,尽可能把bug都在上线前找出来。但是实际工作时由于各种各样的原因,不可避免的会有些问题会在上线后被发现。那么如何能够快速的处理这些线上的问题,降低bug的影响范围,减少对公司的业务或者经济损失呢?在这里,我们提供给大家一个基本的处理线上问题的思路。

即便是测试人员,在测试过程中也不可能发现所有Bug并覆盖 100% 的范围。

一个项目上线后也会出现Bug。那么遇到这种情况,测试人员该如何处理呢?

  1. 评估bug的影响范围
  2. 解决线上问题
  3. 回溯线上问题

一. 第一步 —— 评估bug的影响范围

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

影响范围要从哪些方面进行评估呢?

(1)分析bug影响的用户数量
检查bug是否业务核心环节的功能问题,是的话则影响的用户量比较多(2)分析bug影响的严重程度
检查bug是否涉及到用户的个人信息泄露、资金财产损失等比较敏感的功能,涉及的话则认为bug比较严重对于bug影响范围的评估,必须尽可能的快速且准确,因为影响范围和程度会随着时间不断扩大,及时了解目前的bug影响,可以为后续解决问题提供最适合的指导意见。

二. 第二步 —— 解决线上问题

针对线上问题最重要的是要解决,在评估完影响范围后,就需要制定对应的措施来解决问题并恢复系统的正常使用。

解决线上问题的措施一般有哪些呢?通常根据问题的影响范围来分别处理

(1)影响范围比较小的bug
bug影响范围比较小时,一般都会通过修复bug的方式来解决,方法如下:
了解bug出现的场景,业务操作,努力复现bug开发人员结合bug出现时的各种日志(系统日志、数据库日志、操作日志、debug日志),定位bug产生的原因开发人员修改完成bug后,由测试人员进行验证,保证bug已被修复按照项目规划的发布/升级的时间节点,将bug修复的代码发布到线上,bug解决

(2)影响范围比较大的bug
bug影响范围比较大时,如果还是通过修复bug的方式来解决,对用户的影响或者公司的损失无法把控,此时最重要的是:将问题范围降到最低。方法如下:
无法明确问题引入原因时,可以通过回滚版本的方式来规避部分用户功能可以通过后台配置的方式将功能降级或关闭如果是资源不足等性能问题时,可以通过重启系统或者扩容的方式解决,再进一步观察以上几种规避问题的方法只是帮助我们争取到时间,规避问题后还是要按照之前修复bug的方式来定位问题,修复问题,并将修复的代码发布线上,将bug彻底解决。在实际工作中,我们需要根据bug的影响范围来选取最适当的解决方法,目的只有一个:将问题影响范围降到最低

三. 第三步 ——回溯线上问题
当线上问题解决后,我们还需要对问题进行总结回溯,避免同样的问题再次发生。

线上问题回溯主要从如下几个方面进行:
(1)检查其他的业务是否有同类型的问题
有问题的话提前解决,避免遗漏上线
(2)分析bug的根本原因,考虑如何避免此类问题再次发生
(3) 如果问题只在线上才出现,测试环境重现不了,那么可能是版本或环境配置的问题;
如果问题不仅线上能重现,测试环境也存在,那么很有可能是测试人员在测试过程中未发现的Bug。

分析bug是在哪个阶段引入?是设计阶段、开发阶段、测试阶段?分析bug引入的原因是什么?是流程问题、技术问题、管理问题?处理问题的流程是否合理?是否有问题预警、是否有紧急上线规范。。。?问题的回溯对于团队整体的能力提升是非常有帮助的,通过线上问题的处理,发现在项目研发过程中的各种问题,不断的弥补这些问题并改进,提升项目组的研发能力和效率。

总结

线上问题的处理是测试工程师的一项重要的职责。测试人员要尽可能的保证问题在上线前发现并解决,万一问题遗漏上线,测试人员也要积极处理,保障业务系统的正常运行。

通过线上问题的处理,既可以让我们了解项目代码中的问题并修复,又可以让我们找到项目组的流程、管理、技术等各方面的短板来补齐,这样才能成为一名优秀的测试工程师。

开发人员修复Bug之后,测试人员需要反思。

若是由于疏忽造成测试用例执行遗漏,测试人员需要在下次执行测试的过程中避免这样的情况。
若是由于用例评审的不严格、中途需求变更或者某些其他因素造成的测试用例覆盖不全,测试人员需要补全测试用例。

在测试过程中遇到未发现的Bug,测试人员不要自怨自艾,问题发生了,第一时间想解决办法,维护公司利益,把公司的损失降低到最低;其次是摆好心态,态度要端正。也不要像没回事儿一样,需要正确对待“线上Bug”、汲取经验教训、不断提高测试能力。
测试人员需要不断学习,不断扩充,掌握测试工具、提升测试技能,从而设计出更全面的测试场景和测试用例。

  • 8
    点赞
  • 18
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值