很感谢“加大码”同志在上篇随笔的恢复，让我想起了许多问题。

         常言道，千里之堤，毁于蚁穴，软件同样如此。虽然软件中的BUG本身不会像蚁穴那样慢慢变大，但对用户而言，它引起的错误/异常等的次数却会越积越多，最终我们会失去用户，造成不可挽回的损失，因此，这些质量的问题，我们必须注意，并制定相应的措施、计划、方案去预防、测试、修正BUG的出现。

         至于如何做测试计划、如何写测试用例等之类如何预防“虫子”、如何查找“虫子”的文章比比皆是，但是发现“虫子”之后该怎么办呢？细想一下，这个问题并不十分简单。

         首先，对于有明显“病症”的BUG，一旦出现，我们需要立即详细记录BUG的表征，记录的越细致越好，对于用户而言，这一点往往很难达到，因为用户往往没有这方面的意识，因而我们得到的反馈往往是“有一个错误”、“运行到**地方突然提示出错了”等之类模糊的BUG报告。对于这一点，不管是做项目还是做产品，我们都因该在程序中建立尽可能完善的缺陷机制，这样，我们的程序的容错性、健壮性、可靠性等才能得到基本的保障。那么对于BUG，我们在缺陷机制的设计中因该包含哪些内容呢？我认为至少我们应该有一个日志文件，来记录BUG的时间、原因、导致BUG的语句或方法、堆栈，甚至包含上下文数据的描述，当然，这是在不严重影响性能的前提下完成的。当程序员拿到日志文件之后，就能够比较容易的再现BUG，进而改正之了。

         以上谈得是能够捕捉到的BUG。那么对于不能捕捉到的错误怎么办呢?我想在进行β测试之前，我们应该告诉参与测试的人员，一旦出现异常，应当细致的描述异常之前的操作步骤、使用了哪些数据、异常提示了什么，甚至干脆直接把异常抓图写在测试报告中，上面这些，在测试用例中都应有所体现。

     上面是偶的一些经验和想法，偶不是做测试的，算是抛砖引玉吧，提供一点思路，欢迎大家讨论。