缺陷状态流程图模板由两张表组成：状态表定义每个状态的名称、类型、责任角色和进出条件，流转表定义每条流转的起点、触发动作、目标状态、必填字段和确认人。两张表填完，流程图就有了可复制的骨架，团队再按自身的评审与验证规则调整。下面提供可直接复制的空白表、字段口径、必填规则、一条完整填写示例，以及后续维护方法。
要点总览（TL;DR）
- 模板由状态表和流转表两张表组成：状态表定义状态名称、类型、责任角色和进出条件，流转表定义起点、触发动作、目标状态、必填字段和确认人。
- 状态表除备注外均为必填；流转表的必填字段和审批或确认人两列允许填“无”或“无需确认”，但不允许留空，以便区分漏填与确认无需。
- 填写示例用一条缺陷走完提交、受理、修复、验证不通过、再次修复、验证通过、关闭和重开路径，示范两张表如何逐行对应。
- 维护时按积压、角色分工和统计需要判断状态增删，流转变更需评审并同步更新流程图与工具配置，模板保留版本记录并定期复核。
可复制空白模板：状态表与流转表
模板的交付物是两张空白表。状态表回答“缺陷可能处于哪些状态、由谁负责、什么条件下进入和离开”；流转表回答“谁在什么动作下把缺陷从哪个状态推到哪个状态、需要补齐哪些信息、由谁确认”。两张表配合使用，流程图中的每个节点和箭头都能在表中找到对应行。
表一：缺陷状态定义空白表
将下表复制到文档或表格工具中，每个状态占一行。建议先列出团队实际使用的全部状态，再逐行补齐字段。
| 状态编号 | 状态名称 | 状态类型 | 责任角色 | 进入条件 | 退出条件 | 备注 |
|---|---|---|---|---|---|---|
| ST-01 | ||||||
| ST-02 | ||||||
| ST-03 | ||||||
| ST-04 | ||||||
| ST-05 | ||||||
| ST-06 |
表二：缺陷状态流转空白表
每条流转占一行，起点状态与目标状态须引用状态表中已定义的状态名称。流转编号建议按“FL-序号”编排，便于在评审和系统配置时引用。
| 流转编号 | 起点状态 | 触发动作 | 目标状态 | 必填字段 | 审批或确认人 | 备注 |
|---|---|---|---|---|---|---|
| FL-01 | ||||||
| FL-02 | ||||||
| FL-03 | ||||||
| FL-04 | ||||||
| FL-05 | ||||||
| FL-06 | ||||||
| FL-07 | ||||||
| FL-08 |
行数按实际需要增减。状态表与流转表填完后，把流转表按起点状态分组，即可画出状态流转示意图；图中每个箭头对应流转表中的一行，每个节点对应状态表中的一行。
字段说明：每个字段记录什么
两张表的字段承担不同职责：状态表描述“静态节点”，流转表描述“动态路径”。填写时保持同一字段在不同表中的口径一致，例如责任角色在状态表中写的是“当前状态下由谁处理”，在流转表中审批或确认人写的是“谁批准这次状态变化”，两者可以相同，也可以不同。
状态表字段
| 字段 | 记录内容 | 填写口径 |
|---|---|---|
| 状态编号 | 状态的唯一标识 | 建议用“ST-序号”，便于流转表引用 |
| 状态名称 | 团队日常称呼的状态 | 使用动词或动宾短语，如“待处理”“修复中”“待验证”“已关闭” |
| 状态类型 | 状态所属的阶段类别 | 从待处理、处理中、待验证、已关闭等类别中选择，用于统计和看板分组 |
| 责任角色 | 该状态下负责推进的角色 | 写角色而非个人，如“测试工程师”“开发负责人” |
| 进入条件 | 缺陷进入该状态的前提 | 写可判断的事实，如“已提交且必填信息完整” |
| 退出条件 | 允许离开该状态的前提 | 写可核验的结果，如“修复说明已填写且关联代码变更” |
| 备注 | 补充说明 | 记录特殊约定或历史原因，可留空 |
流转表字段
| 字段 | 记录内容 | 填写口径 |
|---|---|---|
| 流转编号 | 流转的唯一标识 | 建议用“FL-序号”，与状态编号区分 |
| 起点状态 | 流转发生前的状态 | 引用状态表中的状态名称 |
| 触发动作 | 引发状态变化的操作 | 写具体动作，如“提交缺陷”“提交修复”“验证通过”“验证不通过” |
| 目标状态 | 流转完成后的状态 | 引用状态表中的状态名称 |
| 必填字段 | 流转时必须补齐的信息 | 列出字段名，多个用顿号分隔 |
| 审批或确认人 | 对本次流转负责确认的角色 | 写角色，如“测试负责人”“缺陷评审组” |
| 备注 | 补充说明 | 记录例外条件或自动化规则，可留空 |
状态类型的作用在于把具体状态归入统一阶段。团队可以自定义“待复现”“修复中”“回归中”等名称，但归入待处理、处理中、待验证、已关闭等类型后，统计口径、看板列和报表就能跨项目对齐。状态类型宜少不宜多，通常四到五类即可覆盖缺陷从提交到关闭的全过程。
必填与选填：哪些字段不能空
必填字段决定流程图能否被正确执行。判断标准是：缺少该字段时，下一个角色无法判断是否应当接手或放行。满足这一条件的字段设为必填，其余设为选填。
| 表 | 字段 | 必填/选填 | 理由或适用场景 |
|---|---|---|---|
| 状态表 | 状态编号 | 必填 | 流转表需要引用，缺失会导致对应关系断裂 |
| 状态表 | 状态名称 | 必填 | 流程图节点和日常沟通都依赖该名称 |
| 状态表 | 状态类型 | 必填 | 统计与看板分组依赖类型，缺失会造成口径不一 |
| 状态表 | 责任角色 | 必填 | 明确谁推进，避免缺陷停在无人负责的状态 |
| 状态表 | 进入条件 | 必填 | 防止缺陷被随意置入某状态 |
| 状态表 | 退出条件 | 必填 | 作为流转放行的判断依据 |
| 状态表 | 备注 | 选填 | 用于记录特殊约定 |
| 流转表 | 流转编号 | 必填 | 评审、配置和问题追溯时用于引用 |
| 流转表 | 起点状态 | 必填 | 流转的起点，缺失则路径不成立 |
| 流转表 | 触发动作 | 必填 | 说明什么操作引发流转，是执行依据 |
| 流转表 | 目标状态 | 必填 | 流转的终点，缺失则路径不成立 |
| 流转表 | 必填字段 | 必填 | 即使该次流转无需补充信息，也应填写“无”，以区分“未填”和“无需填” |
| 流转表 | 审批或确认人 | 必填 | 明确放行责任；无需审批的流转填写“无需确认” |
| 流转表 | 备注 | 选填 | 记录例外条件、自动化规则或历史调整原因 |
必填缺失时的阻断规则建议统一为三条：状态表中状态名称、类型、责任角色、进出条件任一为空，该状态不得进入流程图评审；流转表中起点或目标状态无法在状态表中找到对应项，该流转视为无效；流转执行时必填字段未补齐，系统或流程应阻止状态变更，并提示缺失项。对于“必填字段”和“审批或确认人”两列，允许填写“无”或“无需确认”，但不允许留空，这样评审时能区分“已确认无需”与“漏填”。
填写示例：一条缺陷从提交到关闭
以下示例为演示情景，用于说明两张表如何对应填写，不代表任何特定团队的真实流程。
示例缺陷基本信息
缺陷编号 BUG-1024，标题“订单列表页在筛选后分页跳转回第一页”，提交人测试工程师，所属模块订单管理，严重程度中等。该缺陷经历提交、受理、修复、验证不通过、再次修复、验证通过、关闭的完整过程。
状态表填写结果
| 状态编号 | 状态名称 | 状态类型 | 责任角色 | 进入条件 | 退出条件 | 备注 |
|---|---|---|---|---|---|---|
| ST-01 | 待处理 | 待处理 | 测试负责人 | 缺陷已提交且必填信息完整 | 已分配处理人并确认受理 | |
| ST-02 | 修复中 | 处理中 | 开发负责人 | 已受理并指定修复人 | 修复说明与关联变更已填写 | |
| ST-03 | 待验证 | 待验证 | 测试工程师 | 开发已提交修复 | 验证结论已记录 | |
| ST-04 | 已关闭 | 已关闭 | 测试负责人 | 验证通过或确认非缺陷 | 关闭原因已记录 | 关闭后如需重开，走单独流转 |
流转表填写结果
| 流转编号 | 起点状态 | 触发动作 | 目标状态 | 必填字段 | 审批或确认人 | 备注 |
|---|---|---|---|---|---|---|
| FL-01 | （新建） | 提交缺陷 | 待处理 | 标题、复现步骤、环境、严重程度 | 无需确认 | 新建不在状态表中单列 |
| FL-02 | 待处理 | 受理并分配 | 修复中 | 处理人、计划修复版本 | 测试负责人 | |
| FL-03 | 修复中 | 提交修复 | 待验证 | 修复说明、关联代码变更 | 开发负责人 | |
| FL-04 | 待验证 | 验证不通过 | 修复中 | 验证结论、失败现象 | 测试工程师 | 退回原处理人 |
| FL-05 | 待验证 | 验证通过 | 已关闭 | 验证结论、验证环境 | 测试负责人 | |
| FL-06 | 已关闭 | 申请重开 | 待处理 | 重开原因 | 测试负责人 | 用于回归发现遗留问题 |
对照两张表可以检查一致性：流转表中出现的每个状态都能在状态表中找到；状态表中每个状态至少有一条进入流转和一条退出流转，已关闭状态通过 FL-06 保留重开路径；FL-04 与 FL-03 构成修复与验证之间的往返，对应示例缺陷“验证不通过后再次修复”的过程。示例中的必填字段也与上一节规则一致，提交环节要求复现步骤和环境，修复环节要求修复说明与关联变更。
调整与维护方法：让流程图跟得上团队
模板投入使用后，状态和流转会随团队分工、发布节奏和工具配置变化。维护的目标是让两张表始终与团队实际执行一致，避免流程图停留在文档里、实际处置另有一套。
新增或合并状态的判断依据
- 新增状态的条件：某类缺陷在现有状态下长期积压，且需要不同角色接手或不同信息才能推进，例如引入“待复现”承接无法稳定复现的缺陷。
- 合并状态的条件：两个状态由同一角色负责、进入退出条件几乎相同，且统计上不需要分开观察，可合并为一个状态并保留原编号作为备注。
- 删除状态前先检查流转表：确认没有流转以该状态为起点或终点，或已为其设计替代路径，再执行删除。
流转变更的评审与通知方式
- 变更提出：由日常使用最多的角色提出，说明变更原因、影响的流转编号和预期效果。
- 评审范围：涉及审批或确认人变化的流转，需相关角色共同确认；仅调整必填字段的，可由流程负责人确认。
- 通知方式：变更生效后在团队例行会议或协作空间中公布，附新旧流转对照，并同步更新流程图和工具中的状态配置。
模板版本记录与定期复核
建议在模板文件顶部保留版本记录，至少包含版本号、变更日期、变更内容和确认人。复核节奏可按发布周期安排，例如每个版本发布前检查一次状态与流转是否仍匹配实际处置；连续两个周期无变更时，可延长复核间隔。复核时重点看三类信号：某状态长期无人推进、某条流转频繁被绕过、必填字段经常被事后补填。出现这些信号，说明模板需要调整。
当团队把缺陷状态与流转放到研发管理工具中执行时，模板中的两张表可以直接对应工作项的状态配置与流转规则。以 ONES 为例，缺陷可作为工作项类型配置状态与流转，必填字段和确认角色可随流转设置，状态变更记录留在工作项中，便于按模板版本核对实际执行情况。工具承载的是执行与留痕，模板本身仍需按上述规则维护，两者保持同一口径，流程图才不会与实际处置脱节。
常见问题
团队状态名称和公司统一模板不一致，应该改哪一边？
先看差异是否只停留在叫法上。如果团队说的“回归中”与模板里的“待验证”在责任角色、进入条件和退出条件上完全一致，保留团队名称、在备注中注明对应关系即可，统计时按状态类型归并。如果两者在责任角色或放行条件上不同，说明它们实际是两个状态，应分别建行，再在流转表中补齐两者之间的流转。调整后同步更新流程图和工具中的状态配置，避免文档与执行各说一套。
缺陷被判定为非缺陷或重复提交，流程图里怎么处理？
这类情况通常不需要新增状态，而是在关闭环节增加一条流转：起点为待处理或待验证，触发动作为“判定非缺陷”或“标记重复”，目标状态为已关闭，必填字段写判定依据和被合并到的缺陷编号，确认人写测试负责人。这样关闭原因有记录，后续统计缺陷有效率时也能区分正常修复关闭与判定关闭。若团队希望单独观察这类结果，可增加一个“已拒绝”状态，但要同步检查它是否有对应的退出路径，例如申请重开。
流转表里的“必填字段”和缺陷提交时的必填项是一回事吗？
两者作用范围不同。提交时的必填项约束的是缺陷创建，保证缺陷可被理解和复现；流转表中的必填字段约束的是某一次状态变化，保证接手方有足够信息判断是否放行。例如提交时要求复现步骤和环境，提交修复时要求修复说明和关联代码变更。填写时逐条流转列出该次变化需要补齐的信息，与提交必填项分开维护，避免把所有字段都堆在创建环节。
模板填好后，怎么判断流程图是否真的在被执行？
可以看三个可观察的信号：某个状态长期没有缺陷流出，说明责任角色或退出条件设置不合理；某条流转频繁被跳过，说明该流转的审批或必填要求与实际工作节奏不匹配；必填字段经常在流转完成后补填，说明阻断规则没有生效或字段过多。发现信号后回到两张表定位具体行，调整责任角色、必填字段或确认人，再按变更评审流程发布新版本。定期复核时对照工具中的状态变更记录，比只看文档更能反映实际执行情况。
小团队可以简化这套模板吗？
可以。小团队可先保留待处理、修复中、待验证、已关闭四个状态，流转表只保留提交、受理、提交修复、验证通过、验证不通过五条主路径，重开和判定非缺陷作为备注中的例外处理。状态类型仍建议保留，便于后续统计口径对齐。随着缺陷量增加或角色分工变细，再按新增状态的判断依据逐步补充，例如无法稳定复现的缺陷增多时引入“待复现”。简化的是行数，两张表的结构和必填规则建议保留。
