调试程序不可重现的bug

　　修复不可充实的bug比修复可重现的bug困难得多。通常，能了解到的信息很少，必须进行大量猜测。不过，也有一些有帮助的策略：
　　（1）尝试将不可重现的bug转化为可重现的bug。通过充分的猜测，通常可以确定bug的大致位置。花一些时间尝试重现bug。一旦有了可重现的bug，就可以使用前面描述的技术找到bug的根源。
　　（2）分析错误日志。如果程序根据前面的描述带有错误日志生成的功能，那么这一点很容易实现。应该筛查这些信息，因为bug出现之前记录的任何错误都有可能会对bug本身有贡献。如果幸运（或者程序写得好），程序会记录到手头要处理的bug的准确原因。
　　（3）获取和分析跟踪。如果程序带有跟踪输出（例如之前描述的环形缓冲区），那么这一点很容易实现。在发生bug时，可能获得一份跟踪的副本。通过这些跟踪，应该能找到代码中bug的正确位置。
　　（4）如果有的话，检查内存转储文件。有些平台会在应用程序异常终止时生成内存转储文件。在Unix和Linux上，这些内存转储文件称为核心文件。每个平台都提供了分析这些内存转储文件的工具。例如，这些工具可以用来生成应用程序的堆栈跟踪信息，或查看应用程序崩溃之前内存中的内容。
　　（5）检查代码。遗憾的是，这往往是检查不可重现bug的根源唯一的策略。令人惊讶的是，这种方法往往奏效。检查代码时，甚至是检查自己编写的代码时，如果带着刚才发生的bug的视角，通常可以找到之前忽视的错误。不建议花很长时间盯着代码，而手工跟踪代码执行路径往往可以直接找到问题所在。
　　（6）使用内存观察工具，这类工具往往会警告一些并不总是会导致程序行为异常的内存错误，但是这些问题可能是手头上bug的根源。
　　（7）提交或更新bug报告。即使不能马上发现bug的根源，如果再次遇到问题，这个报告会使描述前面做出的尝试的有用记录。
　　一旦找到了不可重现bug的根源，就应该创建可重现的测试用例，并将其转移至“可重现bug”类别。重要的是在实际修复bug之前重现这个bug。否则，怎么才能测试bug是否修复？调试不可重现bug的一个常见错误是在代码中修复错误的问题。不能重现bug，也不知道是否真正地修复了这个bug，因此几个月之后这个bug再次出现，就没有什么可惊讶的。