CQ的BUG管理流程[附图]
CQ的BUG管理流程(以BUG状态为线索)：一、测试人员提交bug,BUG状态为submit
二、测试主管审核bug严重度:
1)认为是BUG的,则此时BUG状态为reviewed
2)认为不是BUG的,状态为refused
3)认为属于前一版本已提交,这版本还没解决的的BUG,则duplicate
4)认为是不是BUG的,状态为NA(基本上测试主管认为不是BUG的问题,都用refused来标识)
三、项目经理查看bug:
1)认为不属于BUG的，状态为NA
2)能解决的,分配到各模块负责人,BUG状态为assigned
3)认为暂时不解决的(时间,人力的约束),状态为suspended
4)认为需要延时解决的,状态为postponed
5)认为已提交过此BUG的,状态为duplicate
6)认为是由于测试的环境或操作所引起的问题,,状态为rejected
四、开发人员
1)解决此BUG,状态为resolved
2)不属于BUG的,状态为declined
3)属于重复提交的BUG,状态为duplicate
五、测试人员
1)通过验证或回归测试或新版本发布测试,确认此BUG已解决的,将BUG状态改为closed,闭环;
2)若该BUG,则将BUG状态改为reactived,重新激活;
[ Last edited by 测试有前途 on 2005-8-11 at 10:57 ] 顶 一 下！ 是这样的管理流程。但是，我们用时，没有这么多的状态。（如：declined、suspended等都没有），可能，我们没有分工那么细。 很详细啊
不错不错 我想问一下,这个流程可以按要求修改吗? 当然可以。缺陷管理流程本来就是按照自己公司的需要定制的，没有什么统一的标准。 但是,我这里有很多楼主提到的 状态找不到(例如: Reviewed)。
我用的是CQ2003。
请指教~~~ 没有就自己添加呗。
工具仅仅是工具，具体的设定还要自己动手的。 对，可根据公司的实际情况进行定制的呢 学习中。。。。。。。。。。。。。。。。。 我有些不明白下面的话?是不是有歧异?
4)认为是不是BUG的,状态为NA(基本上测试主管认为不是BUG的问题,都用refused来标识) 谢了 new(tester)--open(dev)--fixed(dev)-closed(tester)
1）测试人员提交的bug 不被开发人员接受 直接failed掉
2）开发人员修复的bug 再次出现问题，或修复不成功，测试可再次打开（reopen） 没用过，有没下载地址啊 不错 熟悉一下bug的管理流畅
谢谢
顶顶顶顶顶顶顶顶顶顶顶顶顶顶顶顶顶顶 公司也用CQ来管理BUG，感觉很不错，不过对于BUG的各种状态和楼主描述的有些不一样，但重点还是要否和公司的实际情况，感谢分享 学习中 很详细但如果不属于缺陷的话，直接refused就行了吧 不错的说！
页:
[1]
2
