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