缺陷受理规则要回答的是一组可判定的问题：这条缺陷是否进入处理队列、由谁负责、按什么优先级推进、超时或信息不足时怎么办。本文按准入、分诊、责任分配、时效升级、复核维护五段展开，交付准入条件表、分诊字段与判定表、角色职责表、时效升级规则和检查清单，供团队直接填写使用。
要点总览（TL;DR）
- 受理规则要覆盖四类判定：是否受理、归谁负责、多急处理、何时复核，分别对应准入条件、责任分配、分诊定级和时效复核。
- 规则落地的最小产物是准入条件表、分诊字段表、责任分配表，再配一份时效与升级规则，写成可填写的字段和判定组合。
- 严重度描述缺陷影响，优先级描述排期顺序，两者分开定义，可减少分诊与排期争议。
- 责任分配优先按模块归属落到模块负责人，归属不明时走协查路径并设定裁定人，避免缺陷在队列中无人接收。
- 规则上线后看退回率、归属争议次数、受理时长分布三项指标，按月或按迭代复核并记录变更。
缺陷受理规则要解决哪几个判定问题
受理规则覆盖缺陷从提交到进入处理队列这一段决策，核心是四类判定：是否受理、归谁负责、多急处理、何时复核。这四类判定分别对应准入条件、责任分配、分诊定级和时效复核，缺一项就会出现“缺陷堆在队列里没人认领”或“分诊人凭印象定级”的情况。
需要明确边界：受理规则决定缺陷是否进入处理流程以及进入时的属性，缺陷进入处理后的状态流转设计、根因分析与预防措施属于相邻主题，不在本文展开。受理环节只负责把缺陷交到正确的责任人手上，并给出可执行的处理时限。
规则落地的最小产物有三张表：
- 准入条件表：列出提交时必须具备的信息，以及不予受理或退回补充的条件。
- 分诊字段表：定义严重度、影响范围、复现概率等字段的取值和判定口径。
- 责任分配表：把模块或责任域映射到具体角色，并说明归属不明时的协查路径。
三张表配合一份时效与升级规则，构成一套可以直接执行的受理规则。规则写成字段和判定组合，分诊人按表填写即可得出结论，减少同一现象被判成不同等级的分歧。
受理入口与准入条件怎么写
受理入口按来源划分，常见的有测试执行发现、线上监控与用户反馈、客户工单转交、内部自查四类。不同入口的提交人不同，必填信息的完整度也不同，规则要分别说明每个入口由谁提交、提交到哪里、需要附带什么材料。
准入必填项建议固定为五项，提交方在进入分诊前完成自检：
| 必填项 | 填写要求 | 自检标准 |
|---|---|---|
| 复现步骤 | 按操作顺序列出，标明前置条件 | 他人按步骤可复现，或注明复现概率 |
| 环境与版本 | 操作系统、浏览器、客户端版本、服务端版本 | 能定位到具体构建或发布批次 |
| 期望结果与实际结果 | 分别描述，附截图或日志 | 两者差异可观察，不依赖主观评价 |
| 影响对象 | 受影响的用户群体、功能模块、数据范围 | 能说明影响是单用户、部分用户还是全量 |
| 发现来源 | 测试、线上、工单或自查 | 与受理入口对应 |
不予受理与退回补充要分开定义。不予受理适用于明显不属于缺陷的情况，例如需求理解偏差、环境配置错误、已被确认为已知限制；退回补充适用于信息不足以判断的情况，例如缺少复现步骤或版本信息。退回后缺陷回到提交人处，补齐信息可重新提交，规则要写明退回时附带的补充清单，避免来回多轮。
准入条件的写法用可观察事实，不用主观判断。例如写“缺少可执行的复现步骤或版本信息时退回补充”，比写“信息不完整时退回”更容易执行；写“期望结果与实际结果均有文字或截图记录”，比写“描述清楚”更可核验。
分诊字段与受理判定表怎么设计
分诊字段把经验判断转成填写动作。建议设置五个核心字段，每个字段给出有限取值和判定口径：
| 字段 | 取值 | 判定口径 |
|---|---|---|
| 严重度 | 致命、严重、一般、轻微 | 按业务中断程度、数据影响、是否有替代方案判定 |
| 影响范围 | 全量用户、部分用户、单用户、内部可见 | 按受影响账号数或功能入口占比判定 |
| 复现概率 | 必现、高频、偶现、仅一次 | 按固定步骤重复执行的复现次数区间判定 |
| 模块归属 | 按产品模块或服务域填写 | 按缺陷现象对应的功能入口和代码责任域判定 |
| 是否阻塞发布 | 是、否 | 按当前迭代或发布计划的准出条件判定 |
严重度与优先级要分开。严重度描述缺陷造成的影响，由分诊人根据影响范围和业务中断程度填写；优先级描述排期顺序，由模块负责人结合当前迭代目标和修复成本确定。两者分开后，一个严重度高但影响面小的缺陷可以排在阻塞发布的缺陷之后，减少“严重度等于优先级”带来的排期争议。
受理判定表按字段组合给出结论。例如“严重度为致命且阻塞发布为是”对应立即受理并进入最高时限；“复现概率为仅一次且影响范围为单用户”对应受理但排入常规队列，由模块负责人评估是否需要更多信息。判定表用表格列出常见组合即可，不必穷举所有取值，未覆盖的组合由分诊人提交复核。
在工具承载上，这些字段需要作为工作项的固定属性存在，分诊人填写后能触发对应的流转和通知。ONES 测试管理支持从测试用例执行结果创建缺陷任务并在测试与研发团队间流转，缺陷可关联至迭代，适合把分诊字段和受理结论放在同一条工作项记录上；字段的具体配置方式需按团队实际环境核验。
责任分配与角色分工如何落地
受理环节涉及五类角色，每个角色在受理阶段有明确的输入、动作和交付物：
| 角色 | 输入 | 动作 | 交付物 |
|---|---|---|---|
| 提交人 | 缺陷现象与现场信息 | 按准入条件填写并自检 | 符合必填项的缺陷记录 |
| 分诊人 | 缺陷记录、模块归属规则 | 填写分诊字段，给出受理结论 | 受理结论与处理时限 |
| 模块负责人 | 受理结论、当前迭代目标 | 确认责任人，确定优先级 | 责任人与排期结论 |
| 修复人 | 分诊结论与复现信息 | 确认可复现性，反馈修复计划 | 修复计划或退回说明 |
| 验证人 | 修复结果与验证环境 | 按原复现步骤验证 | 验证结论 |
责任分配优先按模块归属落到模块负责人，再由模块负责人指定修复人。模块归属表要覆盖主要功能模块和服务域，并注明每个模块的负责人和备份人，避免负责人休假时缺陷无人接收。跨模块缺陷由分诊人按主要影响面归属，涉及多个模块时指定一个主责模块，其余模块作为协查方参与。
分诊人无法判定归属时走协查路径：在缺陷记录中标注待协查，通知候选模块负责人确认，协查结论和确认人记录在案。协查有时限，超时未确认的由分诊人的上级或质量负责人裁定，裁定结果作为后续同类缺陷的归属依据。责任分配规则要写明协查的发起条件、参与人和裁定人，避免归属争议反复出现。
受理时效、退回与升级机制
受理响应时限按严重度分级设定。致命和阻塞发布的缺陷要求当日受理并给出处理计划，严重缺陷在一个工作日内受理，一般和轻微缺陷按周批量分诊。时限的设定依据是缺陷对业务的影响速度和团队的分诊能力，团队规模不同可以调整具体时长，但分级逻辑保持一致。
受理环节有三类非受理结论，处理规则各不相同：
- 退回补充：信息不足时退回提交人，附补充清单，补齐后重新进入分诊，退回次数计入提交质量统计。
- 判定为重复：关联到已有缺陷记录，保留原记录链接，由原缺陷的责任人继续处理。
- 判定为非缺陷：记录判定依据和判定人，通知提交人；提交人如有异议，可在规定时间内申请复核，由质量负责人裁定。
超时未受理和归属争议走升级路径。超时未受理的缺陷自动提醒分诊人和模块负责人，超过升级时限后上报质量负责人；归属争议在协查时限到期后由质量负责人裁定。升级规则要写明每一级的触发条件、通知对象和决策人，避免升级停留在提醒层面。
受理结论变更时需要留痕：记录变更前后的结论、变更原因、变更人和时间。严重度上调、责任人更换、从非缺陷改为受理都属于变更，留痕既便于复盘，也为后续规则调整提供依据。
一个完整的受理示例
以下为演示情景，用于说明字段填写与判定过程。某电商系统在版本发布前的回归测试中，测试人员发现订单提交后偶发重复扣款。提交信息包括：复现步骤为“购物车结算—提交订单—网络延迟超过3秒时重复点击提交”，环境为测试环境、客户端版本 3.8.2，期望结果为一次扣款，实际结果为同一订单出现两笔扣款记录，影响对象为使用该版本的部分用户，来源为测试执行发现。准入自检通过，五项必填信息齐全。
分诊人逐项填写：严重度定为致命，依据是涉及资金且无替代方案；影响范围定为部分用户，依据是仅在网络延迟场景触发；复现概率定为高频，依据是按步骤重复执行多次可稳定复现；模块归属定为订单服务；是否阻塞发布定为是。按受理判定表，该组合对应立即受理，处理时限为当日给出修复计划。
责任分配结果为：订单服务模块负责人接收，指定修复人，支付模块作为协查方确认是否存在重复回调。受理结论记录为“受理，致命，阻塞发布”，时限当日。若提交时缺少网络延迟条件，分诊人按退回补充处理，附上“补充触发条件与复现次数”的清单，提交人补齐后重新进入分诊，再按上述字段判定。
这个示例说明受理规则的价值在于每一步都有依据可查：准入看必填项，分诊看字段口径，责任看模块归属表，时限看判定表。规则执行中出现的争议，最终都会回到某张表的某一行，便于修正。
规则上线后的检查与维护
规则是否被真正使用，看三个可观察指标：退回率反映准入条件的清晰程度，退回率过高说明必填项定义模糊或提交方培训不足；归属争议次数反映模块归属表的覆盖度，争议集中在某几个模块时需要补充负责人或拆分责任域；受理时长分布反映时限设置是否合理，长尾集中在某一严重度时检查该级别的分诊人力。
定期复核建议按月或按迭代进行，检查项包括：退回补充的缺陷是否都在规定轮次内补齐、超时未受理的缺陷是否都走了升级、受理结论变更是否有记录、模块负责人和备份人是否仍然有效。复核由质量负责人或测试负责人牵头，模块负责人参与。
规则调整的触发条件写清楚：连续两个周期退回率超过约定阈值、归属争议集中在同一模块、某严重度的受理时长持续超出时限，都触发对应条款的修订。每次修订记录变更内容、原因、生效时间和影响范围，旧版本存档备查。
规则文档与分诊字段要保持同步。字段增删或取值调整时，判定表、责任分配表和时效规则中引用该字段的部分一并更新，避免文档与工具中的实际配置不一致。ONES 测试管理提供项目缺陷分布统计，可用于观察缺陷在模块和严重度上的分布，作为复核的参考数据；受理时长、退回率等指标能否直接统计需按实际配置确认。
常见问题
提交人认为缺陷被判定为非缺陷，应该怎么处理？
受理规则里要为“判定为非缺陷”保留异议通道。分诊人给出判定时，需记录判定依据和判定人，并通知提交人；提交人如有异议，可在规则约定的时间内申请复核，由质量负责人或指定的裁定人给出最终结论。复核结论同样要留痕，包括原判定、复核意见和最终结论，便于后续同类问题参照。
如果异议集中在某类现象上，说明准入条件或分诊字段的判定口径需要补充，可在下一次规则复核时修订对应条款。
模块负责人休假或离职时，缺陷责任怎么接续？
责任分配表要为每个模块注明负责人和备份人，负责人无法处理时由备份人接收。规则中写明备份人的确认方式，例如在缺陷记录中标注转交并通知备份人，转交记录保留在原缺陷上。
模块负责人长期空缺时，由分诊人上报质量负责人，临时指定接收人，并在规则复核时更新模块归属表。跨模块缺陷由分诊人按主要影响面指定主责模块，其余模块作为协查方参与，避免责任悬空。
团队规模较小，受理时限和角色分工可以简化吗？
可以简化具体时长和角色数量，分级逻辑保持一致。小团队中分诊人和模块负责人可能由同一人兼任，此时仍要保留准入自检、分诊字段填写和受理结论记录三个动作，否则缺陷进入队列后缺少判定依据。
时限可以按团队实际分诊能力调整，例如致命和阻塞发布的缺陷当日受理，其余缺陷按周批量分诊。调整后的时长写入规则文档，并在复核时观察受理时长分布是否出现长尾集中。
受理结论确定后，严重度或责任人还能改吗？
可以改，但要留痕。严重度上调、责任人更换、从非缺陷改为受理都属于受理结论变更，需记录变更前后的结论、变更原因、变更人和时间。变更记录既便于复盘，也为规则调整提供依据。
如果同一类缺陷频繁出现严重度上调，说明分诊字段的判定口径需要细化，例如补充影响范围的量化标准，或在判定表中增加对应组合。
受理规则需要借助工具承载时，应该关注哪些配置点？
重点看三处：分诊字段能否作为工作项固定属性并设置必填校验；受理结论能否触发对应的流转和通知；受理时长、退回率等指标能否从系统中统计。ONES 测试管理支持从测试用例执行结果创建缺陷任务并在测试与研发团队间流转，缺陷可关联至迭代，可作为承载受理记录的载体之一；字段配置、流转规则和统计口径需按团队实际环境核验。
