难以重现的Bug怎么处理

在开发过程中，不管是开发人员还是测试人员最不愿意碰到就是偶现的Bug。如果复现吧需要花费大量时间和精力，而且还不一定能成功复现，不复现吧到线上出了问题谁都受不了。
为什么不能重现Bug？
1.环境的变更造成了bug难以重现，被测物自身发生了某些变更。环境的变更一般是由于多人共用环境造成的，也有少量情况下是系统内部或者时间触发的变更（这类bug非常难重现）。
2.没有找到真正引发bug的操作和步骤。这些操作往往是一些不怎么显而易见的操作，测试人员在不经意间完成，而又忽略了这一操作，以致难于重现bug。
3.bug须要使用特殊数据才会出现
应对的方式

仔细观察：第一件事情就是要观察，观察你所做的一切操作和一切相关的系统反馈。

详细记录：详细记录你的操作步骤及返回结果非常有助于回朔问题，也有助于后续分析。准备一个word文档，和截图工具有时候非常必要。另外，在观察的时候，你不仅要注意被测物的最终返回，还需要观察过程中的一些中间状态，往往这些中间状态提供的信息才是解开问题的关键。这些中间状态一般会被记录在log文件中，因此知道你的被测物是如何记log的，log被记录在哪里非常重要。log给了你另外一个看系统的角度。log是有级别的，如果级别可以动态调整，在找比较难找的bug时，可以将log记录的级别调至最低（DEBUG级）让它们记录更多内容。利用系统的错误转储文件（比如linux的core dump文件，windows下也有相应的记录转储文件的方式）分析也是个不错的办法（需要较高技术能力），但一般建议测试人员把这些转储文件交给更专业的开发人员来分析。

科学分析：对于黑盒测试人员来说，科学分析意味着你需要有一定的分析策略。我们需要采取一些形式化的方法来完成我们的分析。

严密推理：天马行空对测试人员很重要，但是当你试图重现一个bug的时候，这并不是一个非常好的方法。抓住了蛛丝马迹，你就要推理是为什么产生了这种蛛丝马迹。限于工作性质，测试人员更多的会从：业务完整性、数据完整性、业务正确性、数据正确性等方面考虑问题。但是，如果测试人员对被测物的IT架构有比较深入了解的话，推理的范围会扩大到技术实现层面，如：多线程可能引发的问题，网络引发的问题，excepiton处理不当引发的问题，全局事务设计不当引发的问题，内存泄漏引发的问题，数据库表设计不合规引发的问题等等等等，这些会让你的分析推理能力如虎添翼。当然，如果限于条件，测试人员不具备这类能力，则应该在适当的时候请求开发人员协助。

有序求证：这里只有一点需要注意。那就是，在求证的过程中不要打散弹枪，按照你的推理一步一步的来，一个个推理的来验证，一次只引入一处修改。这样才能让你的捕虫网编制的足够细密。

大胆假设：有的时候，看似八竿子打不着的东西竟然存在着千丝万缕的联系，而你获取信息的过程总是一个由少及多的过程，一开始这些联系是无法被识别出来的。天马行空这时候从一定程度上又变得有用起来，当然天马行空也不是无厘头，还得靠我们所谓的“灵光一闪”，这号称是潜意识在帮助你。

坚持不懈：话不多说，有的时候你差的就是那么一点儿点儿耐心。

团队协作：很多情况下，重现bug不是一个人能搞定的。我们需要各种不同的视角开拓思路、加深对被测试物的认识。

一点儿运气：说实在的，有的时候重现bug就是靠运气，你不得不承认这一点。事实上很多美好的事情发生都得依靠运气。

主要的方法
获取手机上的LOG文件、查看当时数据库里的帐号状态
实时的数据监控和分析。记录场景、行为等数据，能有效缩小问题的范围。
有几个入口，通过其他路径是否可以进入这个页面或者操作
弱网情况下操作

借鉴地址：
https://www.cnblogs.com/skytraveler/archive/2014/09/23/3985015.html