偶现bug如何处理?

请先允许我对此类bug进行吐槽,相信做测试的同学都碰见过这种bug!
  我们在测试过程中经常会碰见一类很头疼的bug,就是偶现性的bug,所谓偶现性,是相对于必现而言,这类bug有些可以有重现路径,但是可能需要重复操作十几次甚至上百次才可能重现一次,重现概率比较低,这种bug我暂分类成偶现可重现。另一种则是没有重现路径,找不到任何的规律,但时不时的会出现,这个分类成偶现且难以重现。对于这类偶现bug,测试很头疼,因为需要花费相当多的时间去复现bug,修复之后还要去验证。开发也很头疼,测试如果没法复现,那么需要开发自己尝试找bug、调试、解bug(大多数开发只愿意解bug,而不擅长找bug)。一般来说遇到偶现的bug,都是尝试去按照出问题的方向复现,然后去review对应代码的逻辑,但是代码逻辑review了很多次,加了很多log,也没有找到。一点头绪都没有的情况下,大家是怎么应对这种情况的。

这里对偶现且难以重现的bug进行下经验总结,有不足之处欢迎指出。
在测试过程中发现bug后的处理方法:
  1.抓取log、截图、视频
  2.别急着去复现bug,先仔细回忆下自己的操作步骤及前置环境
  3.找到能重现的步骤,然后再定位代码,还得考虑数据的因素(检查变量变化是否正确)

  有时候测试人员很大的价值就在于能重现难以重现的bug,这需要思维的开阔、经验的积累以及掌握较好的测试技术或者开发技术。bug的出现都必然有一个可重现的路径,只是问题在于我们是否能找到这个路径,因为影响bug重现的因素很多,如环境的改变(硬件环境、网络环境等)、不经意间被忽略的操作、使用的数据是否相同等等。个人一方面对这类bug很怕,因为一旦出现,如果对功能影响很大的话,就需要花很多时间去重现它,而且并不保证就一定能重现。但另一方面又喜欢去挑战这类型的bug,当你通过种种想法、测试技巧去将它重现之后,你会相当的有成就感!
当碰见这种bug,要做的事情:
  1.抓取log、截图、视频
  2.仔细回忆,记录前置环境、操作步骤、使用过的数据
  3.尝试去重现

当发现尝试多次仍无法重现时,先给开发提单,附上能取到的所有日志及截图、详细前置环境及操作步骤、可初步的注明bug出现的概率(百分之一、千分之一)。
对bug进行评估,确定优先级,如果优先级高的话,将bug单发给组内的同事,让大家帮忙关注该bug。
与开发沟通,猜测可能出现问题的地方,在代码中设桩,添加状态打印信息,进行有针对性的测试。
考虑采用自动化,进行压力测试,测试过程中注意收集log信息,统计bug出现的概率。
仍旧无法重现,就只能采取亡羊补牢,关注发布后的用户反馈,跟进bug。

  1.首先你需要在代码里做尽可能多的保护和异常处理:大部分的异常是可以抓到的,能抓到基本上问题就可以解决了。即使你没有管,设备上也会有crash log的,解析出来崩溃的位置后,debug工作会简单很多。实在不行你说的log方式也很好用。
  2.让tester确定复现步骤,概率极低其实可以不去修复。1/50嘛,我觉得还是有点高,如果重新操作一遍不会遇到同样的问题(就是说和windows一样重启可以解决的问题),那可以不修复的,非阻塞型的bug嘛。如果是会阻塞后续操作,重来一遍还是要修复的。

问题的验证:
建议采用自动化的方式验证+收集用户反馈

最后,有时候发现bug、重现bug,运气很重要!希望大家都做个负责的Tester!

 

App crash崩溃追踪,原因定位分析

https://www.jianshu.com/p/c4abdd2c3576

posted @ 2019-02-26 18:35  南方的墙  阅读(8290)  评论(0编辑  收藏  举报