Bug 生命周期管理算是很基础的知识了，本来是没什么值得再提的，但是我从业了三家公司，所用的管理系统中，我感觉都没有完美反映最全面的 Bug 生命周期，每一个系统都或多或少地缺少一部分。因此，在这里想探讨一下我理想中的最全面的 Bug 生命周期管理过程。当然，有很多我还没有使用过的系统，可能它们已经很全面了。另外，可能还有遗漏的部分，欢迎大家一起探讨。

先上图：

根据上图，整个处理流程如下：

1. 发现人发现 Bug 之后，在系统中录入 Bug 单，还未保存的时候，这个时候 Bug 就处于新建状态。如果指定了修复人并保存，那么 Bug 状态就变成了待修复。如果没有指定修复人保存，那么 Bug 状态就变成了计划。当然，计划状态和新建状态也可以合并。这个时候，如果指定了修复人并保存，那么 Bug 状态同样会变成了待修复。如果没有指定修复人保存，那么 Bug 状态就变成了新建。本帖采用的是前一种方式。

2. 当 Bug 处于计划状态，可以指派修复人，然后就变成了待修复状态。如果是撤回或者打回之后变成计划状态，有两种情况：

   a. 确认之后直接关闭 Bug。
   b. 不认可打回，可以重新指派。
   c. 撤回之后，修改相关内容后重新指派。

3. 当 Bug 处于待修复状态，就有比较多的情况了：

   a. 如果发现人发现自己提错了或者描述有错，可以撤回，状态变成计划。
   b. 如果修复人觉得不是 Bug，可以打回，状态变成计划。
   c. 如果修复人觉得是需求，可以先转交给产品经理，这个时候状态还是待修复。产品经理评估后确认是需求，则可以转成需求。状态变成已转需求，如果产品经理觉得不是需求，是 Bug，也可以转回给原来的修复人。当然，如果产品经理觉得不是 Bug，也可以直接打回，状态变成计划。
   d. 修复人可以 Bug 状态改成修复中，表示自己正在修复。处在修复中状态的 Bug，除了可以重新变成待修复状态之外，可流转的状态跟待修复状态的 Bug 相同。
   e. 修复人可以在修复 Bug 之后，可以标修复完成。
   f. 如果修复人觉得 Bug 无法处理或者没必要处理，则可以标成不处理。
   g. 如果修复人觉得影响不大，没时间处理，可以标成下版处理。

4. 当 Bug 处于修复完成状态，发现人如果验证 OK，可以标成关闭。如果验证不通过，则打回给修复人，状态变成待修复。

5. 当 Bug 分别处在下版处理和不处理状态时，可以分别标成确认下版处理和确认不处理或者打回。值得注意的是，这一步最好是由充当项目经理的角色来标。

6. 当 Bug 分别处在确认下版处理和确认不处理状态时，处理人应该是发现人，这样可以形成闭环，避免发现人丢失对 Bug 的跟踪。这个时候，修复人可以选择重新打开或者关闭Bug。当重新打开时，Bug 状态变成待修复。多数情况下，确认下版处理的 Bug 预计下版是要重新打开的，重新打开后，Bug 的账龄需要重新重置。而确认不处理的 Bug 除非发现人不认同需要重新打开，否则可以直接关闭。

7. 关闭状态和已转需求状态是最终状态，当 Bug 处于这两个状态时，就无法修改了，也没有处理人。

8. 每一次标状态，都是可以写备注的。建议除了指派、重新打开、待修复变成修复中、确认不处理/确认下版处理变成关闭之外，其他情况都是需要备注原因的。

9. 为了保持灵活性，除了最终状态，其他状态要有 “转交” 功能，可以转交处理人。

10. 状态转换时，部分情况下处理人是不固定的，需要手动指定处理人。系统可以配置每次状态转换之后的默认处理人。一般以下情况需要配置：

    a. 修复中打回或者待修复撤回/打回之后，处理人都是发现人。
    b. 待修复和修复中之间转换，处理人不变。
    c. 修复完成/不处理/下版处理打回、确认不处理/确认下版处理之后重新打开，处理人都是待修复时的处理人。
    d. 待修复/修复中变成修复完成，处理人是发现人。

11. 每一个状态转换，多数情况下只有处理人才能改状态。但是也可以配置权限。比如待修复状态，项目经理也可以标不处理，计划状态，项目经理也可以指派修复人等等。权限项就不展开讲了。

12. 偶现或者无法重现问题可以备注后标成不处理。项目经理确认不处理后，无法重现问题需要发现人持续观察一个月，定期抽查验证，确定无法重现后才能关闭。偶现问题需要发现人观察一周，定期抽查验证，确定无法重现后关闭。

13. 重复 Bug 可以直接打回。