解决软件的Bug就像警察破案一样。警察在掌握了案件发生的时间地点和相关人物后进行分析推理，采访相关人员，排除嫌疑人，最终找到凶手。同样的，软件开发人员在接到Bug时，也是分析Bug发生的背景，然后在运用各种方法来找出问题的原因。并不是所有的Bug都能一眼看出问题发生在哪个地方。虽然Bug发生的原因千差万别，但是我们还是有一些比较通用的方法来逐步缩小bug的根源的范围。在水缸里面抓鱼要比在河里面抓鱼要容易，同样的如果能把问题的根源缩小到一个类，一个函数，那么我们就能更容易找出Bug是如何发生的了。本文结合最近的一些经验以及阅读的一些资料，简单谈谈如何有效地找出问题的根源。

　　1、哪些因素可能导致软件出现问题

　　简单来讲，导致软件出现问题的因素有如下几个方面：

　　● 软件自身的问题

　　● 第三方的问题，比如操作系统，第三方系统

　　● 用户的输入

　　但最终来讲都是软件的问题，是软件本身没有处理好这些变化的因素。因此，在刚接到Bug的时候，我们可能无法立刻判断问题是由哪个因素引起的，谁都可能是凶手，因此我们要逐渐缩小怀疑的范围。

　　2、利用实证来分析Bug

　　当问题出现了，我们可以根据看到的现象，结合问题发生的环境以及我们对软件逻辑的理解来分析推断出问题的原因。这当然是一种可行的方法，但是随着软件变得更加复杂，这并不是最有效的办法。软件调试相对于其他领域来讲还是比较容易的。比如，发生一起车祸以后，找出事故的原因只能靠分析，交警不能说事故现场没有发动机的日志，要求重现这个事故后再来分析事故的原因。而软件的优势就在于能做各种实验来证明你的想法。比如你怀疑是某个地方的问题，那么就去做个实验来看看。这就是利用实证的手段来分析Bug。它的一般步骤为：

　　● 根据你对问题和软件的了解，提出一个假设，比如你怀疑问题可能是Windows 2012上特有的。

　　● 根据你的假设，去构建实验来验证你的假设。同样，如果你怀疑问题是Windows 2012上特有的，那么可以做的实验之一就是到Windows 2008上去试一下，如果问题还是发生了，那就不能证明问题是2012上特有的。

　　● 根据实验的结果，你能对问题有进一步的认识，从而能将问题的范围缩小。

　　需要注意的是：

　　● 每次实验只能改变一个因素。假如某次实验和上个实现相比，你改变两个因素（比如既换了操作系统，又换了另外一个版本的软件），那么你就不知道这次实现的结果是由哪个因素引起的。

　　● 每次做实验都要有个明确的目的，并且要有记录，包括变化了什么，结果是什么。要不然，过了一阵可能就忘记了。