缺陷生命周期是什么
缺陷从被发现到关闭的全过程：报告、确认分派、处理中、修复、待复测、验证、关闭，验证不通过则重开。每个状态都有责任人与准入、出口条件；流程透明后，跨团队的统计口径才能一致。统计各状态的停留时长，还能定位修复与验证环节的瓶颈。
基本信息
| 典型状态 | New / Assigned / Open / Fixed / Ready for Test / Verified / Closed / Reopened |
|---|---|
| 关键角色 | 报告人、分派人（Triage）、开发、验证人 |
| 核心指标 | 平均修复时长、重开率、各状态滞留分布 |
| 分级入口 | 严重度定影响面，优先级定修复顺序，均在分派时确定 |
| 工具落点 | Jira、禅道、GitLab Issues 等按此工作流配置状态与必填字段 |
| 常见分支 | 重开（Reopened）、延期（Deferred）、无法复现（Cannot Reproduce）、重复（Duplicate）、不是问题（Not a Bug） |
流转示意
流转示意
New -> Assigned -> Open -> Fixed -> Ready for Test
-> Verified -> Closed
-> Reopened ->（回到 Assigned 或 Open）
部分团队另设 Deferred（延期）/ Cannot Reproduce（无法复现）分支典型使用场景
- 新人上手：按状态图理解缺陷从报告到关闭的责任流转。
- 跨团队协作：测试与开发对「已修复、待复测」口径一致，交接不扯皮。
- 度量改进：统计各状态的停留时长，找出验证排队等瓶颈。
- 工具配置：在缺陷系统中配置工作流、必填字段与超时提醒。
- 复盘依据：高重开率或长期滞留的状态，反查修复质量与流程问题。
- 质量度量：按周看新增、关闭、重开、滞留四条线，判断迭代健康度。
阶段责任与出口条件
| 阶段 | 责任人 | 出口条件 |
|---|---|---|
| 确认与分派 | 测试或 Triage | 可复现、信息完整，定级后指派 |
| 处理中 | 开发 | 提交修复并写明修改点与影响范围 |
| 待复测 | 测试 | 按原步骤验证并回归相关功能 |
| 验证不通过 | 测试 | 重开并补充新证据 |
| 关闭 | 测试 | 验证通过且有回归结论 |
每个状态都要有责任人与准入条件，写进团队工作协议，而不是靠口头约定。
重开率是流程健康度指标：持续偏高，通常说明修复质量或验收标准有问题。
流程别一次上太全：先跑通 New 到 Closed 的最小闭环，再按需增加延期、无法复现等分支；状态过多没人维护，反而会失效。
跨团队只认两样东西：可复现的证据、明确的下一步责任人。