制定缺陷分派规则，核心是把“这条缺陷该由谁受理、按什么依据决定”写成一张可执行的判定表，让分诊人不必每次凭经验判断。本文按字段定义、责任归属判定、角色时限、示例演示和上线检查的顺序展开，覆盖从提交到确定受理人的受理决策环节；缺陷状态流转规则与根因分析属于相邻主题，本文不展开。
要点总览（TL;DR）
- 分派规则的核心是一张可执行的判定表：先固定模块/组件、严重程度、影响范围、复现环境、来源渠道等分诊字段，再按条件逐条映射到受理人。
- 判定顺序建议为组件负责人优先、严重程度触发升级、跨模块归口主责团队、无法判定进分诊池，并保留兜底行与处理时限。
- 规则要配运行机制：分诊人、模块负责人、团队接口人、分诊负责人各有时限，分错退回分诊池重新判定，不允许个人之间直接转派。
- 上线前逐项核对字段完整性、兜底覆盖、角色时限落实到人、纠偏与变更责任，上线后前两三个迭代加密复核。
- 分派结果需要系统承载时，缺陷工作项要能记录分诊字段、负责人变更留痕，分诊池以固定待分派状态呈现。
分派规则要解决哪几个判定问题
一套分派规则要能稳定回答三个问题：谁受理这条缺陷、依据什么信息作出这个判定、判定不了或判错时怎么办。这三个问题对应规则的三块内容——责任归属判定表、分诊字段规范和兜底与纠偏机制。缺少任何一块，规则都会退回到“找熟悉的人问一下”的状态。
规则的输入来自两个时点。提交时，提交人填写模块/组件、严重程度、影响范围、复现环境、来源渠道等字段；分诊时，分诊人核对字段、补充缺失信息，再据此查判定表。规则的作用范围到“确定受理人/团队”为止，受理之后的修复排期、验证关闭属于状态流转规则，定位原因、制定预防措施属于根因分析，两者与分派规则相邻但判定对象不同。
可以用一份判定问题清单来界定范围：
- 受理对象：缺陷落到个人负责人还是团队接口人？
- 判定依据：哪些字段参与判定，优先级如何？
- 兜底处理：字段缺失、跨模块、无明确负责人时进入哪个池子、由谁接手？
- 纠偏机制：分错后如何转派，谁有权改判？
清单确认后，规则设计就有了明确的边界，后续章节的字段与判定表都围绕这几个问题展开。
第一步：确定分诊所需的字段与判定依据
分派判定要稳定，前提是输入字段稳定。字段不齐或取值随意，判定表再细也无法执行。建议在制定规则前先固定下表所列字段，明确取值、必填要求和补录责任人。
| 字段 | 取值示例 | 必填 | 缺失时补录责任人 |
|---|---|---|---|
| 所属模块/组件 | 按产品架构枚举，如“订单服务/支付回调” | 是 | 提交人补充，分诊人核对 |
| 严重程度 | 阻断、严重、一般、轻微（附判定口径） | 是 | 分诊人按口径核定 |
| 影响范围 | 单用户、部分用户、全量用户、特定环境 | 是 | 提交人补充 |
| 复现环境 | 环境类型、版本号、设备或浏览器 | 是 | 提交人补充，缺失时退回 |
| 来源渠道 | 测试执行、线上监控、客户反馈、内部试用 | 是 | 提交人选择 |
| 提交人 | 系统自动记录 | 是 | 系统字段，无需补录 |
字段规范要写清两件事：枚举值只能从固定列表中选择，避免“严重”“很严重”混用；严重程度要附判定口径，例如“阻断”指核心流程不可用且无替代路径，让不同提交人对同一现象给出接近的判断。模块/组件字段建议与产品架构或代码仓库的归属保持一致，它是后续组件负责人判定的基础。
字段缺失时的处理方式也要写进规则：影响判定的关键字段（模块、严重程度）缺失时，缺陷退回提交人补录并注明原因；非关键字段缺失时，由分诊人在分诊环节补录，补录动作留痕。这样字段质量有责任人，判定表才有可靠输入。
第二步：编写责任归属判定表
判定表把“条件—结论”写成逐条可查的映射，并按固定顺序执行，前一条命中即停止。推荐顺序为：组件负责人优先、严重程度触发升级、跨模块归口主责团队、无法判定进分诊池。
| 顺序 | 条件 | 结论（受理人/团队） |
|---|---|---|
| 1 | 模块/组件有明确负责人，且缺陷属于该组件范围 | 分派给组件负责人 |
| 2 | 严重程度为阻断或严重，且影响范围为全量用户或核心流程 | 分派给组件负责人，同时通知团队负责人与测试负责人 |
| 3 | 缺陷涉及多个模块，无法归入单一组件 | 归口到主责团队：以缺陷首次出现的模块或主要影响链路所属团队为主责，其他团队作为协作方 |
| 4 | 模块无负责人、字段不足以判定或归属存在争议 | 进入分诊池，由分诊人当日内指定受理团队 |
| 兜底 | 以上均未命中 | 进入分诊池，由分诊负责人裁定并记录理由 |
跨团队缺陷的归口原则需要在规则中写明，避免两个团队互相推。常见做法是以“主要影响链路所属团队”为主责，主责团队负责修复与对外答复，协作团队在约定时限内提供支持；如果影响链路难以判断，则由分诊人根据复现路径指定主责，并在缺陷记录中写明依据，便于后续复核。
判定表要保留兜底行，并规定兜底行的处理时限。兜底不是把问题搁置，而是把“判不了”的缺陷集中到一个有明确责任人的池子里，由分诊人在限定时间内作出决定。
第三步：设定分诊角色、时限与升级路径
判定表解决“怎么判”，运行机制解决“谁来判、多久判完、判错怎么办”。角色分工建议按下表落实，每个角色对应到具体人员或值班安排。
| 角色 | 职责 | 关键时限 |
|---|---|---|
| 分诊人 | 核对字段、查判定表、完成分派或转入分诊池 | 新缺陷在一个工作日内完成分派 |
| 模块负责人 | 确认缺陷是否属于本组件，接收或退回并说明理由 | 收到分派后半个工作日内确认 |
| 团队接口人 | 跨团队缺陷的协作对接，协调本团队支持资源 | 按主责团队约定时限响应 |
| 分诊负责人 | 裁定归属争议、处理兜底池、组织定期复核 | 争议在当日内裁定 |
时限要配合提醒机制：缺陷进入待分派状态超过约定时间未处理，系统或值班流程提醒分诊人；分派后模块负责人未确认，提醒升级到团队接口人。分错后的转派规则同样要写清——接收方认为归属有误时，附上理由退回分诊池，由分诊人重新判定，不允许直接转给其他个人，避免缺陷在个人之间来回传递而失去跟踪。
升级路径按“分诊人→分诊负责人→研发负责人”逐级设置，触发条件包括超时未分派、归属争议无法裁定、同一缺陷被退回两次以上。定期复核建议按周或按迭代进行，抽样检查已分派缺陷的归属准确性，统计退回率和分诊池滞留时长，作为调整判定表和字段规范的依据。
当分派规则需要系统承载时，缺陷工作项本身要能记录模块、严重程度、来源渠道等字段，负责人变更和转派过程要留痕，分诊池可以用固定的待分派状态或队列呈现。ONES 测试管理支持未通过的用例快速创建缺陷任务，缺陷任务在测试与研发团队间流转，缺陷可关联至迭代，便于把分派结果与迭代交付放在同一处跟踪；分派准确性的复核也可以借助项目缺陷分布统计来观察缺陷集中在哪些模块。具体的字段自定义与自动分派配置，需结合团队实际使用的版本确认。
示例：一条缺陷如何按规则完成分派
以下为演示情景，用于说明判定表的使用方式。测试人员在回归测试中发现：支付回调在特定版本下重复扣款，影响部分用户，复现环境为预发布环境，来源渠道为测试执行。
提交时填写字段：模块为“订单服务/支付回调”，严重程度为“严重”，影响范围为“部分用户”，复现环境为“预发布环境、版本 3.2.1”，来源渠道为“测试执行”。分诊人核对字段齐全，按判定表逐条执行：第 1 条命中，支付回调组件有明确负责人，分派给该负责人；第 2 条同时命中，严重程度为严重且影响支付核心流程，因此在分派的同时通知团队负责人与测试负责人。整个过程在一个工作日内完成，受理人明确，通知对象明确。
对比另一种情形：同一缺陷如果模块字段填写为“支付相关”，无法对应到具体组件，第 1 条不命中；影响范围若为全量用户且严重程度为阻断，第 2 条因缺少组件归属也无法直接执行；此时进入第 4 条，缺陷进入分诊池，由分诊人根据复现路径确认归属到订单服务团队，并记录判定理由。两种情形的差别在于字段是否足以支撑判定，这也说明字段规范与判定表必须配套使用。
规则上线前的完成检查
规则定稿后，用下面的清单逐项核对，全部通过再上线。检查可以由分诊负责人组织，测试与研发团队接口人共同确认。
- 字段是否齐全：模块/组件、严重程度、影响范围、复现环境、来源渠道、提交人六项均有定义，枚举值固定，必填项明确。
- 严重程度是否有判定口径：每个等级有可对照的描述，提交人与分诊人对同一现象能给出接近判断。
- 判定表是否覆盖兜底：组件负责人、严重程度升级、跨模块归口、分诊池四条路径齐全，兜底行有明确处理人和时限。
- 角色是否落实到人：分诊人、模块负责人、团队接口人、分诊负责人均有具体人员或值班安排，不停留在岗位名称。
- 时限与升级是否可执行：分派、确认、争议裁定各有时间要求，超时提醒和升级路径有承载方式。
- 纠偏机制是否明确：退回与转派的规则、复核周期、复核指标（退回率、分诊池滞留时长）已确定。
- 变更责任是否指定：字段增删、判定表调整由谁提出、谁审批、多久评审一次，写入规则文档。
上线后前两到三个迭代建议加密复核频率，观察分诊池滞留和退回情况，再根据实际数据调整判定顺序或字段取值。规则文档与判定表保持同一版本，变更时同步更新，避免分诊人依据旧表操作。
常见问题
团队规模较小、没有专职分诊人时，这套规则还能用吗？
可以用，但角色需要合并。小团队常见的做法是模块负责人兼任分诊人，按周轮值，判定表和字段规范保持不变。需要保留的是兜底机制：轮值人遇到归属争议或字段不足时，指定一位固定裁定人（通常是研发负责人），避免争议停在轮值人手里。时限可以放宽，例如从半个工作日调整为一个工作日，但要有明确数值并写进规则，否则超时提醒和升级路径无法触发。
缺陷提交时模块字段经常填错，判定表还能执行吗？
能执行，但需要两道处理。第一道在提交环节：模块字段改为从固定枚举中选择，并与产品架构或代码仓库归属对齐，减少自由填写。第二道在分诊环节：分诊人核对模块字段，与复现路径明显不符时按实际归属修正并留痕，同时把填错情况反馈给提交人。如果某类填错反复出现，说明枚举划分与提交人的理解不一致，应调整枚举名称或补充示例，而不是靠分诊人长期纠错。
跨团队缺陷归口到主责团队后，协作团队不配合怎么办？
>
归口原则要在规则里写清主责与协作的义务：主责团队负责修复与对外答复，协作团队在约定时限内提供支持。协作不配合属于升级事项，触发条件可以设为协作请求超时未响应，升级路径沿“团队接口人→分诊负责人→研发负责人”逐级处理。同时建议在复核时统计跨团队缺陷的响应情况，把反复出现的协作阻塞作为调整归口原则的依据，例如改为按影响链路分段拆分子缺陷，各自归属清晰。
分派准确率怎么衡量，复核频率定多少合适？
可用的指标包括退回率（被接收方退回分诊池的比例）、分诊池滞留时长、同一缺陷被退回次数。复核频率按团队缺陷量确定：量大的团队按周抽样，量小的团队按迭代复核。规则上线后的前两到三个迭代建议加密复核，观察判定顺序和字段取值是否需要调整；稳定后转为常规周期。复核结论要落到规则文档的变更记录里，避免只统计不调整。
严重程度由提交人填写，和分诊人判断不一致时以谁为准？
以分诊人按判定口径核定的结果为准，但要把口径写清楚。严重程度每个等级附可对照的描述，例如“阻断”指核心流程不可用且无替代路径，提交人据此初判，分诊人复核时如调整等级需注明理由。等级调整会直接影响是否触发升级通知，因此调整动作要留痕，便于后续复核时判断口径是否需要修订。若同一类现象反复出现初判与核定不一致，应优先修订判定口径的描述，而不是逐条纠正。
