吐槽

请先允许我对此类 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！