Bug管理的简单流程

Bug管理的简单流程：

BUG的各种状态：

◆新错误(New)：测试中新报告的软件缺陷。

◆打开 (Open)：错误被确认并分配给相关开发人员处理。

◆修正(Fixed)：相关开发人员已完成修正，等待测试人员验证。

◆拒绝(Rejected)：拒绝修改缺陷。包括两种情况：

拒绝-不是错误（Rejected-Not Bug）：报告的错误不是错误。

拒绝-重复（Rejected-Duplicated）：以前已经报告过这个错误，需要指出已经报告过的错误ID编号。

◆重新打开（Reopen）：没有正确修复的错误，需要进一步修复。

◆延期修改(Deferred)：不在当前版本修复的错误，以后的版本修复。

◆不能重现(Reproduct):开发人员在自己的环境下不能重现的缺陷。

◆关闭(Closed)：错误已被修复。

BUG管理的基本流程：

1、测试人员提交新的Bug入库，此时BUG状态为New。

2、错误被确认，项目经理将Bug分配给相应的开发人员，设置Bug状态为Open,

与此同时，测试人员和开发人员同时收到改变Bug状态的邮件。特殊时候若测试人员非常了解Bug所属，测试人员也可直接分配Bug给开发人员，并设置置Bug状态。

3、开发人员查询状态为Open和Reopen的Bug，若Bug反映的问题是由于开发平

台本身的缺陷或是测试人员操作错误引起时，置Bug状态为Rejected；

4、当Bug反映的内容不包含在当前需求规格说明中，属于升级或者优化功能,且该

Bug的存在不影响客户操作的顺利进行,开发人员可以延迟修复时间，置Bug的状态为Deferred；是Bug则解决并置状态为Fixed，Rejected和Deferred的Bug，开发人员要留下文字说明。

5、测试人员查询状态为Fixed的Bug，然后验证Bug是否已解决，如解决置Bug

的状态为Closed，如没有解决置状态为Reopen。

Bug的状态每改变一次，都会邮件周知相关的人员，让其明确Bug的当前状态。

对于不能解决和延期解决的Bug，不能由开发人员自己决定，一般要通过某种会议（评审会）通过才能认可。

一般输入到库中的Bug，原则性不能删除，及开发人员和测试人员没有删除的权限。

一般管理员有此权限。

对于测试人员和开发人员要加适当的使用权限，测试人员一般只有新增、查询、验证等权限，开发人员一般只有查询、解决等权限。测试负责人和项目经理可以适当地加大使用权限。

Bug的生命周期：