亲爱的BUG，你现在还好吗？

面试的时候，我常常让应聘者介绍一下他们处理BUG的流程，较好一点的流程如下：测试提出BUG并提交到BUG控制系统中，某个Leader负责把BUG分配给的相关人员去修改，修改之后提交版本，测试人员验证，验证不通过打回继续改，通过了测试就进行一下关闭操作，之后就再没有机会和这个BUG见面了。有差一些的测试人员直接坐在开发人员的旁边测试，有BUG子，直接告诉开发人员，如果开发人员自信能够记住这些BUG，就逐个从记忆中提取修改，不自信的就找张纸、找个本、找支笔写下只言片语，然后逐次修改，修改之后，编译个版本给相应的测试人员，测试再测，如此循环往复，直到BUG解决。BUG验证通过了，就再也没有人去理会他了，它的生命旅程也就结束。

我认为这样处理BUG，看轻了BUG的价值，就像拿着英镑当日元用，太浪费了。

BUG是整个生命周期中缺陷和问题的最终表现形式。如果我们在开发软件各个环节的工作做非常完美，一点缺陷没有，一点问题没有，需求文档完全反应用户现在和将来的需求，设计也完全正确地反应需求的内容，程序结构非常合理、编码一点瑕疵没有，测试用例也完整，发版准备地非常充分，用户培训非常到位，试想不论是在我们公司内部的测试阶段还是在用户的测试及使用过程中还会这么多的BUG产生吗？正是我们的工作中有各种各样的缺陷和问题存在，才导致了这些BUG的产生。

    而我们解决BUG时的要求仅仅是让发生这个BUG的程序能够正常运行，忽略调查追究BUG产生的深层原因，就像除去杂草时我们只把看到的地上面的部分铲除了，没有深挖地下根，没有做到“斩草除根”，换一个模块，换一个项目还会生发出同样的bug。

怎么才能做到“除根”呢？这就需要对这些修改后的BUG进行分类分析，针对每个BUG多问几个“为什么”，找到产生BUG的最根本原因。是开发流程的问题去修正流程，是人员能力的问题就安排相应的工作去提高，是软硬件环境的问题则看如何绕过等等。

通过这样的分析就能够修正我们的工作流程和规范，提高个人能力，绕过大部分软硬件的问题，在以后的工作大大减少BUG的出现，让我们不会被同一块石头绊倒，达到“吃一堑，长一智”。

这样的分析还能帮助我们找到程序中的关键模块，有调查表明：80%的BUG发生在20%的模块中。我们就可以针对这些关键模块可以下大功夫去做更多的工作来避免BUG的发生，提高代码的质量。

通过BUG的分类分析还能够帮助我们找到当前项目中类似的还未被发现的BUG。

要做好BUG的分类分析一个最基本的前提就是详细记录BUG的相关信息，比如BUG发生的操作步骤、期望正常现象、BUG现象、重现几率、发生时软硬件环境、发生原因、发生的模块以及方法、解决方法、BUG的种类等。没有这些信息BUG的分类分析就无从下手。

每个BUG也有自己的生命过程，就像良田里的杂草，也会经历播种、生根、发芽、成长、成熟等过程。发现地越早解决它们的代价越小。通过BUG的分类分析能够完善我们的工作流程和规范，提高个人能力，找到项目中的关键模块，发现同类型的BUG，达到能够尽早发现和避免大部分已知的BUG，也达到了充分利用BUG的价值。