缺陷流转要解决的是“谁在什么条件下把缺陷推进到下一步”，而不是只画一张状态图。本文给出一套可直接落地的做法：先定义有限的状态和迁移条件，再明确各角色的动作与交付物，随后补齐退回、重开、挂起、超期等异常规则，最后用流转记录和停留时长检验执行情况。这些规则通常需要在研发管理工具中承载，ONES 可作为其中一种落地载体。
要点总览（TL;DR）
- 缺陷流转先定一组含义唯一的状态（新建、已确认、处理中、待验证、已关闭、已拒绝或延后），每条迁移写清触发条件、责任角色、必填字段和下一状态。
- 角色按“谁有权推进到下一状态”划分：关闭权交给测试或独立验证角色，拒绝与延后权交给模块负责人，重开权交给发现问题的测试或提交人。
- 退回、重开、挂起、延后和超期都要在流程设计阶段写成规则，异常操作留下理由、责任人和到期时间。
- 用流转记录完整性和各状态停留时长检验执行情况，停留集中的环节通常指向规则或责任划分问题。
- 规则变更走评审并同步更新迁移表、权限和检查清单，历史缺陷保留原有流转记录。
缺陷流转先定哪几个状态和迁移条件
第一版状态集合建议控制在六个左右，每个状态只表达一种确定含义。状态过多会让团队在“处理中”和“修复中”之间反复犹豫，状态过少则无法区分“已修复”和“已验证”。一个可用的最小集合是：新建、已确认、处理中、待验证、已关闭、已拒绝或延后。
每个状态的含义要写成一句可判断的话。例如“已确认”指缺陷已被确认可复现且归属明确；“待验证”指开发已提交修复并附上验证入口；“已关闭”指验证通过且证据齐全。含义模糊的状态会在流转中制造争议。
迁移规则按四要素书写：触发条件、责任角色、必填字段、下一状态。四要素齐全，不同的人执行同一条规则才能得到一致结果。下表是一份可直接改用的状态迁移表。
| 当前状态 | 触发条件 | 责任角色 | 必填字段 | 下一状态 |
|---|---|---|---|---|
| 新建 | 提交人完成缺陷描述并提交 | 提交人 | 复现步骤、环境、期望与实际结果、严重程度 | 已确认 / 已拒绝 |
| 已确认 | 确认可复现且归属模块明确 | 测试或模块负责人 | 归属模块、负责人、优先级 | 处理中 / 延后 |
| 处理中 | 开发开始修复并记录方案 | 开发 | 修复说明、影响范围、提交验证的入口 | 待验证 / 挂起 |
| 待验证 | 修复已提交，具备验证条件 | 开发 | 修复版本、验证步骤 | 已关闭 / 处理中 |
| 已关闭 | 验证通过且证据留存 | 测试 | 验证结论、验证环境与版本 | —（可重开） |
| 已拒绝 / 延后 | 判定为非缺陷、重复或暂不处理 | 模块负责人或发布决策者 | 判定理由、关联缺陷或计划处理时间 | 已关闭 / 已确认 |
准入准出条件要写成可判断的规则，避免“描述清楚”“影响可控”这类无法核对的表述。可判断的写法是：“复现步骤包含至少三步且每步有操作对象”“修复说明包含根因和改动范围”“验证结论包含验证版本和通过项”。规则能被第三方独立核对，才算写完。
状态数量的取舍看两个信号：如果团队经常争论某条缺陷该放哪个状态，说明状态含义重叠，需要合并；如果无法区分“已修复未验证”和“已验证未发布”，说明缺少状态，需要补充。状态集合稳定后，新增状态要走变更评审，避免个人随手添加。
缺陷流转中的角色分工与交付物
角色分工按“谁有权把缺陷推进到下一状态”来界定，比按部门划分更容易执行。每个关键迁移点都要有唯一责任人，并明确该角色交付什么信息，否则状态推进会变成无人负责的等待。
| 角色 | 关键动作 | 交付物 | 权限边界 |
|---|---|---|---|
| 提交人 | 描述缺陷、补充复现信息、回应澄清 | 完整缺陷描述与环境信息 | 可提交、可补充，不直接关闭 |
| 测试 | 确认可复现性、执行验证、给出验证结论 | 确认结论、验证记录、退回原因 | 可关闭、可退回，不擅自改优先级 |
| 开发 | 定位根因、修复、提交验证 | 修复说明、影响范围、验证入口 | 可推进到待验证，不自行关闭 |
| 模块负责人 | 判定归属、裁定争议、决定延后 | 归属结论、延后理由与计划时间 | 可拒绝、可延后、可指派 |
| 发布决策者 | 决定缺陷是否阻塞发布、是否带缺陷上线 | 发布决策记录与风险说明 | 可批准带缺陷发布，可要求重开 |
关闭权建议放在测试或独立验证角色，拒绝与延后权放在模块负责人，重开权交给发现问题的测试或提交人。把关闭权交给修复者本人，会让“已修复”和“已验证”混为一谈。权限要落到具体的人或用户组，而不是停留在岗位名称上。
跨团队缺陷先定归属再进入流转。归属判定规则可以按“缺陷由哪个模块的代码或配置引起”确定，争议时由模块负责人裁定并记录理由。归属未定的缺陷停留在已确认状态，由提交人补充信息、模块负责人推进判定，避免在团队之间来回转派。
规则确定后，状态、必填字段和迁移权限需要在工具中配置成可执行的约束。ONES 支持未通过的用例快速创建缺陷任务，缺陷任务可在测试与研发团队间流转，并提供覆盖全生命周期的缺陷管理、缺陷关联迭代的能力；同时支持为不同用户组配置权限。团队可据此把上述状态与角色权限落到工作项上，具体状态机与迁移权限的配置方式以实际产品为准。
退回、重开、挂起与超期怎么处置
异常路径要在流程设计阶段写成规则，等出现争议再临时约定，往往演变成团队之间的责任推诿。以下四类规则可以直接纳入流程文档。
- 验证不通过退回。测试从待验证退回处理中时，必须填写未通过的具体项、实际观察结果和复现环境，责任随之转移回开发。退回不是重新描述缺陷，而是给出可定位的差异信息。退回次数在同一缺陷上累计记录，连续退回两次以上时由模块负责人介入判断是否为方案问题。
- 重开。重开的判定条件是：已关闭缺陷在相同或相近条件下再次出现，或原修复未覆盖描述中的场景。重开需关联原缺陷并注明重开理由，重开次数计入缺陷记录。重开次数偏高的模块，通常指向修复方案或验证范围的问题，可作为流程复盘的输入。
- 挂起与延后。挂起适用于依赖外部条件、暂时无法推进的缺陷，延后适用于确认存在但本周期不处理的缺陷。两者都要填写理由、责任人和到期时间，延后还需模块负责人或发布决策者审批。到期未处理的挂起与延后缺陷自动回到待处理队列，由负责人重新判定。
- 超期未推进。为每个状态设定停留时长上限，例如待验证超过约定天数未验证、处理中超过约定天数无更新。超期先提醒当前责任人，再次超期升级到模块负责人，持续超期进入发布评审视野。阈值按团队节奏设定，关键是阈值公开且提醒可追踪。
这四类规则共同的作用是把“卡住”变成可见状态。缺陷停在某个状态时，团队能判断是等待信息、等待修复还是等待决策，而不是只能看到一条长期未动的记录。
一个缺陷从提交到关闭的流转示例
以下为演示情景，用于说明状态、角色与字段如何串联，不代表真实项目数据。
提交与确认。测试在回归中发现“订单列表按金额排序后翻页结果重复”，提交缺陷并填写复现步骤、测试环境、期望与实际结果，严重程度定为中。缺陷进入新建。模块负责人当天确认可复现，补充归属模块为订单查询、指定开发负责人，状态推进到已确认，再进入处理中。
处理与提交验证。开发定位到分页参数与排序字段组合时的边界问题，在处理中状态填写根因、改动范围和影响接口，附上修复版本号与验证入口，状态推进到待验证。此时必填字段从“修复说明”切换为“修复版本与验证步骤”。
验证不通过退回。测试在待验证状态验证后发现，按金额排序正常，但按时间排序仍出现重复。测试填写未通过项、实际结果和复现环境，退回处理中。开发补充第二处边界处理，再次提交待验证，退回次数记录为一次。
关闭。测试在约定版本上验证两种排序均正常，填写验证结论、验证环境与版本，状态推进到已关闭。缺陷记录中保留了两次提交、一次退回和完整的状态变更时间，可作为后续同类问题的参考。
这条示例说明，流转的可靠性来自每个迁移点都有明确的责任人和必填信息。状态本身只是标签，字段和角色才让标签具备约束力。
缺陷流转的完成检查
流程建好不等于被执行。下面这份清单可逐项核对，用于判断缺陷流转是否真正落地。
| 检查项 | 核对方式 | 通过标准 |
|---|---|---|
| 状态与迁移规则完整可判断 | 抽查状态迁移表，检查每条规则是否具备触发条件、责任角色、必填字段、下一状态 | 每条迁移均可由第三方独立判断是否满足 |
| 角色与权限落实到人 | 核对关闭、拒绝、重开、延后操作的实际执行者 | 关键操作有唯一责任角色，权限配置到人或用户组 |
| 异常路径有明确规则 | 检查退回、重开、挂起、延后是否有理由字段和审批要求 | 异常操作均留下理由与责任人记录 |
| 流转记录与停留时长可查 | 抽取若干缺陷查看状态变更历史与各状态停留时间 | 能还原完整流转路径，能识别停留异常的环节 |
| 规则变更可维护 | 查看状态或字段调整是否有评审记录和生效说明 | 变更经过评审，历史缺陷数据不受破坏 |
检查时优先看停留时长分布。如果大量缺陷集中在待验证，问题可能在验证资源或验证标准；如果集中在已确认，问题可能在归属判定。停留数据比状态数量更能反映流程的真实运行情况。
规则变更后要同步更新迁移表、角色权限和检查清单，并对历史缺陷保留原有流转记录。流程的稳定性来自规则可维护，而不是一次定完不再调整。
常见问题
团队规模小、缺陷量不大，还需要设这么多状态吗？
状态数量按团队实际需要取舍，不必照搬六个。判断标准是能否区分关键节点：如果团队需要区分“已修复未验证”和“已验证”，待验证状态就应保留；如果经常争论某条缺陷该放哪个状态，说明状态含义重叠，应合并。小团队可以先从新建、处理中、待验证、已关闭四个状态起步，随缺陷量和协作复杂度增加再补充已确认、已拒绝或延后。
缺陷归属在两个团队之间有争议时，流转应该停在哪一步？
归属未定的缺陷停留在已确认状态，由提交人补充复现信息和影响范围，模块负责人推进归属判定并记录理由。归属判定可按“缺陷由哪个模块的代码或配置引起”确定，争议时由模块负责人裁定。归属确定后再进入处理中，避免缺陷在团队之间反复转派而无人真正修复。
退回和重开有什么区别，记录方式要分开吗？
退回发生在待验证阶段，指修复已提交但验证未通过，责任转移回开发，需填写未通过项、实际观察结果和复现环境。重开发生在已关闭之后，指缺陷在相同或相近条件下再次出现，或原修复未覆盖描述场景，需关联原缺陷并注明理由。两者建议分开记录：退回次数反映修复方案质量，重开次数反映验证范围与关闭把关，分开统计才能定位问题环节。
超期提醒的阈值怎么定，定得太严会不会造成干扰？
阈值按团队节奏设定，例如待验证超过约定天数未验证、处理中超过约定天数无更新。关键是阈值公开、提醒可追踪，并与升级路径配套：先提醒当前责任人，再次超期升级到模块负责人，持续超期进入发布评审视野。阈值过严会产生大量无效提醒，可先按现有缺陷的实际停留时长分布取一个偏宽松的值，运行一段时间后再收紧。
状态和迁移规则定好后，在工具里怎么保证被执行？
把状态、必填字段和迁移权限配置成工具中的约束，让不符合规则的推进无法完成，比靠文档约定更可靠。ONES 支持未通过的用例快速创建缺陷任务，缺陷任务可在测试与研发团队间流转，并提供覆盖全生命周期的缺陷管理、缺陷关联迭代的能力，同时支持为不同用户组配置权限。团队可据此把状态与角色权限落到工作项上，具体状态机与迁移权限的配置方式以实际产品为准。
