缺陷生命周期管理的核心，是把缺陷从发现到关闭的每个状态、每次流转条件和每个角色的责任固定下来。先定义状态与准入准出规则，再明确提交、分派、修复、验证、关闭各环节的负责人和交付物，最后用检查项确认流程可执行、可追溯。本文围绕状态流转表、角色职责清单、分步实施清单和完成检查表展开，适合正在建立或重构缺陷流程的研发团队对照使用。
要点总览（TL;DR）
- 缺陷生命周期管理的最小状态集合是新建、已确认、处理中、待验证、已关闭，再配驳回、重复、暂缓三个分支状态；每个状态都要写明准入条件、准出条件和允许的下游状态。
- 状态流转要落到五类角色：提交人、分派/协调人、开发修复人、测试验证人、关闭决策人；每个状态必须有唯一推进责任人，跨角色交接设置必填信息。
- 建立流程可按五步推进：梳理现状路径、确定状态机并评审、配置必填字段与流转校验、试点收集卡点、固化规则纳入日常管理，每步都有输入、输出和完成标志。
- 流程上线前用检查表核对状态覆盖度、角色职责完整性、流转校验有效性、历史缺陷处理口径和统计复盘机制，未通过项先处理再上线。
缺陷生命周期包含哪些状态与流转规则
状态集合宜少不宜多。最小可用集合是新建、已确认、处理中、待验证、已关闭五个主状态，再配驳回、重复、暂缓三个分支状态。主状态描述缺陷当前处在处置链的哪一段，分支状态描述它暂时离开主链的原因。状态过多会让流转记录难以阅读，状态过少则无法区分责任交接点，团队可以先按这套最小集合运行，遇到真实分支再增补。
每个状态都需要写明准入条件和准出条件。准入条件回答“什么情况下可以进入这个状态”，准出条件回答“满足什么才能离开”。两者共同构成流转校验的依据，也是后续配置必填字段和流转限制的基础。
| 状态 | 准入条件 | 准出条件 | 允许的下游状态 |
|---|---|---|---|
| 新建 | 提交人填写标题、复现步骤、环境、影响范围、严重程度 | 分派/协调人完成有效性判断 | 已确认、驳回、重复、暂缓 |
| 已确认 | 缺陷可复现或影响已被证据支持，严重程度与优先级已核定 | 指定修复责任人并给出计划处理时间 | 处理中、暂缓 |
| 处理中 | 修复责任人已接单，定位或修复动作已开始 | 提交修复说明，包含原因分析、改动范围、自测结果 | 待验证、暂缓 |
| 待验证 | 修复说明完整，修复版本或环境可获取 | 测试验证人给出验证结论 | 已关闭、处理中 |
| 已关闭 | 验证通过，关闭检查项全部满足 | —（如需重开，走新建关联或重开规则） | — |
| 驳回 | 判定为描述不清、非缺陷或不属于本产品范围 | 提交人确认驳回理由或补充信息后重新提交 | 新建（重新提交） |
| 重复 | 与已有缺陷指向同一问题，已关联主缺陷编号 | 主缺陷关闭后同步归档 | 已关闭 |
| 暂缓 | 确认有效但当前版本不处理，已记录暂缓原因与复审时间 | 复审时间到达或版本计划变更 | 已确认、处理中 |
允许的流转路径要显式列出，禁止的跳转同样要写清楚。最常见的禁止项是从处理中直接跳到已关闭，跳过待验证；以及从新建直接进入处理中，绕过确认环节。这两类跳转会让修复结果缺少独立验证，也让缺陷有效性判断失去责任人。另一类需要约束的是从待验证退回新建，回退应回到处理中并保留原有修复记录，避免历史信息丢失。
状态与严重程度、优先级是三件不同的事。状态表示处置进度，严重程度表示缺陷对系统的影响，优先级表示团队打算多快处理它。严重程度高的缺陷优先级通常也高，但两者不必绑定：一个影响面大但已有规避手段的缺陷可以定为高严重、中优先级；一个界面文案错误可以是低严重、高优先级。把三者混在一个字段里，会导致状态流转无法反映真实进度，也无法据此统计各环节停留时间。
各角色在缺陷流转中负责什么、交付什么
状态流转只有落到具体角色和交付物上才可执行。建议至少区分五类角色：提交人、分派/协调人、开发修复人、测试验证人、关闭决策人。小团队可以一人兼多角，但每个状态下“谁负责推进”必须唯一，避免出现缺陷停在某个状态无人处理。
| 角色 | 输入 | 动作 | 输出物 |
|---|---|---|---|
| 提交人 | 使用中发现的问题、日志、截图 | 按模板提交缺陷，补充复现步骤与环境；对驳回结论作出回应 | 信息完整的缺陷记录 |
| 分派/协调人 | 新建状态的缺陷 | 判断有效性，核定严重程度与优先级，指定修复责任人 | 确认结论、分派记录、处理时限 |
| 开发修复人 | 已确认并分派的缺陷 | 定位原因、实施修复、自测，填写修复说明 | 修复说明（原因、改动范围、自测结果、影响版本） |
| 测试验证人 | 待验证状态的缺陷及修复说明 | 在约定环境复现原问题，执行回归验证 | 验证结论、验证环境与版本记录 |
| 关闭决策人 | 验证通过的缺陷 | 核对关闭检查项，确认无遗留关联问题 | 关闭依据与关闭时间 |
跨角色交接是流程最容易断的地方，因此要在流转时设置必填信息。提交到确认环节，必填复现步骤、环境、影响范围；确认到处理环节，必填修复责任人与计划处理时间；处理到验证环节，必填修复说明与修复版本；验证到关闭环节，必填验证结论与验证环境。这些字段既是交接凭证，也是后续复盘的数据来源。
争议缺陷需要预设裁决角色。无法复现的缺陷，由测试验证人与提交人共同确认，仍无法复现时由分派/协调人决定转为暂缓并记录复审时间；需求理解分歧，由产品负责人或需求责任人给出结论并写入缺陷记录；修复方案争议，由技术负责人裁决。裁决角色要写进流程文档，避免争议时临时找人。
当缺陷数量增多、跨版本并行时，状态与责任分派需要由工作项系统承载。ONES 支持在工作项中配置状态流转、必填字段与责任人字段，缺陷从提交到关闭的每次流转都留有记录，分派与验证结论可以随工作项一并追溯，便于团队按状态统计停留时间和积压情况。
按步骤建立缺陷生命周期流程
从零搭建或重构流程，可以按五步推进。每步都应有明确输入、动作、输出和完成标志，并指定负责人，避免流程设计停留在讨论阶段。
第一步：梳理现有缺陷来源与处置路径
输入是当前团队实际使用的缺陷记录渠道，包括测试用例执行、线上问题反馈、用户工单、代码评审发现等。动作是抽样近期缺陷，还原它们从被发现到关闭实际走了哪些环节、在哪些环节停留最久、哪些环节经常缺失记录。输出是一份现状路径说明和问题清单。完成标志是团队对“当前缺陷从哪里来、卡在哪里”形成一致认识。负责人建议为测试负责人或质量负责人。
第二步：确定状态机与流转规则并评审
输入是第一步的现状路径说明。动作是确定状态集合、每个状态的准入准出条件、允许与禁止的流转路径，形成状态流转表。输出是评审通过的状态流转表。完成标志是开发、测试、产品三方对状态定义和跳转限制无异议。负责人建议为质量负责人，评审参与方包括开发与产品代表。
第三步：配置必填字段与流转校验
输入是状态流转表和角色职责清单。动作是把每个流转环节的必填字段、责任人字段、流转限制落到实际使用的管理工具中，并验证配置是否按预期拦截不合规流转。输出是可运行的流程配置与字段说明。完成标志是模拟提交一条缺陷，能够走通全部状态且缺字段时被正确拦截。负责人建议为工具管理员或研发效能负责人。
第四步：试点运行并收集卡点
输入是已配置好的流程。动作是选择一个项目或一个版本周期试点，记录每次流转被拦截的原因、角色交接遗漏的情况、状态定义不清引发的争议。输出是试点问题清单与调整建议。完成标志是试点周期结束，主要卡点已有处理结论。负责人建议为试点项目负责人。
第五步：固化规则并纳入日常管理
输入是试点问题清单与调整后的规则。动作是发布流程文档，把状态流转表、角色职责清单、关闭检查标准纳入团队规范，并在版本例会上按状态统计缺陷积压与停留时间。输出是正式发布的流程文档与例行统计口径。完成标志是流程文档发布，且连续一个版本周期按新规则运行。负责人建议为质量负责人。
示例：一个缺陷从提交到关闭的完整流转
以下为演示情景，用于说明规则如何被执行，不代表真实项目数据。
某版本测试中，测试人员发现“订单导出在超过一万条记录时超时”。提交人按模板提交缺陷：标题写明现象，复现步骤列出数据量与操作路径，环境填写测试环境版本号，影响范围标注为订单导出功能，严重程度定为高。此时状态为新建，交付物是信息完整的缺陷记录。
分派/协调人当天确认该问题可复现，核定优先级为高，指定后端开发为修复责任人，状态流转为已确认，交付物是确认结论与分派记录。开发接单后状态进入处理中，定位为分页查询未加索引，完成修复并自测，填写修复说明：原因分析、改动范围、自测结果、修复版本，状态流转为待验证。
测试验证人在约定环境按原复现步骤验证，发现大数据量下仍偶发超时，验证不通过，状态退回处理中，并附上新的复现记录。开发补充优化后再次提交修复说明，状态回到待验证。这次验证通过，测试验证人记录验证环境与版本，状态进入待关闭检查。
关闭决策人核对关闭检查项：原问题已复现且验证通过、修复说明完整、关联的重复缺陷已合并、回归范围已覆盖。全部满足后状态置为已关闭，记录关闭依据与关闭时间。整条链路中，每次状态变化都对应一个角色动作和一份交付物，事后可按状态统计各环节耗时。
流程上线前的完成检查
流程是否达到可运行状态，可以用一张检查表逐项核对。每项都应有明确的通过标准和负责人，未通过项需在正式上线前处理完毕。
| 检查项 | 通过标准 | 负责人 |
|---|---|---|
| 状态与流转规则覆盖度 | 主状态与分支状态齐全，驳回、重复、暂缓均有定义；允许与禁止的跳转已列明 | 质量负责人 |
| 角色职责完整性 | 每个状态都有唯一推进责任人；交接必填信息已定义；争议裁决角色已指定 | 质量负责人与项目负责人 |
| 必填字段与流转校验 | 模拟提交可走通全流程；缺必填信息时被正确拦截；禁止跳转无法执行 | 工具管理员 |
| 历史缺陷处理口径 | 存量缺陷的迁移范围、归档规则、状态映射方式已明确并完成处理 | 各项目负责人 |
| 统计与复盘机制 | 可按状态统计缺陷数量与停留时间；已约定复盘周期与规则调整触发条件 | 质量负责人 |
历史缺陷的处理口径容易被忽略。建议明确哪些存量缺陷迁入新流程、哪些按原状态归档只读、旧状态如何映射到新状态，避免新旧规则并行造成统计口径混乱。流程上线后，按版本或按月复盘一次，重点看状态停留时间异常、频繁回退和驳回率偏高的环节，据此调整流转规则或角色分工，让流程随团队实际运行情况持续修正。
常见问题
小团队人手有限，五类角色必须分开设置吗？
不必。小团队可以一人兼多角，例如测试人员同时承担提交人和测试验证人，技术负责人同时承担分派/协调人和关闭决策人。需要守住的条件是：在任意一个状态下，负责推进的人必须唯一且明确写进流程文档。兼角时建议在缺陷记录中保留角色字段，记录每次流转由谁以什么角色完成，这样后续统计停留时间和复盘责任时仍有依据。团队规模扩大后再逐步拆分角色。
缺陷被驳回后，提交人补充信息重新提交，应该算新缺陷还是原缺陷？
取决于驳回原因。如果是描述不清、信息缺失，建议在原缺陷上补充信息后重新流转回新建或已确认，保留完整讨论历史；如果是判定为非缺陷或不属于本产品范围，提交人补充证据后认为判断有误，可以重新提交并关联原缺陷编号，便于追溯争议过程。无论哪种方式，都要在流程文档中写明规则，避免同一问题在系统里出现多条互不关联的记录，影响后续统计。
存量缺陷很多，迁移到新流程时怎么处理比较稳妥？
先划定迁移范围：仍在处理中的缺陷建议迁入新流程，并按新状态映射继续流转；已关闭的历史缺陷按原状态归档只读，不再参与新流程统计。旧状态到新状态的映射关系要写成对照表，例如旧的“已解决”映射为“待验证”。迁移前抽样验证映射结果，确认状态和责任人没有丢失。新旧规则并行期间，统计口径要注明数据来源，避免积压数量出现两套数字。
流程运行一段时间后，什么情况下需要调整状态或流转规则？
出现以下信号时值得复盘：某个状态停留时间明显偏长、回退到处理中的比例持续偏高、驳回率异常、频繁出现绕过确认直接处理的跳转。复盘时先看数据再改规则，区分是规则设计问题还是执行问题。调整规则要经过与初次评审相同的参与方确认，并同步更新流程文档和工具配置，避免文档与实际流转不一致。调整频率不宜过高，建议按版本或按月集中评估一次。
缺陷状态和严重程度、优先级应该怎么区分使用？
三者描述不同维度：状态表示缺陷当前处在处置链的哪一段，严重程度表示对系统的影响大小，优先级表示团队打算多快处理。严重程度高的缺陷优先级通常也高，但两者可以分开判断，例如影响面大但已有规避手段的缺陷可定为高严重、中优先级。把三者合并成一个字段，会导致状态无法反映真实进度，也无法按状态统计各环节停留时间。建议在缺陷模板中分别设置这三个字段，并在确认环节由分派/协调人核定。
