这个问题在日常测试中挺常见的,首先要做的就是暴露风险,将问题暴露给产品研发测试三方以及leader,三方评估影响范围以及修复成本。
接口从三个方面来考虑进一步处理:
一. 评估Bug的影响范围
二. 解决线上问题
三. 复盘线上问题
检查bug是否业务核心环节的功能问题,是的话则影响的用户量比较多
检查bug是否涉及到用户的个人信息泄露、资金财产损失等比较敏感的功能,涉及的话则认为bug比较严重
bug影响范围比较小时,一般都会通过修复bug的方式来解决,方法如下:
了解bug出现的场景,业务操作,努力复现bug,开发人员结合bug出现时的各种日志(系统日志、数据库日志、操作日志、debug日志),定位bug产生的原因,开发人员修改完成bug后,由测试人员进行回归测试,保证bug已被修复,按照项目规划的发布/升级的时间节点,将bug修复的代码发布到线上,bug解决.
如果开发修复缺陷的影响范围可控(测试要参与影响评估,掌握代码review能力是必备技能,关键时候能“保命”),则测试加班加点回归测试,保证问题修复验证通过的同时未产生新缺陷。当然如果测试过程又产生新缺陷,则考虑项目延期吧。
如果开发修复缺陷的影响范围较大且不可控。则考虑项目延期,让开发给岀详细修复方案作为紧急fix版本,三方评估开发/测试工作量,保证问题修复后上线.
想都不要想赶紧去着手安排做规避:
1.无法明确问题原因时,可以通过回滚版本的方式来规避
2.部分用户功能可以通过后台配置的方式将功能降级或关闭
3.如果是资源不足等性能问题时,可以通过重启系统或者扩容的方式解决,再进一步观察
4.以上几种规避问题的方法只是帮助我们争取到时间,规避问题后还是要按照之前修复bug的方式来定位问题,修复问题,并将修复的代码发布线上,将bug彻底解决。
5.做好备份,及时发出上线公告,产生bug的功能暂且不上线,其他功能继续上线
线上问题复盘主要从如下几个方面进行:
1.检查其他的业务是否有同类型的问题,有问题的话提前解决,避免遗漏上线
2.分析bug的根本原因,考虑如何避免此类问题再次发生
3.分析bug是在哪个阶段引入?是设计阶段、开发阶段、测试阶段?
4.分析bug引入的原因是什么?是流程问题、技术问题、管理问题?
5.处理问题的流程是否合理?是否有问题预警、是否有紧急上线规范。
感谢每一个认真阅读我文章的人!!!
作为一位过来人也是希望大家少走一些弯路,如果你不想再体验一次学习时找不到资料,没人解答问题,坚持几天便放弃的感受的话,在这里我给大家分享一些自动化测试的学习资源,希望能给你前进的路上带来帮助。
文档获取方式:
加入我的软件测试交流群:680748947免费获取~(同行大佬一起学术交流,每晚都有大佬直播分享技术知识点)
这份文档,对于想从事【软件测试】的朋友来说应该是最全面最完整的备战仓库,这个仓库也陪伴我走过了最艰难的路程,希望也能帮助到你!
以上均可以分享,只需要你搜索vx公众号:程序员雨果,即可免费领取
上一篇:揭秘智慧礼品背后的故事