4、Bug的种类

　　需求阶段的BUG——来源：

　　● 模糊不清的需求

　　● 忽略的需求

　　● 冲突的需求

　　分析、设计阶段的BUG——来源：

　　● 忽略设计

　　● 混乱的设计 ：这样的情况发生在两种设计性质完全相反的情况中，如果在实际的系统中，某块地址规定不允许被多线程访问，而方案却被设计成以多线程方式进行，则会在此层面上产生BUG，严重的会造成整个系统的崩溃。

　　● 模糊的设计：模糊BUG产生的原因在于设计人员对需求没有清晰的认识，或者需求本身就是含糊不清的。

　　实现阶段的BUG——来源：

　　● 遗漏的功能

　　● 内存溢出：属于一种比较严重的软件BUG类型。例如，软件执行了某些强行向操作系统保护地址写入数据的指令，导致整个环境的彻底崩溃；再如：数值除零导致堆栈溢出

　　● 其他实现：表现为出现的错误难以定位其类型，比如在产品化阶段，测试人员或者最终用户提出的部分提高程序运行效率的建议，当然开发人员并不完全处理这些问题，但是这些建议将成为一种特殊的BUG类型，被保留在项目数据库中。

　　配置阶段的BUG

　　● 配置阶段的BUG是最危险的，往往体现在软件交付或者最后的系统测试中。

　　● 配置阶段的BUG出现的原因是复杂的，比较典型的是旧的代码覆盖了新的代码；或者测试服务器上的代码和实现人员本机最新代码版本不一致。这些情况造成了错误代码被修改后，经过一个时间段再次回归测试时又会出现同样的问题。

　　● 配置阶段的BUG解决方案也很简单，项目组可以指定专人（集成员）进行配置和集成管理，集成员保证正确集成整个系统，并将最新的代码发布到测试服务器或者客户服务器上。这个阶段由QA（质量保证）部门负责监管和控制，规定集成的时间间隔和最佳集成时间，统一维护一份项目组集成人员和集成时间列表。

　　短视将来的BUG

　　● 很多软件BUG都是设计人员或者实现人员的眼光短浅造成的，出名的例子就是“千年虫”问题。

　　● 其他短视的BUG例子还有我们以前的身份证号码，原来的15位的编号根本不符合一人一号的设计要求，重码的现象相当严重。所以出现了18位号码。

　　● 再如：中国移动开发了134号段的号码。现在又有了159号段。

　　静态文档的BUG

　　● 文档BUG的定义很简单，即说明模糊、描述不完整和过期的都属于文档BUG。

　　● 说明模糊特指无充分的信息判断如何正确地处理事情。例如设计文档中说明了对类实例方法的调用，却没说明边界条件和特殊的调用顺序。

　　● 描述不完整特指文档信息不足以支持用户完成某项工作。例如某套软件的某一项操作有具体的前置条件，而客户从文档上并没有获取关于该前置操作的相关信息，客户便认为软件存在着BUG。

　　● 过期文档本身就是错的并且无法弥补，这种现象经常发生在后期对系统功能修改而没有及时更新对应的文档，造成了文档的不一致性。

　　5、BUG的生命周期

　　● BUG初始状态（Unconfirmed&New态）
　　● BUG分配状态（Assigned态）
　　● BUG重新分配状态（Reassigned态）
　　● BUG修复状态（Resolved&Fixed态）
　　● BUG验证状态（Vertified&Fixed态）
　　● BUG重新打开状态（Reopen态）
　　● BUG关闭状态（Closed&Fixed态）