bug管理流程

2010-03-19  李康 

状态流程图:
软件错误的状态:
新信息(New)测试中新报告的软件缺陷;
打开 (Open)被确认并分配给相关开发人员处理;
修正(Fixed)开发人员已完成修正,等待测试人员验证;
拒绝(Declined):拒绝修改缺陷;
延期(Deferred):不在当前版本修复的错误,下一版修复;
关闭(Closed):错误已被修复。  
 
人员角色:

new—tester(测试工程师)

declined-not bug--Test Supervisor(测试主管)

declined-duplicated--Test Supervisor(测试主管)

open--Project Manager/Technical Manager(项目经理/技术主管)

fixed—programer(工发工程师)

closed—tester(测试工程师)

deferred-next build--Test Supervisor(测试主管)

deferred-next main release--Test Supervisor(测试主管)

 

Bug管理的一般流程:

1.         测试人员提交新的Bug入库,错误状态为New

2.         高级测试人员验证错误,如果确认是错误,分配给相应的开发人员,设置状态为Open。如果不是错误,则拒绝,设置为Declined(拒绝)状态。

3.         开发人员查询状态为OpenBug,如果不是错误,则置状态为Declined;如果是Bug则修复并置状态为Fixed。不能解决的Bug,要留下文字说明及保持BugOpen状态。对于不能解决和延期解决的Bug,不能由开发人员自己决定,一般要通过某种会议(评审会)通过才能认可。

4.         测试人员查询状态为FixedBug,然后验证Bug是否已解决,如解决置Bug的状态为Closed,如没有解决置状态为Reopen

 

软件错误流程管理要点:

    为了保证错误的正确性,需要有丰富测试经验的测试人员验证发现的错误是否是真正的错误,书写的测试步骤是否准确,可以重复。

    每次对错误的处理都要保留处理信息,包括处理姓名,时间,处理方法,处理意见,Bug状态。

    拒绝或延期错误不能由程序员单方面决定,应该由项目经理,测试经理和设计经理共同决定。

    错误修复后必须由报告错误的测试人员验证后,确认已经修复,才能关闭错误。

    加强测试人员与程序员的交流,对于某些不能重复的错误,可以请测试人员补充详细的测试步骤和方法,以及必要的测试用例。

 

   
646°/6389 人阅读/8 条评论 发表评论

金鑫  2010-03-19

我们的缺陷处理流程相比之下简单很多。当然这需要建立在准确清晰的缺陷问题描述的基础上


王恩建  2010-03-19

金鑫: 我们的缺陷处理流程相比之下简单很多。当然这需要建立在准确清晰的缺陷问题描述的基础上
他们的流程要严谨一些,bug质量应该也高一些。


孙建伟  2010-03-19

这种比较适合比较大的项目,人员比较多的时候


李康  2010-03-19

是的哦!从发现BUG开始我们就会一直跟踪下去,直到关闭这个BUG.不过我们的人员组成也没那么详细,很多时候是一人身兼数职。


彭方  2010-03-23

Declined—— 我们也是比较大的项目,目前对拒bug这一个环节做很多分类,主要是责权的分类:测试原因的错误和重复bug(Reject),开发原因不能修改的bug(Cannot fix)和需求原因设计如此的bug(by Design);
除了第一种,另外两种还有走下去的流程;


袁帅  2010-06-09

顶, 和你写的是一样的想法。


袁帅  2010-06-10

又来了 ~


陈静伟  2010-08-11

对我这样的新新手和很有用,学习了


登录 后发表评论