遇到偶现性bug该如何处理和跟踪

我们在进行测试的过程中，难免会发现软件的bug。

有些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，要做的事情：
　　1.抓取log、截图、视频
　　2.仔细回忆，记录前置环境、操作步骤、使用过的数据
　　3.尝试去重现

当发现尝试多次仍无法重现时，先给开发提单，附上能取到的所有日志及截图、详细前置环境及操作步骤、可初步的注明bug出现的概率（百分之一、千分之一）。
对bug进行评估，确定优先级，如果优先级高的话，将bug单发给组内的同事，让大家帮忙关注该bug。
与开发沟通，猜测可能出现问题的地方，让开发协助查看代码走向，添加状态打印信息，进行有针对性的测试。
仍旧无法重现，

我们一把需要把bug保留3个版本，持续关注。

并且需要关注发布后的用户反馈，跟进bug。