Bug管理的简单流程.doc

《Bug管理的简单流程.doc》由会员上传分享，免费在线阅读，更多相关内容在工程资料-天天文库。

1、Bug管理的简单流程：BUG的各种状态：◆新错误(New)：测试中新报告的软件缺陷。◆打开(Open)：错误被确认并分配给相关开发人员处理。◆修正(Fixed)：相关开发人员已完成修正，等待测试人员验证。◆拒绝(Rejected)：拒绝修改缺陷。包括两种情况：拒绝-不是错误（Rejected-NotBug）：报告的错误不是错误。拒绝-重复（Rejected-Duplicated）：以前已经报告过这个错误，需要指出已经报告过的错误ID编号。◆重新打开（Reopen）：没有正确修复的错误，需要进一步修复。◆延期修改(Def

2、erred)：不在当前版本修复的错误，以后的版本修复。◆不能重现(Reproduct):开发人员在自己的环境下不能重现的缺陷。◆关闭(Closed)：错误已被修复。BUG管理的基本流程：1、测试人员提交新的Bug入库，此时BUG状态为New。2、错误被确认，项目经理将Bug分配给相应的开发人员，设置Bug状态为Open,与此同时，测试人员和开发人员同时收到改变Bug状态的邮件。特殊时候若测试人员非常了解Bug所属，测试人员也可直接分配Bug给开发人员，并设置置Bug状态。3、开发人员查询状态为Open和Reopen的B

3、ug，若Bug反映的问题是由于开发平台本身的缺陷或是测试人员操作错误引起时，置Bug状态为Rejected；4、当Bug反映的内容不包含在当前需求规格说明中，属于升级或者优化功能,且该Bug的存在不影响客户操作的顺利进行,开发人员可以延迟修复时间，置Bug的状态为Deferred；是Bug则解决并置状态为Fixed，Rejected和Deferred的Bug，开发人员要留下文字说明。5、测试人员查询状态为Fixed的Bug，然后验证Bug是否已解决，如解决置Bug的状态为Closed，如没有解决置状态为Reopen。B

4、ug的状态每改变一次，都会邮件周知相关的人员，让其明确Bug的当前状态。对于不能解决和延期解决的Bug，不能由开发人员自己决定，一般要通过某种会议（评审会）通过才能认可。一般输入到库中的Bug，原则性不能删除，及开发人员和测试人员没有删除的权限。一般管理员有此权限。对于测试人员和开发人员要加适当的使用权限，测试人员一般只有新增、查询、验证等权限，开发人员一般只有查询、解决等权限。测试负责人和项目经理可以适当地加大使用权限。Bug的生命周期：