BUG的生命周期？？
始于New，终于Closed，具体的步骤呢？？？ 我认为步骤是这样:1.项目经理提交新版本
2.测试人员对新版本进行测试,找出bug,然后提交bug给测试经理
3.测试经理对提交上来的bug判断是否有重复的,如果重复则duplicate,若不重复则判断是否现在就修改,目前不修改则postpone,等到合适时机再提交修改
4.如果不重复则提交给开发经理,由开发经理分配bug给相关的开发人员进行修改
5.开发人员open bug,若确认bug不是错误无需修改则rejectd.
6.评审专家组对被拒绝的bug评审是否需要修改,评审通过确定不用修改则abandon.不通过则reopen
7.开发人员对bug进行修正fixed,然后提交给测试人员进行回归测试
8.回归测试通过则对bugclosed .
9.若回归不通过则再提交给开发人员重新修改reopen,直到回归通过最终closed. 一般bug是不会close的除非重复了或者not a bug或者will not fix。
正常bug的生命周期的最后一步是verified.回归测试通过是verified而不是close。一般的tester也不应该具有close bug的权限。
close应该是leader的事情而且不同公司似乎有不同的做法，有的就是verified为最终结果。
[ 本帖最后由 baizhudan 于 2007-8-7 17:39 编辑 ] 测试人员或者开发人员发现BUG
↓
测试经理或开发经理确认BUG(否)→将BUG置为(REJECT)
(是)
↓
将BUG置为(OPEN)
↓
程序远修复(FIXED) ←←↑
↓ ↑
测试人员验证-(否)→REOPEN
(是)
↓
VERIEY
↓
CLOSE 给一个自己正在使用的BUG管理工具：
缺陷状态流转
l 测试人员增加一个新的Defect记录到ClearQuest中，并指定提交给项目经理，此时Defect的状态为submitted.
l 项目经理
查询该Defect记录，通过assign动作分发，把Defect的状态改为assigned；
如果拒绝修改可以置为rejected；
如果需要延期修改把问题置为postponed状态。
l 开发人员
1. 开发人员应在第一时间查看自己的Defect，通过open动作确认该Defect，此时Defect的状态由assigned改为opened；如果不是属于自己的Defect或不做修改,则通过rejected动作将Defect的状态由assigned改为rejected,并把owner修改为项目经理，项目经理将该Defect通过reassign重新发往新的owner。
2. 开发人员如果认为需要延期修改，则通过rejected动作将Defect的状态由assigned改为rejected,并把owner修改为项目经理。由项目经理把问题置为postponed状态。
3. 开发人员在open该Defect后，应根据缺陷的严重程度以及解决的优先级，1类的致命错误和2类的严重错误和优先级为紧急的，应立即着手解决，并且不得将这类Defect带入下一次新版本的迭代，特殊情况的需报告项目经理；其他类的错误也应按优先级的要求逐一进行解决。
4. 开发人员修改程序，解决Defect后，同时在ClearQuest上通过modify把导致Defect的原因和解决方法记录下来,同时将Defect的状态由opened改为resolved。
l 测试人员
进行确认测试，若成功，把Defect 的状态改为closed，该条测试记录的生命周期完成；
若错误继续存在（或拒绝复审），则测试人员修改测试记录，通过reassign再次发布该Defect给相应的开发人员。重复第3步至第4步直到该Defect真正解决完毕。
若需要延期复审,则测试人员修改测试记录,问题状态不变. 进入公司注意根据情况进行剪裁 1、测试人员发现bug。
2、开发人员确认是否是bug，如果是开发人员修改bug;如果不是开发人员会把bug返回给测试人员。
3、开发人员修改完bug后，会提交给测试人员进行回归测试，如果测试通过，缺陷就会被关闭；如果没有通过，重新提交，直到验证通过后关闭bug。
这是我理解的bug生命周期，在这过程中，bug一般都有四种状态：待修订、待验证、关闭、注销。
页:
[1]
