缺陷分诊要解决的是缺陷进入受理环节后的判断问题：这条缺陷是否成立、有多严重、该谁处理、下一步走哪条路径。本文按流程体系建设的思路，给出一套可直接落地的分诊机制，包括提交字段清单、严重度与优先级判定表、模块责任人映射规则、响应时限与复核办法，并附一个完整示例和上线前检查清单。
要点总览（TL;DR）
- 缺陷分诊在受理阶段产出四个决定：是否有效、严重度、优先级、责任归属；状态流转和根因分析分别属于后续环节。
- 分诊质量取决于提交信息完整度，把复现步骤、环境版本、影响范围、日志截图、发现阶段、复现概率固化为必填字段，并约定缺失时的退回与补充期限。
- 严重度看缺陷本身的影响，优先级看排期顺序，两者分开判定并分别记录理由，避免把严重度直接当优先级用。
- 责任分配依靠模块责任人映射表，跨模块缺陷按首次出现模块、调用链上游、契约变更方三条规则定主责，责任不清时按约定路径升级裁决。
- 分诊机制上线前逐项核对字段模板、分级表、映射表、时限与复核规则，先在一个项目或迭代试运行，用分诊耗时、退回率、结论调整比例评估效果。
缺陷分诊要产出哪四个决定
缺陷分诊是缺陷受理阶段的决策动作。每条新缺陷进入分诊环节后，分诊人需要给出四个明确结论，缺一不可。
- 是否有效：判断这条记录是否构成缺陷。重复提交、环境配置错误、需求理解偏差、使用方式不当，都应在这里识别出来，分别转入合并、退回或转需求讨论。
- 严重度：判断缺陷本身对系统造成的影响程度，依据是功能受损范围、数据影响和可恢复性，与什么时候修无关。
- 优先级：判断这条缺陷在当前排期中的处理顺序，依据是影响用户范围、是否存在临时绕行方案、与发布节点的关系。
- 责任归属：确定主责处理人，通常是模块责任人；跨模块缺陷还需指定主责方与配合方。
这四个决定与缺陷生命周期管理、根因分析属于不同环节。状态流转管理关注缺陷从新建、处理中、待验证到关闭的推进规则，分诊只负责把缺陷送到正确的起点；根因分析发生在缺陷修复之后，用于统计问题模式和预防复发，分诊阶段只需保证信息足够支撑后续分析。把三者混在一起，常见结果是分诊会开成了技术讨论会，结论迟迟出不来。
分诊结论需要留下最小记录，便于追溯和复核：分诊人、分诊时间、有效性结论、严重度、优先级、主责人、分诊依据（一句话说明判断理由）、以及是否触发退回或升级。这条记录不必很长，但要能回答“当时为什么这么判”。
分诊输入：提交时就该带齐的信息
分诊质量很大程度上取决于提交信息的完整度。信息残缺的缺陷，分诊人只能反复追问，响应时间被拉长，判断也容易失真。可行的做法是把必填字段固化到提交模板里，让提交人在提交时完成第一轮信息补齐。
| 字段 | 内容要求 | 责任人 |
|---|---|---|
| 标题 | 一句话描述现象，包含模块和触发条件 | 提交人 |
| 复现步骤 | 按顺序编号，写明前置条件和操作路径 | 提交人 |
| 环境与版本 | 测试或生产环境、客户端版本、服务端版本、浏览器或设备 | 提交人 |
| 影响范围 | 受影响的用户群体、功能模块、是否涉及数据 | 提交人 |
| 日志与截图 | 错误日志片段、接口返回、界面截图或录屏 | 提交人 |
| 发现阶段 | 需求评审、开发自测、测试执行、灰度、生产 | 提交人 |
| 复现概率 | 必现、高频、偶现，偶现需注明尝试次数 | 提交人 |
| 初步定位 | 可疑模块、相关提交或接口 | 分诊人补齐 |
提交人负责现象层面的信息：看到了什么、在什么条件下看到、影响谁。分诊人负责判断层面的补充：可疑模块定位、与已有缺陷的重复关系、是否需要补充特定环境日志。这条分工要写进模板说明，避免双方都以为对方会补。
字段缺失时的处理规则应当前置约定：缺少复现步骤或环境信息的缺陷，分诊人可以直接退回，并在退回说明中列出需要补充的具体字段，而不是笼统写“信息不全”。退回后设置补充期限，例如两个工作日内未补充则关闭或转入待定池。对于生产环境发现的紧急缺陷，允许先受理后补信息，但要在分诊记录中标注“信息待补”，并在修复前完成补齐。
严重度与优先级怎么分开判定
严重度和优先级混用是分诊中最常见的问题。两者判定依据不同：严重度描述缺陷的客观影响，优先级描述处理顺序，同一条缺陷可以严重度高而优先级低，也可以严重度中等但优先级很高。
| 严重度 | 判定依据 | 典型表现 |
|---|---|---|
| 致命 | 核心功能不可用，或造成数据丢失、数据错误、安全风险 | 登录失败、支付中断、数据写入错乱 |
| 严重 | 主要功能受阻，无合理绕行方案 | 关键流程某一步报错，用户无法完成任务 |
| 一般 | 功能可用但结果不正确，或存在可接受的绕行方案 | 展示数据偏差、非关键校验缺失 |
| 轻微 | 体验问题，不影响任务完成 | 文案错误、样式错位、提示不清晰 |
| 建议 | 优化类反馈，当前行为符合设计 | 交互改进建议、性能优化想法 |
| 优先级 | 判定依据 | 处理要求 |
|---|---|---|
| P0 | 影响大量用户或核心业务，无绕行方案，且临近发布节点 | 立即处理，当日响应 |
| P1 | 影响主要用户群体，绕行成本高，需在当前迭代内解决 | 当前迭代排入 |
| P2 | 影响范围有限，有可接受的绕行方案 | 排入后续迭代 |
| P3 | 影响面小，可与相关需求合并处理 | 进入待办池，定期评估 |
组合判定的示例如下：一条“报表导出偶现乱码”的缺陷，严重度定为一般，因为数据本身正确、导出功能可用，用户可重新导出；但如果该报表是客户对账的固定交付物，且本周有对账节点，优先级应定为 P1。反过来，一条“帮助文档链接失效”的缺陷，严重度是轻微，优先级通常是 P3，即使它出现在首页。判定时先定严重度，再结合用户范围、绕行方案和发布节点定优先级，两步分开记录理由。
责任分配：模块责任人与指派规则
责任分配的目标是让每条缺陷有且只有一个主责人。做法是维护一张模块责任人映射表，把系统模块与责任人、备份责任人对应起来。
| 模块 | 主责人 | 备份责任人 | 维护人 | 更新时机 |
|---|---|---|---|---|
| 订单服务 | A | B | 技术负责人 | 人员变动、模块拆分时 |
| 支付网关 | C | D | 技术负责人 | 同上 |
| 前端工作台 | E | F | 前端负责人 | 同上 |
映射表由各技术负责人维护，分诊人只负责按表指派，不自行判断谁更合适。表要指定明确的维护人和更新触发条件，否则人员调整后会出现指派给已离职成员的情况。
跨模块缺陷的主责判定遵循三条规则：优先归入缺陷首次出现的模块；无法判断来源时，归入调用链上游模块；涉及接口契约不一致的，归入契约变更方。主责人确定后，配合方由主责人在处理过程中自行拉通，分诊环节只记录主责，不展开协作细节。
责任人不明时的裁决路径要事先约定：分诊人无法按表判定时，提交给对应技术负责人裁决，裁决时限建议为一个工作日；仍无法确定的，升级到研发负责人。裁决结果要回写到映射表或分诊记录中，形成可复用的判断依据，减少同类争议重复发生。
分诊流转：响应时限、退回与复核
分诊环节需要时限约束，否则缺陷会在待分诊状态积压。时限设置可以按严重度或来源区分，例如生产环境缺陷要求两小时内完成分诊，测试环境缺陷要求一个工作日内完成。时限要落到具体的人，即当日分诊轮值人，而不是笼统的“测试团队”。超时提醒应指向轮值人和其备份，提醒内容包括缺陷编号和已等待时长。
退回提交人的条件应当明确列举：缺少复现步骤且无法推断、环境信息缺失导致无法判断、描述与截图不一致、疑似重复但未提供原缺陷编号。退回话术的要点是具体、可执行，例如“请补充复现步骤第 2 步之后的页面截图，以及发生时的浏览器版本”，避免“请补充详细信息”这类无法操作的表述。退回次数也应记录，同一缺陷被退回两次以上，分诊人应主动联系提交人当面确认。
分诊结论需要定期复核。可行做法是每周抽取一定比例的分诊记录，检查严重度与优先级是否符合判定表、主责人是否与映射表一致、退回理由是否成立。复核发现偏差时，记录调整前后的结论和调整原因，作为分级表的修订依据。当某类偏差反复出现，说明判定表本身需要补充示例或调整口径，而不是只纠正单条记录。
分诊结论要落到可追踪的工作项上。ONES Project 支持缺陷跟踪与质量统计，可一键提交 Bug 至对应的项目或迭代中，记录和跟踪缺陷修复情况；分诊人可以在缺陷工作项上完成有效性确认、严重度与优先级标注、指派主责人等动作，使分诊结论与后续处理在同一条记录上延续。ONES TestCase 支持未通过的用例快速创建缺陷任务，缺陷任务在测试与研发团队间流转，适合测试执行阶段发现的问题直接进入分诊。分诊记录中的状态分布也可以通过统计功能沉淀下来，用于复核时对照。
角色分工与各环节交付物
分诊涉及四类角色，职责边界和产出需要事先写清，避免出现“都以为对方在跟”的情况。
| 角色 | 职责 | 输入 | 输出 |
|---|---|---|---|
| 提交人 | 按模板提交缺陷，补充被退回的信息 | 发现的问题现象、环境、日志 | 字段完整的缺陷记录 |
| 分诊人 | 判定有效性、严重度、优先级，按映射表指派 | 缺陷记录、模块责任人映射表、分级表 | 分诊结论记录、指派动作 |
| 模块责任人 | 接收指派，确认归属，处理或转派并说明理由 | 分诊结论、缺陷详情 | 归属确认或转派说明、修复结果 |
| 裁决人 | 处理责任不清、分级争议的升级事项 | 争议缺陷、双方理由 | 裁决结论、映射表或分级表修订建议 |
分诊会议或轮值安排适用于两类场景：缺陷量大、分诊人需要集中处理时，可采用每日固定时段的分诊会，逐条过待分诊缺陷；跨团队协作复杂、模块边界模糊时，可安排轮值分诊人并配套裁决人值班。缺陷量小、模块清晰的团队，由固定分诊人按需处理即可，不必设置会议。无论哪种安排，都要保证分诊人在时限内可被找到。
一个完整分诊示例
以下为演示情景，用于说明各字段如何填写和判断。
原始描述：“下单后优惠券没有抵扣，金额不对。”提交人只填了标题和一张订单截图，环境、复现步骤均缺失。
补齐信息：分诊人退回并说明需要补充下单账号、优惠券类型、下单时间和订单号。提交人补充后确认：测试环境，版本 3.2.1，使用满减券，订单金额 200 元，应减 30 元，实际未减；复现概率为必现；影响范围为所有使用该类优惠券的订单。
判定过程：有效性成立，非重复缺陷，排除环境配置问题。严重度定为严重，因为优惠金额计算错误直接影响交易结果，且无绕行方案。优先级定为 P1，因为影响所有使用该类券的用户，当前迭代有营销活动上线，但已有临时方案可人工补差。责任归属按映射表归入订单服务，主责人为 A。
分诊结论记录：分诊人、分诊时间、有效性成立、严重度严重、优先级 P1、主责人 A、依据“金额计算错误且影响全部同类券订单，活动前需修复”。后续交接：A 确认归属后在缺陷记录中更新处理状态，修复完成后由提交人验证，验证结果回写同一条记录。
分诊机制上线前的完成检查
分诊机制是否具备运行条件，可以按以下清单逐项核对，全部满足后再扩大范围。
- 提交模板已包含复现步骤、环境与版本、影响范围、日志截图、发现阶段、复现概率等必填字段，并明确提交人与分诊人的补充分工。
- 严重度分级表和优先级判定表已发布，每级配有至少两个团队内真实缺陷作为示例，判定口径无歧义。
- 模块责任人映射表覆盖当前全部在维护模块，指定了维护人和更新触发条件，备份责任人已确认。
- 分诊响应时限、超时提醒对象、退回条件和退回话术模板已明确到具体角色。
- 复核机制已确定：复核频率、抽样比例、偏差记录方式和分级表修订流程。
- 裁决人和升级路径已指定，裁决时限已约定。
- 试运行范围已选定，例如一个项目或一个迭代，并确定观察指标：分诊平均耗时、退回率、分诊结论被调整的比例、责任争议升级次数。
试运行一到两个迭代后，对照观察指标评估机制是否有效。分诊耗时稳定在时限内、退回率下降、结论调整比例处于低位，说明分级表和映射表基本可用；若某类偏差集中出现，优先修订对应的判定表或映射规则，再进入全量运行。
常见问题
缺陷分诊和缺陷评审会议是一回事吗？
两者目标不同。分诊是对每条新缺陷做出受理判断，产出有效性、严重度、优先级、责任归属四个结论，通常由分诊人按规则逐条处理。评审会议更多用于争议缺陷的集体讨论，例如分级口径不一致、责任归属有分歧。把常规分诊都放进会议，会拉长响应时间；可行的做法是常规缺陷按规则直接分诊，只把争议项提交会议或裁决人处理。
团队规模小、模块划分不清晰时，还需要维护模块责任人映射表吗？
需要，但可以简化。小团队可以按功能域而非系统模块建表，一人可兼多个模块的主责，备份责任人可以互相担任。关键是每条缺陷有且只有一个主责人，并且表有明确的维护人和更新触发条件。模块边界模糊时，跨模块判定规则和裁决人尤其重要，否则容易出现缺陷在几个人之间来回转派。
生产环境发现的紧急缺陷，信息不全也要先分诊吗？
可以先行受理，但要在分诊记录中标注“信息待补”，并明确补齐责任人和补齐时限，在修复完成前把复现步骤、环境版本、影响范围补全。这样既保证紧急问题不被流程卡住，也避免修复后无法验证或无法沉淀分析依据。非生产环境的缺陷建议按常规退回规则处理，先补齐再分诊。
分诊结论被判错了，应该改结论还是改分级表？
先看偏差是个案还是模式。单条记录判错，按复核流程调整结论并记录调整原因即可。如果同类偏差反复出现，例如多条缺陷的优先级都被上调，说明判定表的口径或示例不足，应修订分级表并补充团队内真实案例。复核记录的价值就在这里：它既是纠错依据，也是分级表迭代的输入。
分诊结论如何落到工具里并保持可追溯？
把分诊结论写进缺陷工作项本身，包括严重度、优先级、主责人和一句判断依据，指派动作也在同一条记录上完成，后续修复、验证、关闭都延续这条记录。ONES Project 支持缺陷跟踪与质量统计，可一键提交 Bug 至对应的项目或迭代中，记录和跟踪缺陷修复情况；ONES TestCase 支持未通过的用例快速创建缺陷任务，适合测试执行阶段发现的问题直接进入分诊。具体字段配置与指派方式需按团队实际部署环境确认。
