1. 首先一定要报到缺陷库中
遇到复现不了的bug一定要报到缺陷库里，特别是一些比较致命的或者是严重的缺陷，一定要报！一定要报！一定要报！重要的事说三遍。
因为一般来说，复现不了的问题或者是复现率很低的问题，大部分都跟系统运行环境有关，比如当前系统的内存使用情况、CPU调度、服务器响应超时等情况，如果你操作时正好遇到这些情况发生了，问题就来了，但如果没有发生，问题就不会出现。但天有不测风云，关键是谁知道啥时候就碰到了呢。所以，千万不要偷懒，碰到一个咱就报一个，一般对于报到系统里面的bug，就算最后实在没有被解决掉，咱还有个申诉的地儿，如果你没有报，但最后线上被用户碰到了，那这个锅你就背定了，千万别给自己挖坑。
2. 既然要报，该怎么报？
对于这种无法重现的bug，在报的时候也有讲究。一般对于必现的bug，大家在报的时候不需要提供特别详细的日志啊、操作环境啥的这些信息，因为只要步骤写清楚，程序员自己复现了就可以定位问题了。但对于这种无法重现的bug，我上面说过，通常跟系统环境啊、系统状态啊、操作步骤啊、操作时间长短啥的都有关系。所以，咱们在报这类问题时，除了详细的复现步骤外，最好是把系统运行的日志信息、环境变量设置信息、操作了多长时间等信息都给附上，尽量帮助开发去进行问题的定位。一般只要有日志，哪怕操作时无法复现，开发人员也可以根据日志信息去定位问题，那就大大提高了定位问题解决问题的可能性。总结一下就是能写多少尽量写，不要怕麻烦。
3. 什么时候关闭bug？
报上去之后，问题又来了。既然是一个不好重现的bug，那咱们啥时候可以关闭这个bug呢？
如果开发人员那边凭运气找到了问题的原因解决了这个bug还好，但如果凭实力也没有定位到问题，这个问题又不好重现，那岂不是这个bug就会成了缺陷库的“老赖”，永远赖在库里不走了？这个倒也不是，一般对于确实无法定位、无法重现导致最终无法解决的缺陷，我们需要连续跟踪至少三个以上的回归测试版本，在三个以上的版本都无法重现（确实一次都没有再现过），我们才能在客观地记录了所有尝试复现的步骤和操作后，放心地把这个缺陷从库里给关掉。如果在三个版本内回测仍然会重现，那就继续reopen这个bug，继续让开发定位问题解决问题。
好了，以上就是我们应对无法重现的缺陷的一般方法。我说的这个方法没有那么多大道理，从实用性的角度出发，从我多年的工作实践来看，是非常具备可操作性的，希望可以给大家提供参考。当然，这样做了也是无法保证这种bug日后在线上就一定不会再重现的，实际上神仙也无法保证。对于这种玄学问题，我们就不必过于纠结了。但至少，我们这样做了，就算是万一真出了问题，我们作为测试工程师还可以拿话出来说，问心无愧，背锅也不是一个人背嘛，哈哈哈。