设计缺陷状态流程图，可以按“状态集合—流转规则—角色分工—示例验证—完成检查”的顺序推进：先固定每个状态的进入与退出条件，再把每条箭头写成带触发条件、操作角色和必填证据的规则，最后用一张真实缺陷走查闭环。本文给出可直接套用的状态定义表、流转规则表、角色职责表和示例图，适用于希望把口头约定变成可执行流程的测试与研发团队。
要点总览（TL;DR）
- 先定状态集合：最小可用为新建、已确认/待处理、处理中、待验证、已关闭，再按团队规模和缺陷量决定是否增加已拒绝、已延期、重新打开。
- 每条箭头写成一行规则：起点、终点、触发条件、操作角色、必填证据，正常流转、退回、拒绝与延期、重新打开四类路径分别定义。
- 角色分工要写清交接点：确认后责任转到修复开发，提交修复说明后责任转到验证人，并给每个状态设停留超时与升级责任人。
- 流程图定稿前用真实缺陷走查：选已关闭、被拒绝、被退回、重新打开各一条，核对是否有人负责、证据是否齐全、有无未定义路径。
- 流程运行一个迭代后结合缺陷状态分布复查，重点看停留最长的状态，据此调整超时阈值或精简状态。
先定状态集合：缺陷从发现到关闭要经过哪些状态
状态集合是流程图的骨架。建议先落一张状态定义表，每个状态写清四列：状态名、含义、进入条件、责任角色。进入条件决定“什么情况下可以进入这个状态”，它比状态名称更能约束实际操作。
最小可用集合包含五个状态：新建、已确认/待处理、处理中、待验证、已关闭。多数团队在此基础上按需增加已拒绝、已延期、重新打开三个扩展状态。下表给出可直接改用的模板。
| 状态名 | 含义 | 进入条件 | 责任角色 |
|---|---|---|---|
| 新建 | 缺陷已被提交，尚未被确认 | 提交人填写标题、复现步骤、环境、严重程度和期望结果 | 提交人（测试或用户） |
| 已确认/待处理 | 缺陷真实存在，等待排期修复 | 开发负责人或缺陷管理负责人确认可复现，并给出优先级 | 开发负责人 |
| 处理中 | 已分配责任人，正在定位或修复 | 缺陷已指派给具体开发人员，且进入当前迭代或修复计划 | 修复开发 |
| 待验证 | 修复完成，等待验证 | 开发提交修复说明，注明改动范围、影响模块和自测结果 | 验证人（通常为提交人） |
| 已关闭 | 验证通过，流程结束 | 验证人按原复现步骤验证通过，并填写验证结论与验证版本 | 验证人 |
| 已拒绝（可选） | 判定为非缺陷、重复或无法复现 | 给出拒绝理由和判定依据，重复缺陷需关联原缺陷编号 | 开发负责人或缺陷管理负责人 |
| 已延期（可选） | 确认存在但本版本不修复 | 说明延期原因、计划修复版本，并经项目负责人确认 | 项目负责人 |
| 重新打开（可选） | 已关闭缺陷再次出现或验证不通过 | 提供新的复现证据或回归失败记录，关联原缺陷 | 验证人或提交人 |
状态数量要与团队规模和缺陷量匹配。缺陷量小、角色重合的团队，五个状态足够；缺陷量大、多人协作、需要对外交付的团队，再引入已拒绝、已延期、重新打开。状态过多的典型后果是缺陷停在中间状态无人推进，因此每增加一个状态，都要同时回答“谁负责推动它离开这个状态”。
画流转规则：每条箭头写清触发条件、操作角色和必填证据
流程图上的箭头如果只写“确认”“修复”，执行时仍会靠口头沟通。可执行的做法是把每条箭头展开成一行规则：起点状态、终点状态、触发条件、操作角色、必填证据。正常流转、退回、拒绝与延期、重新打开四类路径分别定义。
正常流转路径是主干：新建→已确认/待处理→处理中→待验证→已关闭。触发条件分别是确认可复现、完成指派并进入修复计划、提交修复说明、验证通过。退回路径发生在待验证环节：验证不通过时回到处理中，验证人必须补充失败现象、失败环境和复现步骤，避免开发反复猜测。拒绝与延期路径从已确认/待处理或处理中分出，判定依据要写具体，例如“与已有关联缺陷重复”“设计规格明确如此”“本版本范围外且已排入后续版本”，并注明审批角色。重新打开路径从已关闭回到已确认/待处理或处理中，需约定时限，例如关闭后一个发布周期内可重新打开，超出时限按新缺陷提交并关联原编号。
| 起点状态 | 终点状态 | 触发条件 | 操作角色 | 必填证据 |
|---|---|---|---|---|
| 新建 | 已确认/待处理 | 确认缺陷可复现且属于缺陷范畴 | 开发负责人 | 确认结论、优先级、目标版本 |
| 新建 | 已拒绝 | 非缺陷、重复或信息不足无法复现 | 开发负责人 | 拒绝理由、关联缺陷编号（重复时） |
| 已确认/待处理 | 处理中 | 已指派责任人并纳入修复计划 | 开发负责人 | 指派人、计划修复版本 |
| 已确认/待处理 | 已延期 | 确认存在但本版本不修复 | 项目负责人 | 延期原因、计划修复版本 |
| 处理中 | 待验证 | 修复完成并自测通过 | 修复开发 | 修复说明、改动范围、自测结果 |
| 待验证 | 已关闭 | 按原步骤验证通过 | 验证人 | 验证结论、验证版本 |
| 待验证 | 处理中 | 验证不通过 | 验证人 | 失败现象、失败环境、复现步骤 |
| 已关闭 | 已确认/待处理 | 关闭后约定时限内再次出现 | 验证人或提交人 | 新复现证据、原缺陷编号 |
必填证据是流转规则里最容易被省略、也最影响协作效率的部分。复现步骤、修复说明、验证结论这三类字段分别对应提交、修复、验证三个动作，缺一项就会让下一环节重新沟通。规则表定稿后，流程图上的每条箭头都应能在表中找到对应行，反之亦然。
角色与交付物分工：谁在哪个状态做什么、交出什么
状态卡住通常不是规则缺失，而是某个环节没有明确责任人。角色分工表要回答三个问题：谁在哪个状态动作、动作产出什么、停留超时由谁提醒和升级。
| 角色 | 负责状态 | 主要动作 | 交付物 |
|---|---|---|---|
| 提交人（测试或用户） | 新建、待验证 | 提交缺陷、补充复现信息、执行验证 | 缺陷记录、验证结论 |
| 开发负责人 | 新建、已确认/待处理 | 确认可复现性、判定优先级、指派修复人 | 确认结论、优先级、指派人 |
| 修复开发 | 处理中 | 定位原因、修复、自测 | 修复说明、改动范围、自测结果 |
| 验证人 | 待验证 | 按原步骤回归验证，判定通过或退回 | 验证结论、失败证据 |
| 缺陷管理/项目负责人 | 全流程 | 维护状态规则、处理拒绝与延期审批、跟踪停留超时 | 规则变更记录、审批结论、超时清单 |
职责边界要写清交接点：开发负责人确认后，缺陷的推进责任转移到修复开发；提交修复说明后，责任转移到验证人。停留超时建议按状态分别设定，例如新建超过一个工作日未确认、待验证超过两个工作日未验证，由缺陷管理负责人汇总提醒，连续超时则升级到项目负责人。超时阈值应结合团队节奏设定，并在流程上线后按实际数据调整。
流程规则确定后，需要落到团队日常使用的工作项上。ONES Project 支持缺陷跟踪管理，并可与 TestCase 数据互通、一键提 Bug，缺陷记录能直接进入对应项目或迭代；其多层级权限可按组织架构、用户组和项目角色分配，便于把确认、修复、验证等动作对应到不同角色。缺陷状态分布也可用于统计，帮助团队发现长期堆积的状态环节。具体状态与流转配置方式以实际产品版本为准。
示例：一张中等复杂度团队的缺陷状态流程图
假设一个二十人左右的研发团队，包含测试、开发和一名兼职缺陷管理负责人，每个迭代产生约一百五十条缺陷，需要对外交付版本。该团队采用八个状态：新建、已确认/待处理、处理中、待验证、已关闭、已拒绝、已延期、重新打开。
主干路径为：测试提交缺陷进入新建；开发负责人在一个工作日内确认，可复现的进入已确认/待处理并给出优先级，不可复现或重复的进入已拒绝并写明理由；已确认缺陷在迭代排期时指派修复人，进入处理中；修复完成提交修复说明后进入待验证；验证人按原步骤回归，通过则关闭，不通过则退回处理中并附失败证据。
关键分支的处理方式是：已拒绝缺陷若提交人补充了新证据，可经缺陷管理负责人复核后重新进入已确认/待处理；已确认缺陷若判定本版本不修复，由项目负责人审批后进入已延期，并记录计划修复版本；已关闭缺陷在一个发布周期内再次出现，验证人可直接重新打开并关联原编号，超出时限则新建缺陷并关联原记录。
这张图与配套表格一一对应：八个状态对应状态定义表的八行；主干与分支共约十条箭头对应流转规则表的十行；每个状态的责任角色对应角色分工表。画图时建议在箭头上标注规则编号，评审时逐条核对，避免图与表脱节。
完成检查：流程图能否直接执行
流程图定稿前，用下面这份清单逐项核对。全部通过，才具备直接执行的条件。
- 状态覆盖完整：从提交到关闭的全部实际处置路径都有对应状态，图中没有无法到达的孤立状态，也没有只能进不能出的状态。
- 每条流转有主：每条箭头都写明操作角色，不存在“谁都可以改”的流转。
- 证据字段齐全：提交、修复、验证三个动作分别有必填字段，退回和重新打开有补充证据要求。
- 异常路径已定义：退回、拒绝、延期、重新打开四类路径都有判定依据、审批角色和时限约定。
- 图表一致：流程图上的每个状态和箭头都能在状态定义表、流转规则表中找到对应行，三份材料没有互相矛盾。
- 超时责任明确：每个状态有停留时长参考值和提醒、升级责任人。
上线验证的方法是拿真实缺陷走查：选取近期已关闭、被拒绝、被退回和重新打开的各一条缺陷，按新流程图逐步核对，记录每一步是否有人负责、证据是否齐全、是否出现图中未定义的路径。走查中发现的问题直接回改规则表，再同步更新流程图。流程运行一个迭代后，可结合缺陷状态分布数据复查，重点看哪个状态停留时间最长，据此调整超时阈值或精简状态。
常见问题
团队规模小、缺陷量不大，状态可以精简到几个？
五个状态通常够用：新建、已确认/待处理、处理中、待验证、已关闭。角色重合的小团队可以把“已确认”和“待处理”合并，由同一个人完成确认与指派。精简的前提是每个状态仍写清进入条件和责任角色，退回路径保留在待验证与处理中之间。等缺陷量上升、多人协作或需要对外交付时，再引入已拒绝、已延期、重新打开。
缺陷被拒绝后提交人不认可，流程上怎么处理？
建议在规则表里预留一条复核路径：提交人补充新证据后，由缺陷管理负责人或项目负责人复核，复核通过则从已拒绝回到已确认/待处理，复核不通过则维持拒绝并记录理由。复核环节要约定时限，避免争议长期悬置。重复缺陷的拒绝必须关联原缺陷编号，方便提交人自行核对。
重新打开要不要设时限？超时怎么办？
建议设时限，例如关闭后一个发布周期内可直接重新打开并关联原编号；超出时限按新缺陷提交，同时在描述中关联原记录。时限的作用是让回归验证有明确窗口，也让历史缺陷数据保持可统计。时限长短结合发布节奏确定，并在流程上线后按实际回归情况调整。
流程图设计好后，怎么落到团队日常使用的工具里？
把状态定义表对应到工作项状态，把流转规则对应到操作权限和必填字段，把角色分工对应到项目角色权限。ONES Project 支持缺陷跟踪管理，并可与 TestCase 数据互通、一键提 Bug，缺陷记录能直接进入对应项目或迭代；多层级权限可按组织架构、用户组和项目角色分配，便于把确认、修复、验证动作对应到不同角色。缺陷状态分布也可用于统计，帮助发现长期堆积的环节。具体状态与流转配置方式以实际产品版本为准。
流程上线后，怎么判断它是否真的在起作用？
看两个信号：一是缺陷状态分布，哪个状态停留时间最长，往往就是流程瓶颈；二是走查记录，上线初期用真实缺陷逐条核对，统计出现未定义路径或证据缺失的次数。若某个状态长期堆积，先检查该状态是否有明确责任人和超时提醒，再考虑是否状态划分过细。调整后同步更新状态定义表、流转规则表和流程图，保持三份材料一致。
