缺陷生命周期管理：从发现到关闭的完整流程
缺陷生命周期，说白了就是一个 bug 从被发现到被彻底解决的全过程。我见过太多团队，bug 提了就不管了，或者修完就忘，结果同一个问题反复出现。嗯，这其实是个管理问题。
一个完整的缺陷生命周期，通常包含这几个阶段：
- 发现（New）：测试人员或用户发现了问题
- 确认（Confirmed）：开发或测试负责人确认这是个有效缺陷
- 分配（Assigned）：指派给对应的开发人员
- 修复（Fixed）：开发完成代码修改
- 验证（Verified）：测试人员验证修复是否有效
- 关闭（Closed）：确认无误，正式关闭
你想想看，如果中间任何一个环节断了，这个 bug 就可能变成「僵尸缺陷」—— 没人知道它到底修没修好。我在项目中遇到过，一个低优先级的 bug 在「已分配」状态躺了三个月，最后上线前才发现根本没改。
缺陷状态流转：别让 bug 卡在半路上
状态流转不是随便跳的。每个状态都有明确的进入条件和退出条件。我个人习惯用这张流转图来培训新同事：
New → Confirmed → Assigned → Fixed → Verified → Closed
↑ ↑ ↑ ↑ ↑
└────────┴───────────┴─────────┴─────────┘
可回退到任意前序状态为什么会需要回退？举个例子：开发说「修好了」，测试一验证发现根本没修好，那就得打回「Assigned」状态。我曾经见过一个团队，开发把 bug 状态改成「Fixed」就不管了，测试验证不通过也没人改状态，结果那个 bug 在「Fixed」状态挂了两个月。
我曾经犯过一个错误：允许开发人员直接从「New」跳到「Fixed」。结果呢？开发自己确认自己修好了，测试根本不知道有这个 bug。后来我强制要求：任何缺陷必须经过「Confirmed」和「Assigned」才能到「Fixed」。流程虽然多了一步，但堵住了漏洞。
常见的状态流转规则：
- New → Confirmed：必须有重现步骤和截图/日志
- Confirmed → Assigned：必须指定责任人，不能留空
- Assigned → Fixed：必须关联代码提交记录
- Fixed → Verified：必须由非修复者本人验证
- Verified → Closed：必须确认无副作用
我建议在状态流转中加入「Rejected」和「Deferred」两个特殊状态。Rejected 用于确认不是 bug 的情况，Deferred 用于确认是 bug 但当前版本不修的情况。这样能避免 bug 被「遗忘」在 New 状态里。
缺陷优先级与严重等级：别把小事当大事
很多团队把「优先级」和「严重等级」混为一谈。其实它们是两个维度：
- 严重等级（Severity）：这个 bug 对系统的影响程度
- 优先级（Priority）：这个 bug 需要多快被修复
说白了，严重等级是「客观的」，优先级是「主观的」。一个按钮颜色不对，严重等级可能是「低」，但如果这是客户 CEO 特别关注的页面，优先级可能就是「高」。
我常用的定义标准是这样的：
| 等级 | 严重等级定义 | 优先级定义 |
|---|---|---|
| P0/Critical | 系统崩溃、数据丢失、核心功能不可用 | 立即停止当前工作，24小时内必须修复 |
| P1/Major | 主要功能异常，但有临时替代方案 | 当前迭代内必须修复 |
| P2/Minor | 次要功能异常，不影响核心流程 | 下个迭代修复 |
| P3/Trivial | 界面错位、文案错误、轻微体验问题 | 有空再修，或累积到一定数量统一处理 |
你想想看，如果所有 bug 都标成 P0，那 P0 就失去了意义。我在项目中遇到过，有个团队把 80% 的 bug 都标成「高优先级」，结果真正紧急的 bug 反而被淹没了。后来我强制要求：P0 必须由项目经理和技术负责人共同确认。
严重等级由测试人员根据技术影响判定，优先级由项目经理根据业务影响判定。两者不能互相替代。
优先级与严重等级的矩阵决策
实际工作中，我习惯用这个矩阵来快速决策：
| Critical | Major | Minor | Trivial | |
|---|---|---|---|---|
| 高优先级 | 立即修复 | 当前迭代 | 下个迭代 | 累积处理 |
| 中优先级 | 当前迭代 | 下个迭代 | 下个迭代 | 累积处理 |
| 低优先级 | 下个迭代 | 下个迭代 | 累积处理 | 可忽略 |
举个例子：一个 Critical 严重等级但低优先级的 bug，比如某个冷门功能在极端条件下会崩溃，但几乎没人用。这种情况我会放到下个迭代修，而不是立刻停掉所有工作。
优先级不是一成不变的。我记得有一次，一个 P3 的界面错位 bug，因为客户要在展会上演示，一夜之间变成了 P0。所以，定期 review 优先级是必要的，我建议每周至少 review 一次。
从发现到关闭：一个完整的例子
让我用一个真实案例串一下整个流程：
- 发现：测试人员小张在测试支付功能时，发现点击「确认支付」后页面白屏，但钱已经扣了。
- 确认：测试组长老王复现了问题，确认是 bug，严重等级标为 Critical（数据不一致）。
- 分配：项目经理评估后，优先级标为 P0，指派给后端开发小李。
- 修复：小李定位到是支付回调接口超时导致，提交了修复代码。
- 验证：小张用同样的测试用例验证，确认白屏问题解决，且支付状态正确。
- 关闭：测试组长确认无副作用，关闭缺陷。
你看，每一步都有明确的责任人和产出物。如果中间任何一步卡住了，比如小李修完但小张没验证，这个 bug 就会卡在「Fixed」状态。我建议团队每周开一次缺陷评审会，专门处理那些「卡住」的 bug。
我习惯在缺陷关闭后，加一个「复盘」步骤。不是每个 bug 都要复盘，但 P0 和 P1 的 bug 一定要。问三个问题：为什么会出现？为什么没在测试阶段发现？怎么防止再出现？这样缺陷生命周期才算真正闭环。
嗯，缺陷生命周期管理，说白了就是让每个 bug 都有始有终。流程本身不复杂，难的是坚持执行。我见过太多团队，刚开始做得很好，三个月后就开始「灵活处理」了。记住：流程是保护你的，不是限制你的。