请坚信一点“有果必有因”！

任何BUG的发生的都有她的原因或者根源。BUG不会自己无缘无辜的跳出来给你看！呵呵！为什么这么说呢？因为BUG是我们不希望得到或者看到的结果，我们为什么要发现BUG呢？！是因为我们要解决她和规避她。我们如果只是发现BGU而不去解决她，那我们就没有发现她的必要了。既然一定要解决就必须找到问题的根源所在，就是产生问题的原因。其次才是想办法解决问题，马克思说过“发现问题就解决了问题的一半”。

我现在要说的是哪里会出现问题呢？当然这是个很大很广很复杂的问题。我没有什么权威，不敢做什么定义之类的东西。只是不自己在工作中的一点认识说出来，大家讨论讨论，分享一下。我觉得BUG来源于两个阶段，第一是需求阶段；第二是开发阶段。这里可能会有不同的意见，认为BUG是开发出来的，需求阶段怎么会出现BUG呢？！我要为开发人员喊冤了。那种出了问题就找开发人员的，是应该受到强烈抵制的哦。而在我开来来源于需求阶段的BUG更为严重（以我个人的经验和认识来讲的，不具备普遍性的哦）。这是就这个阶段的BUG的带来的后果和修改BUG的成本方面来讲的。主要有以下几个方面：

第一 需求遗漏或不全面

我们都知道需求来源于生活实践又高于生活实践。需求的提出必须在建立在全面的调查和系统的分析基础之上。没有调查就没有发言权。现在的软件需求有多少是经过调查和分析的呢？！往往是某个人拍拍脑袋就可以想出来的。这种现象是比较普遍的。有调查的不过是形式上的罢了。发放一些调查问卷，然后计算一下调查者认同的百分比就完事了，然后不管什么结果就开始立项了。

没有调查和分析的结果就是需求遗漏或不全面。需求都没有计划或设计的东西，开发人员怎么做出来而且做的正确呢？往往是完成开发后，这种情况没有考虑，那种情况没有设计。要靠测试人员设计用例来发现问题是多么的难啊。要是上线以后出现了问题，严重性不可估量啊。

对于开发来说，对于这种需求遗漏是最害怕的。有可能为了添加或补充这种需要修改整体的架构就难以接受了。往往测试人员对于这方面的问题也无从下手。

关于冒烟测试，应该是微软首先提出来的一个概念，和微软一直提倡的每日build有很密切的联系。具体说，冒烟测试就是在每日build建立后，对系统的基本功能进行简单的测试。这种测试强调功能的覆盖率，而不对功能的正确性进行验证。

就象生产汽车一样，汽车生产出来以后，首先发动汽车，看汽车能否冒烟，如果能，证明汽车最起码可以开动了。说明完成了最基本的功能。

　　冒烟测试一般用于每日构建(Nightly build)，构建服务器首先从CVS服务器上，下载最新的源代码，然后编译单元测试，运行单元测试通过后，编译可执行文件，可执行文件若可运行，并能执行最基本的功能，则认为通过了冒烟测试，这时，构建服务器会把程序打包成安装文件，然后上传到内部网站，第二天一早，测试人员来了以后，会收到构建服务器发来的邮件提示昨晚是否构建成功。若构建成功，则测试人员进行相关的功能测试。所有这些功能的完成，一般是靠编写脚本完成的，目前比较常用的脚本有TCL，Perl，Python及功能弱弱的批处理。用这些可以完成系统的每日构建。

　　简单的说，就是先保证系统能跑的起来，不至于让测试工作做到一半突然出现错误导致业务中断。目的就是先通过最基本的测试，如果最基本的测试都有问题，就直接打回开发部了，减少测试部门时间的浪费。