51Testing软件测试论坛

 找回密码
 (注-册)加入51Testing

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

查看: 1515|回复: 7
打印 上一主题 下一主题

BUG的生命周期??

[复制链接]

该用户从未签到

跳转到指定楼层
1#
发表于 2007-8-4 16:38:36 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式
始于New,终于Closed,具体的步骤呢???
分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
收藏收藏
回复

使用道具 举报

该用户从未签到

2#
发表于 2007-8-4 18:43:35 | 只看该作者
我认为步骤是这样:
1.项目经理提交新版本
2.测试人员对新版本进行测试,找出bug,然后提交bug给测试经理
3.测试经理对提交上来的bug判断是否有重复的,如果重复则duplicate,若不重复则判断是否现在就修改,目前不修改则postpone,等到合适时机再提交修改
4.如果不重复则提交给开发经理,由开发经理分配bug给相关的开发人员进行修改
5.开发人员open bug,若确认bug不是错误无需修改则rejectd.
6.评审专家组对被拒绝的bug评审是否需要修改,评审通过确定不用修改则abandon.不通过则reopen
7.开发人员对bug进行修正fixed,然后提交给测试人员进行回归测试
8.回归测试通过则对bug  closed .
9.若回归不通过则再提交给开发人员重新修改reopen,直到回归通过最终closed.
回复 支持 反对

使用道具 举报

该用户从未签到

3#
发表于 2007-8-6 14:52:10 | 只看该作者
一般bug是不会close的除非重复了或者not a bug或者will not fix。

正常bug的生命周期的最后一步是verified.回归测试通过是verified而不是close。一般的tester也不应该具有close bug的权限。

close应该是leader的事情而且不同公司似乎有不同的做法,有的就是verified为最终结果。

[ 本帖最后由 baizhudan 于 2007-8-7 17:39 编辑 ]
回复 支持 反对

使用道具 举报

该用户从未签到

4#
发表于 2007-8-6 19:32:00 | 只看该作者
测试人员或者开发人员发现BUG
                 ↓
测试经理或开发经理确认BUG(否)→将BUG置为(REJECT)
                (是)
                 ↓
     将BUG置为(OPEN)
                 ↓
     程序远修复(FIXED)    ←←↑
                 ↓                     ↑
         测试人员验证-(否)→REOPEN
                (是)
                 ↓
              VERIEY
                 ↓
              CLOSE
回复 支持 反对

使用道具 举报

该用户从未签到

5#
发表于 2007-8-8 12:39:23 | 只看该作者
给一个自己正在使用的BUG管理工具:

本帖子中包含更多资源

您需要 登录 才可以下载或查看,没有帐号?(注-册)加入51Testing

x
回复 支持 反对

使用道具 举报

该用户从未签到

6#
发表于 2007-8-8 13:07:37 | 只看该作者
缺陷状态流转
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真正解决完毕。

若需要延期复审,则测试人员修改测试记录,问题状态不变.
回复 支持 反对

使用道具 举报

该用户从未签到

7#
发表于 2007-8-8 13:25:44 | 只看该作者
进入公司注意根据情况进行剪裁
回复 支持 反对

使用道具 举报

该用户从未签到

8#
发表于 2008-2-26 12:29:24 | 只看该作者
1、测试人员发现bug。
2、开发人员确认是否是bug,如果是开发人员修改bug;如果不是开发人员会把bug返回给测试人员。
3、开发人员修改完bug后,会提交给测试人员进行回归测试,如果测试通过,缺陷就会被关闭;如果没有通过,重新提交,直到验证通过后关闭bug。
这是我理解的bug生命周期,在这过程中,bug一般都有四种状态:待修订、待验证、关闭、注销。
回复 支持 反对

使用道具 举报

本版积分规则

关闭

站长推荐上一条 /1 下一条

小黑屋|手机版|Archiver|51Testing软件测试网 ( 沪ICP备05003035号 关于我们

GMT+8, 2024-11-17 12:25 , Processed in 0.069697 second(s), 24 queries .

Powered by Discuz! X3.2

© 2001-2024 Comsenz Inc.

快速回复 返回顶部 返回列表