bug生命周期_Bug的生命周期状态流程图

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