【20240821-每日一题】对于重现率不高的 BUG 怎么处理?

难度

简单

题目

对于重现率不高的 BUG 怎么处理?请详细阐述。

首先会对比新旧版本检查一下偶现bug是否为新的问题,描述一下bug的内容最好是有视频或者对应的接口,然后让开发看一下内容是否能定位到问题所在,如果还是不能定位的话就可以查看一下这个时间段的日志或者前端的操作记录,看是否会有特殊的数据或者操作等,最后如果是复现不出或者是没有再出现的问题会先挂起bug一段时间后再关闭bug。

首先:测试自己先尝试复现,无法复现,可以和开发一起分析代码和日志,评估可能出现的原因,再去复现。能复现就能想办法去解决并进行回归测试。通过以上方法依然无法复现的,如果bug带来的影响经过评估后,很小,可以尝试去修复,然后发布上线观察线上的数据。影响大,而所属团队无法定位到该问题 ,将问题升级,请求协助,尽快修复该问题。

只有非常小概率BUG无法重现,尤其是自动化操作发现的bug有时候手工较难重现。一般手工测试过程中bug不能重现可以从下面几个方面考虑:

  1. 数据问题:是否使用了特殊的数据。需考虑重复数据、特殊数据。
  2. 操作问题:重现过程中的操作步骤是否有遗漏,这个需要测试人员非常耐心和细心观察。
  3. 前置场景:是否在一个特定的前置场景下才会有问题,这种经常集中在系统较复杂的情况下。
  4. 网络问题:远程测试过程中因为网络问题导致的缺陷。
    重现过程还可以借助日志和一些工具辅助,找开发一起分析在工作量较大的公司比较难实现,除非是重大问题。

首先还是要积极重现,实在重现不了如前面同学说的,评估缺陷的对交付的影响,如果影响小可以暂时忽略。

其次,无法重现的问题仍需要登记到缺陷系统,打上无法重现的标记,第一,如果不严重开发可以暂时不处理,如果严重开发需要分析代码;第二,方便自己后续或者其他同学一起观察。