如果项目在上线后才发现Bug怎么办?
这个问题在日常测试中挺常见的,首先要做的就是暴露风险,将问题暴露给产品研发测试三方以及leader,三方评估影响范围以及修复成本。
接口从三个方面来考虑进一步处理:
一. 评估Bug的影响范围
二. 解决线上问题
三. 复盘线上问题
1.评估Bug的影响范围是处理线上Bug的第一步,通常需要根据评估的结果来决定下一步的处理方案。
1.1 分析bug影响的用户数量
检查bug是否业务核心环节的功能问题,是的话则影响的用户量比较多
1.2 分析bug影响的严重程度
检查bug是否涉及到用户的个人信息泄露、资金财产损失等比较敏感的功能,涉及的话则认为bug比较严重
2.我们通常会根据bug的影响范围来分别处理
2.1 影响范围比较小的bug
bug影响范围比较小时,一般都会通过修复bug的方式来解决,方法如下:
了解bug出现的场景,业务操作,努力复现bug,开发人员结合bug出现时的各种日志(系统日志、数据库日志、操作日志、debug日志),定位bug产生的原因,开发人员修改完成bug后,由测试人员进行回归测试,保证bug已被修复,按照项目规划的发布/升级的时间节点,将bug修复的代码发布到线上,bug解决.
如果开发修复缺陷的影响范围可控(测试要参与影响评估,掌握代码review能力是必备技能,关键时候能“保命”),则测试加班加点回归测试,保证问题修复验证通过的同时未产生新缺陷。当然如果测试过程又产生新缺陷,则考虑项目延期吧。
2.2 影响范围比较大的bug
如果开发修复缺陷的影晌范围较大且不可控。则考虑项目延期,让开发给岀详细修复方案作为紧急fix版本,三方评估开发/测试工作量,保证问题修复后上线.
想都不要想赶紧去着手安排做规避:
1.无法明确问题原因时,可以通过回滚版本的方式来规避
2.部分用户功能可以通过后台配置的方式将功能降级或关闭
3.如果是资源不足等性能问题时,可以通过重启系统或者扩容的方式解决,再进一步观察
4.以上几种规避问题的方法只是帮助我们争取到时间,规避问题后还是要按照之前修复bug的方式来定位问题,修复问题,并将修复的代码发布线上,将bug彻底解决。
5. 做好备份,及时发出上线公告,产生bug的功能暂且不上线,其他功能继续上线
3.当线上问题解决后,我们还需要对问题进行复盘,避免同样的问题再次发生:
线上问题复盘主要从如下几个方面进行:
1.检查其他的业务是否有同类型的问题,有问题的话提前解决,避免遗漏上线
2.分析bug的根本原因,考虑如何避免此类问题再次发生
分析bug是在哪个阶段引入?是设计阶段、开发阶段、测试阶段?
分析bug引入的原因是什么?是流程问题、技术问题、管理问题?
处理问题的流程是否合理?是否有问题预警、是否有紧急上线规范。
更多关于软件测试培训的问题,欢迎咨询千锋教育在线名师。千锋教育拥有多年IT培训服务经验,采用全程面授高品质、高体验培养模式,拥有国内一体化教学管理及学员服务,助力更多学员实现高薪梦想。