BUG处理流程规范

BUG的生命周期

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

如果待验的BUG在验证时没有解决好，我们需要重新激活—>指派—>解决—>验证，循环这个过程。

BUG处理流程图

BUG状态

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

2. 已解决
   这类BUG通常是开发已找到具体原因并解决了指派给测试人员的，测试在验证之前需注意开发是否在BUG上说明原因以及解决方案，如未进行说明，则要求开发补充完整，并确认已更新到测试环境后再进行验证，验证通过则关闭BUG，若不通过则重新激活指派给开发。

3. 重复BUG
   这类BUG通常是开发认为与某个BUG重复，或是同一个原因，针对此类问题，研发人员在处理该BUG时，需注明重复的BUG ID或链接；

   测试人员确认是哪种情况：
   若是重复的，则判断是否真的重复，还是开发理解有误，若确认重复则关闭BUG，若不是重复则说明原因，重新激活指派给开发；
   若是同类型原因的，则需要等关联的那个BUG解决后进行验证，验证通过后关闭BUG，若不通过则重新激活指派给开发。

4. 不是BUG
   这类BUG通常是由测试人员操作错误或环境错误导致的问题，不是软件本身的BUG，开发在说明清楚原因后，测试确认确实不是BUG则关闭，若依然认为是缺陷，则说明原因并重新激活BUG指派给开发。

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

6. 不予解决
   这类BUG通常是小问题或实际场景中基本不会被触发的问题，对用户基本没有影响，需找产品经理进行确认，确认可以不修改则进行关闭，确认仍需解决则说明原因并重新激活指派给开发。

7. 设计如此
   这类BUG，开发在说明清楚原因后，测试同产品经理进行确认，确认设计如此进行关闭；确认是问题，说明原因并重新激活指派给开发。

8. 延期处理
   这类BUG通常是认为影响不大，即使不修改也不影响版本发布。测试人员与产品经理进行确认，不予延期请根据情况备注说明并重新激活指派给开发；确定延期则做好记录，后续版本进行关注。