缺陷分配要解决的是“这条缺陷该不该进开发、由谁接、多久响应、退回怎么办”。做法是先分诊再派单：用严重程度、影响范围、复现状态、所属模块四项字段判断承接方向，再按模块负责人或轮值规则落到具体责任人，并约定响应时限与退回条件。本文围绕缺陷受理决策环节，给出可直接套用的流程、规则表、角色分工和检查清单。
要点总览（TL;DR）
- 缺陷分配按“先分诊、再派单”执行：分诊判断缺陷是否进入开发、由哪类角色承接，派单落到具体责任人并约定响应时限。
- 分诊字段固定为严重程度、影响范围、复现状态、所属模块四项，判定口径写成规则表，让不同分诊人对同一条缺陷得出接近结论。
- 派单优先按模块负责人归属，缺位时用轮值或备份负责人兜底；退回必须写明理由和需补充的信息，退回后回到分诊环节重新判定。
- 分诊人、模块负责人、开发责任人、验证人各有明确交付物，交接时至少包含分诊结论、责任人、优先级、补充要求和期望响应时间。
- 用超时未受理率、退回率与原因、重分配次数检查机制是否生效，并按季度或版本节奏复核规则表。
缺陷分配的核心答案与操作步骤
缺陷分配的顺序不能颠倒。分诊在前，回答“这条缺陷是否成立、属于哪类问题、应由哪类角色承接”；派单在后，回答“具体落到哪个人、什么时候必须响应”。如果跳过前端判定直接指派，常见结果是缺陷在测试与开发之间来回转移，或者被派给不熟悉该模块的人，处理周期被拉长。
整个流程可以拆成五个步骤，每一步都有明确的输入、动作、输出和完成标志，便于逐项核对。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 1. 提交受理 | 缺陷描述、复现步骤、环境信息、截图或日志 | 提交人按模板填写受理字段，系统生成缺陷记录 | 一条待分诊的缺陷记录 | 四项受理字段均已填写，缺项无法进入下一步 |
| 2. 分诊判定 | 待分诊记录、分诊规则表 | 分诊人核对严重程度、影响范围、复现状态、所属模块，判定是否进入开发及承接角色 | 分诊结论：进入开发／退回补充／转其他处理 | 分诊结论与判定依据写入记录，可被他人复核 |
| 3. 确定承接人 | 分诊结论、模块负责人清单或轮值表 | 按模块归属找到负责人；负责人缺位时按轮值或值班表指定 | 具体开发责任人 | 责任人字段已填写，且该人已知悉 |
| 4. 派单与响应 | 责任人、响应时限约定 | 通知责任人，责任人在时限内确认受理或提出退回 | 受理确认或退回申请 | 在响应时限内出现“已受理”或“已退回”状态 |
| 5. 退回处理与重派 | 退回申请及理由 | 分诊人复核退回理由，补充信息后重新判定或改派 | 重新分诊结论或新的责任人 | 缺陷回到有效流转状态，不再处于无人承接 |
响应时限需要按团队实际约定，常见做法是按严重程度分档：阻断类缺陷当日响应，一般缺陷在一个工作日内响应。时限一旦写入规则，就要在记录上可观察，否则超时无人发现。退回条件同样要事先写明，例如复现步骤缺失、环境信息不足、经核实属于需求变更而非缺陷，这些情形允许退回，退回时必须填写理由和需要补充的信息。
在工具承载上，缺陷记录本身就是一个工作项，受理字段对应工作项属性，承接人对应负责人字段，分诊、受理、退回对应状态变化。ONES Project 适配缺陷管理等场景，支持分配负责人，并支持一键提交 Bug 至对应项目或迭代、统计缺陷状态分布；ONES TestCase 支持未通过的用例快速创建缺陷任务，使缺陷在测试与研发团队之间流转。把上述步骤落到这类工作项上，分诊结论、责任人和状态变化会留痕，便于后续检查超时与退回情况。具体字段配置与自动化派单能力需以实际环境为准。
分诊规则表怎么编写：字段与判定标准
分诊规则表的作用是把“这条缺陷严不严重、该谁看”从个人经验变成可核对的判断。编写时不必追求字段多，而是保证每个字段都有明确的取值和判定口径，让两个分诊人对同一条缺陷能得出接近的结论。
建议固定以下字段，并为每个字段写明取值和判定说明：
| 字段 | 取值示例 | 判定说明 |
|---|---|---|
| 严重程度 | 阻断／严重／一般／轻微 | 阻断：核心流程不可用且无替代方案；严重：主要功能受损但有临时绕行方式；一般：非核心功能异常；轻微：界面、文案等不影响使用的问题 |
| 影响范围 | 全部用户／部分用户／单一场景／内部可见 | 按受影响的用户群体和业务场景描述，避免只写“影响较大” |
| 复现状态 | 稳定复现／偶现／无法复现／待确认 | 稳定复现需附步骤；偶现需注明出现频率和观察到的条件 |
| 所属模块 | 按系统模块清单取值 | 以缺陷实际出问题的功能模块为准，跨模块问题归主责模块并注明关联模块 |
| 优先级 | P0／P1／P2／P3 | 由严重程度与影响范围共同决定，不单独由提交人主观填写 |
严重程度与优先级要分开看。严重程度描述问题本身的破坏力，优先级描述在当前版本节奏下的处理次序。一条严重程度为“严重”的缺陷，如果只影响内部测试环境且已有绕行方案，优先级可以低于影响全部用户的一般缺陷。把两者的组合关系写成对照表，能减少分诊时的争论。
复现状态不明确时，不要直接派给开发。处理方式是退回提交人补充复现步骤、环境、账号或日志；如果提交人已尽力仍无法稳定复现，则由分诊人标记为“待确认”，指定一名熟悉该模块的成员在约定时间内协助定位，定位后再决定是否进入开发。这样避免开发收到无法验证的缺陷后反复询问。
模块归属的判断依据应来自系统模块清单，而不是提交人的猜测。分诊人对照清单确认归属；遇到跨模块问题，按主要出错环节确定主责模块，关联模块在记录中注明，由主责模块负责人协调。规则表本身需要维护：模块拆分、版本节奏变化或退回原因集中出现时，由分诊负责人发起修订，记录变更内容和生效时间，并通知相关角色，避免规则与实际执行脱节。
角色分工与交付物：谁分诊、谁承接、谁验证
缺陷分配出问题，多数时候不是流程缺失，而是角色边界模糊：分诊人只做转交不做判定，模块负责人只挂名不承接，验证环节没人对结果负责。把每个角色的职责和交付物写清楚，责任才不会悬空。
| 角色 | 职责 | 交付物 |
|---|---|---|
| 提交人 | 按模板提供缺陷描述、复现步骤、环境和证据 | 信息完整的缺陷记录 |
| 分诊人 | 依据规则表判定缺陷是否进入开发、承接角色与优先级；处理退回复核 | 分诊结论及判定依据 |
| 模块负责人 | 确认模块归属，指定或承接具体开发责任人；协调跨模块问题 | 承接人指派结果 |
| 开发责任人 | 在响应时限内确认受理或提出退回；负责修复并更新状态 | 受理确认、修复结果 |
| 验证人 | 对修复结果进行验证，确认缺陷关闭或重新打开 | 验证结论 |
分诊人对判定结论负责，这意味着分诊结论要写明依据，例如“严重程度定为严重，因支付主流程报错且无绕行方案”。模块负责人与开发责任人的边界在于：模块负责人对“谁来做”负责，开发责任人对“做不做、怎么做”负责。开发责任人认为分诊有误时可以退回，但不能既不处理也不回应。
验证人通常由提交缺陷的测试人员或对应模块的测试负责人担任，职责是依据原复现步骤确认问题是否消除，并检查修复是否引入新的异常。验证不通过时，缺陷重新打开并回到原开发责任人，而不是重新走一遍分诊。
交接时的信息要求要统一：分诊结论、责任人、优先级、需要补充的信息、期望响应时间，这几项缺一不可。责任人缺位时，按预先约定的轮值表或备份负责人兜底，并在记录中注明代承接原因；职责冲突，例如模块负责人同时是缺陷提交人，则由分诊负责人指定另一名承接人，避免自审自派。
示例：一条缺陷从提交到落到责任人
以下为演示情景，用于说明流转过程，不对应真实项目数据。
某电商系统测试人员在回归测试中发现：用户提交订单后，选择优惠券结算时页面报错，订单无法生成。初始信息为：严重程度暂填“严重”，影响范围为“使用优惠券的用户”，复现状态“稳定复现”，附有操作步骤和报错截图，所属模块暂填“订单”。
分诊人对照规则表判定：核心下单流程受阻且无绕行方案，严重程度维持“严重”；影响范围为部分用户，优先级定为 P1；复现步骤完整，复现状态确认“稳定复现”；出错环节在优惠券计算与订单提交的交界处，按主责模块归入“营销—优惠券”，关联模块注明“订单”。分诊结论为进入开发，承接角色为营销模块开发。
派单时，分诊人查询模块负责人清单，将缺陷指派给优惠券模块负责人，并通过工作项通知和团队群消息同步，约定当日响应。模块负责人确认后指定具体开发责任人，责任人字段更新，状态变为“已受理”。
假设该责任人查看后认为问题出在订单侧调用参数，提出退回，理由为“优惠券接口返回正常，订单侧传参缺少字段”，并附上接口日志。分诊人复核后退回理由成立，将模块归属改为“订单”，关联模块改为“优惠券”，重新指派给订单模块开发责任人。第二次派单后责任人在时限内受理，修复完成提交验证；验证人按原步骤复测通过，并补测了其他优惠券类型，确认无新增异常后关闭缺陷。整个过程记录了两次派单、一次退回及退回原因，可作为后续复核规则表的样本。
完成检查：缺陷分配机制是否跑通
机制是否生效，不能只看流程有没有写，而要看缺陷是否在约定时间内落到人、退回是否可控、重派是否频繁。建议按以下清单逐项核对，并持续观察几个指标。
- 规则表是否覆盖常见缺陷类型：抽取近一个月缺陷，检查严重程度、影响范围、复现状态、模块归属是否都有明确取值，是否存在大量“其他”“待定”。
- 超时未受理率：统计超过响应时限仍处于待受理状态的缺陷占比，按严重程度分档观察，阻断类缺陷应接近零。
- 退回率与退回原因：统计退回缺陷占已派单缺陷的比例，并按原因分类，例如信息不足、模块归属错误、非缺陷。信息不足集中出现，说明提交模板或提交前检查需要加强。
- 重分配次数：统计每条缺陷的平均派单次数，重派集中在哪些模块、哪些原因，据此判断模块清单或负责人清单是否需要更新。
- 责任人缺位兜底是否有效：检查缺位期间是否有缺陷长时间无人承接，轮值或备份负责人是否按约定生效。
- 规则表定期复核：约定复核周期，例如每季度或每个大版本结束后，由分诊负责人汇总退回与重派数据，修订字段口径和模块清单，并记录变更。
这些检查项可以做成一张周期性核对的清单，把数据来源、统计口径和责任人固定下来。若超时未受理率持续偏高，优先检查响应时限是否合理、通知是否真正触达责任人；若退回率偏高且集中在信息不足，优先改提交模板和提交前检查；若重分配次数偏高，优先核对模块归属规则。缺陷状态流转规则与根因分析属于相邻主题，可在本机制跑通后另行展开。
常见问题
团队规模小、没有专职分诊人时，缺陷分配怎么安排？
小团队可以不设专职分诊人，但分诊动作不能省。常见做法是由测试负责人或模块负责人轮流兼任分诊人，按天或按版本轮换，并在团队内公布当班人。分诊结论仍要写明判定依据，便于他人复核。如果缺陷量不大，也可以约定由提交人先按规则表自评严重程度和模块，再由当班分诊人确认，减少来回沟通。关键是分诊责任有明确归属，避免所有人都可以派单、又没人对判定负责。
开发责任人认为分诊结论有误，可以直接改派给别人吗？
不建议直接改派。开发责任人应在响应时限内提出退回，写明理由和依据，例如接口日志显示问题出在另一模块，或复现步骤无法验证。分诊人复核后退回理由成立，再修改模块归属并重新指派；理由不成立，则维持原派单并说明原因。这样退回和重派都有记录，后续统计退回原因时能看出是信息不足、模块归属错误还是非缺陷，规则表也据此修订。
缺陷在多个模块交界处出现，模块归属怎么定？
按主要出错环节确定主责模块，关联模块在记录中注明，由主责模块负责人协调。判断依据来自系统模块清单和实际报错位置，不按提交人的猜测填写。如果一时难以判断，分诊人可以指定一名熟悉相关模块的成员在约定时间内协助定位，定位清楚后再确定归属。跨模块问题容易在派单后反复转移，把主责和关联写清楚，能减少第二次退回。
响应时限和退回条件应该由谁定、多久调整一次？
响应时限和退回条件由分诊负责人牵头，与各模块负责人共同约定，按严重程度分档，例如阻断类当日响应、一般缺陷一个工作日内响应。时限要能在缺陷记录上观察到，否则超时无人发现。调整时机可以跟随规则表复核周期，例如每季度或每个大版本结束后，结合超时未受理率和退回原因分布判断时限是否过紧或过松，变更后通知相关角色并记录生效时间。
用工具承载缺陷分配时，需要关注哪些配置点？
重点看三处：受理字段能否作为工作项属性固定下来并设置必填，负责人字段能否按模块清单指派到具体的人，状态变化能否覆盖分诊、受理、退回几个环节并留下记录。ONES Project 适配缺陷管理等场景，支持分配负责人，并支持一键提交 Bug 至对应项目或迭代、统计缺陷状态分布；ONES TestCase 支持未通过的用例快速创建缺陷任务，使缺陷在测试与研发团队之间流转。自动派单、超时提醒等能力需以实际环境的配置情况为准。
