移动测试基础 Android 测试中对于偶现且难以重现的 bug 的处理

xuxu · 2015年03月28日 · 最后由 securitytest 回复于 2017年09月26日 · 1700 次阅读

吐槽

请先允许我对此类bug进行吐槽,相信做测试的同学都碰见过这种bug!

我们在测试过程中经常会碰见一类很头疼的bug,就是偶现性的bug,所谓偶现性,是相对于必现而言,这类bug有些可以有重现路径,但是可能需要重复操作十几次甚至上百次才可能重现一次,重现概率比较低,这种bug我暂分类成偶现可重现。另一种则是没有重现路径,找不到任何的规律,但时不时的会出现,这个分类成偶现且难以重现。对于这类偶现bug,测试很头疼,因为需要花费相当多的时间去复现bug,修复之后还要去验证。开发也很头疼,测试如果没法复现,那么需要开发自己尝试找bug、调试、解bug(大多数开发只愿意解bug,而不擅长找bug)。。

这里对偶现且难以重现的bug进行下经验总结,有不足之处欢迎指出。

偶现且难以重现

首先先啰嗦几句测试人员在测试过程中发现bug后的处理方法:

1.log的及时抓取
2.截图
3.视频
4.别急着去复现bug,先仔细回忆下自己的操作步骤及前置环境

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

当碰见这种bug,要做的事情:

1.抓取log、截图
2.仔细回忆,记录前置环境、操作步骤、使用过的数据
3.尝试去重现

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

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

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

如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!
共收到 6 条回复 时间 点赞

一楼顶~~

个人经验,如果是在 E2E 测试中遇到这类bug,那么环境方面的日志(如网络包记录)会产生很大帮助(网络本身就是 E2E 测试中最不稳定的因素)。同时一定要关注是否有内存泄露!很多时候应用无故crash且遇到的前置条件各不相同,都是由于内存泄露到最后被系统强制关闭了。
另外,回忆操作步骤也是很重要的一步。我测试中曾经发现过一个自己以为是偶现的bug(前面很多个版本都没出现过,而且也没有明确重现步骤,重现概率为千分之一不到),现象是在某个界面进行点击操作,有时候软件会crash。后面回忆操作时和平时的主要区别是除了手指外,手掌也碰到了屏幕某个区域,最后发现是程序隐藏控件没做好处理,当点击到隐藏控件所在位置时隐藏控件的点击事件被错误地被触发了。开发也说完全想象不了这样的bug怎么能被纯手工发现。。。

顶赞“希望大家都做个负责的Tester!”

这种bug真的很头疼,即使做到上面这些,开发通常也很难解决

顶赞“希望大家都做个负责的Tester!”

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册