一篇文章讲清楚如何对软件缺陷进行管理(5)

短视将来的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态）

6、BUG生命历程的5种典型过程

（1）BUGStart--> BUG初始状态 -->BUG分配状态-->BUG重新分配状态 --> BUG修复状态 -->BUG验证状态 --> BUG关闭状态

测试人员发现BUG并且将该BUG标记为Unconfirmed&New状态，下一步测试人员在排除BUG的登记错误后，将该BUG置为Assigned状态。实现人员接到该BUG通告

进行BUG确认，确认成功后该BUG状态被置为Reassigned状态，当实现人员修复BUG后该BUG置为Resolved&Fixed状态。测试人员对实现人员修复后的BUG进行确

认测试，如果该BUG被正确修复了，那么其状态被置为Closed&Fixed状态，同时意味着该BUG的整个生命周期终结了

（2）BUGStart--> BUG修复状态 --> BUG验证状态 -->BUG关闭状态

原文转自：http://www.uml.org.cn/Test/201611161.asp