在介绍bug的光辉历史的时候，不经意间给bug蒙上了一层神秘的面纱，仿佛bug是一个遥远的神秘的事物，如同金字塔之中的种种。其实bug本身并没有那么神秘。

　　首先给出一个“官方”的定义，来自Ron Patton《软件测试》：

　　>>>>>>

　　至少满足下列五个规则之一才称发生了一个软件缺陷（Software bug）：

　　1）软件未实现产品说明书要求的功能

　　2）软件中出现了产品说明书中指明不应该出现的错误

　　3）软件实现了产品说明书未提到的功能

　　4）软件未实现产品说明书虽未明确提及但应该实现的目标

　　5）软件难以理解、不易使用、运行缓慢或者——从测试人员的角度看——最终用户会认为不好

　　<<<<<<

　　关于上面的“官方”解释我就不做赘言了，“照搬”是没有意义的，所以如果需要了解更多，请阅读原书《软件测试》（Ron Patton）著。从我自己的经验来看，所谓bug，大致可以分为“该做的没做，做了不该做的，没有按要求做”，我自己就是这样简单的来对bug做出分类。

　　所谓“该做的没做”的又包含了三个部分，即

　　● 产品说明书中要求做的没做

　　● 产品说明书中没有明确要求（单独作为项目列出）但是应该实现的

　　● 产品说明书中没提到，但是测试人员认为应该做的

　　对于上面的“该做的没做”三种情况应该区别对待，对于第一种就很直接了，产品说明书中列出来的功能没有实现，直接作为bug提交了；第二种稍微麻烦一点，需要跟开发人员统一认识；第三种就更加麻烦了，这时候需要开发人员项目经理测试人员一起合计合计了，统一认识之后再决定怎么处置这个bug。

　　所谓“做了不该做的”，这句话是作为测试新人和开发人员来讲最难理解的bug，这里并不是指它的概念或者意义等理性可以解决的事情，而是感性层面的“理解”。试想开发人员好不容易做了一个新功能，测试人员却拿着“产品说明书”这根鸡毛当令箭来要求删除，大多数人可能会想到，额外的功能总是好的……但是，需要提醒的是，每一个额外的功能都有引入额外的bug的风险，这不仅仅增加了测试的工作量也增加了产品的质量风险，更重要的是，增加的额外功能的合理性是否确定。比如我们开发一个课程管理系统，一般情况下产品说明书中要求给普通用户的功能只有登陆和浏览，这个时候如果开发人员提供了其他额外的功能如搜索，排序甚至编辑，这就会出现问题了，这些额外的额操作会额外增加系统或者服务器端的负担，甚至具有安全问题。当然，对于“做了不该做的”类型的问题，需要找到相关开发人员与PM一起确定，测试人员是不应该自以为是地作为bug提交，至于原因，在后续的文章中会提到。

　　所谓“没有按要求做”，这里的要求是指“应该做成什么样子”，这些内容是依据产品说明书来定的，比如一个“职位”选项，产品说明书中明确指出使用“下拉框”来处理，而开发人员偏偏使用了“文本框”，这些都是bug。对于这种类型的bug，辨别和处理相对就比较简单了，而且我们找到的大部分bug也都是这种类型。

　　关于bug的定义，其实直到现在都没有“官方定义”，这也为什么我引用Ron Patton的话的时候使用的是“‘官方’定义”的原因了。上面提到bug的时候，总是带着一个亲属“产品说明书”，实际上在当前中国很多软件项目中并没有这个东西，因此在项目实践过程中，上面提到的内容千万不要生搬硬套，至于怎样灵活处理，在后续文章中也将提到个人见解。

　　以上为个人见解，欢迎大家一起交流。