Bug的生命周期状态流程图

发布时间 2023-12-25 19:22:13作者: Bear-Run

bug的生命周期

BUG的生命周期,就是一个BUG被发现到这个BUG被关闭的过程。

生命周期中缺陷状态:新建-->指派-->已解决-->待验-->关闭

发现BUG-->提交BUG-->指派BUG-->研发确认BUG-->研发去修复BUG-->回归验证BUG-->是否通过验证-->关闭BUG

如果待验的BUG在验证时没有解决好,我们需要重新打开--指派—已解决—待验,循环这个过程。

中间其他状态:拒绝、延期等

BUG的处理流程图(生命周期图)

 

 

状态处理

1.已经指派的BUG---已经指派给开发的,应随时关注并进行跟踪自己所提BUG的状态变化!如果一直未修复,提醒开发人员修改;如果已经修复等待测试环境更新后进行验证

2.已解决的BUG----等待测试环境更新后进行验证,验证通过则关闭;验证不通过则重新指派给开发

3.重复BUG----先去查看下是否跟开发指定的BUG或者,自己在BUG系统内看到的BUG重复?如果确定重复则关闭;如果不重复,说明原因,重新打开指派给开发。

4.不是缺陷----确认开发环境是否和测试环境一致,如果如开发所说不是缺陷则进行关闭;如果确认是缺陷跟开发沟通,沟通未达一致找产品/反馈老大确认,确认是BUG注明情况并再次指派给开发。

5.无法重现----确认开发环境是否跟测试环境一致?包括操作步骤,浏览器、环境、特定账号等,如果多个版本验证之后,如开发所说重现不了,依据BUG的严重程度跟产品,开发一起确认关闭;如果找到重现原因,注明清楚并再次指派给开发。

6.不予解决---找产品经理进行确认。确认不予解决进行关闭;确认需要解决请备注原因并打开指派给开发

7.设计如此---找产品经理进行确认。确认设计如此进行关闭;确认是问题,备注原因重现指派给开发。

8.延期修改---请看下BUG严重程度,是否影响当前版本发布?与产品经理进行确认。不予延期请根据情况重新打开并将情况进行备注说明;确定延期则做好记录,后续版本进行关注。

开发同学注意事项:

开发人员应在BUG系统中,备注好以下信息:

已修改BUG应在该BUG的注释处,备注修改方案及信息,以备以后出现类似的问题时,可以快速的找到原因

设计如此(不是缺陷)、不予解决、延期解决的BUG、无法重现的BUG,应备注处理的原因,节省沟通的时间,以及,如果后续有相同问题时,可以快速查找到原因

重复BUG注明重复BUGID