Bug Triage（缺陷分诊）是对新报告的缺陷进行确认、定级、指派的流程，目的是让有限的开发资源优先修复影响最大的问题。 一个高效的分诊流程要保证两件事：每条缺陷在固定时间内被看过，以及看过一次就定好去向（修复、排期、降级或关闭）。
为什么需要分诊
没有分诊机制的团队，缺陷处理通常呈现两种病态：- 挤兑式：谁嗓门大谁的问题先被修，P0 和 P2 排在同一个队列里；
- 黑洞式：缺陷散落在群聊、邮件、口头反馈里，相当一部分从来没被任何人「决定过」。
分诊的角色分工
| 角色 | 职责 |
|---|---|
| 分诊主持人（通常 QA Lead / 测试负责人） | 组织分诊会议、维护队列清零、推动决策 |
| QA / 测试 | 确认可复现性、补充复现步骤、初步定级 |
| 开发负责人 | 评估技术影响面、估修复成本、认领指派 |
| 产品负责人（PM/PO） | 从业务角度定优先级、裁决「修不修」的分歧 |
标准分诊流程（5 步）
1. 接入与去重
所有渠道（内部测试、Beta 用户、线上反馈）的报告进入同一个台账，按「模块 + 现象」查重后合并。分散的入口是分诊失效的根源——群聊里报的 Bug 和工具里报的 Bug 必须汇到一张表。2. 确认（Validate）
- 是否可复现？按报告中的步骤走一遍；
- 复现不了：标注环境信息待查，退回报告人补充——报告自带环境上下文的团队在这里几乎不卡壳（见下文）；
- 不是缺陷（预期行为/使用问题）：转为咨询或文档改进项，关闭并告知报告人。
3. 定级（Severity × Priority）
严重级（Severity，技术视角）和优先级（Priority，业务视角）是两个维度，不要混用：| 高优先级（Priority） | 低优先级 | |
|---|---|---|
| 高严重级 | 立即修（首页白屏） | 本迭代修（长尾功能崩溃，无绕行方案但用户极少到达） |
| 低严重级 | 尽快修（登录按钮错位，影响所有用户） | 排进 Backlog（角落文案错别字） |
4. 指派与排期
- P0：当天热修或回滚，通知所有相关人；
- P1：排入当前迭代（占用计划会预留的 20% 缓冲，见 Sprint Planning 指南）；
- P2/P3：进 Product Backlog，按常规排序。
5. 回传与关闭
修复后：通知报告人（尤其外部测试者）复测 → 验证通过 → 关闭并记录根因分类（供回顾会统计）。外部报告人的状态回传直接决定其后续报告意愿。分诊会议怎么开
- 频率：迭代节奏快的团队每天一次，15~30 分钟，只处理新增队列；频率低的每周 2~3 次；
- 形式：过台账看板，一条 3~5 分钟，超过 5 分钟定不下来的挂「待定」下班前单聊；
- 纪律：会议只做决策，不做技术方案讨论；只过新增，不复查已定级的。
高效分诊的前提：报告自带上下文
分诊会议最浪费时间的一幕：QA 念一条报告——「用户说点按钮没反应」——然后全场追问：哪个页面？哪个浏览器？Console 有报错吗？能不能再点一次？一条本该 2 分钟定级的报告被拖成 15 分钟的侦探剧。 根源在于报告缺上下文。对比一下：| 信息项 | 手动报告（用户凭记忆描述） | 自动采集的报告 |
|---|---|---|
| 复现步骤 | 「我点了那个按钮就没反应了」 | 标注截图/录屏指认位置与操作 |
| 页面 URL | 经常缺失或口述出错 | 自动附带 |
| 浏览器/设备 | 通常缺失 | 自动附带 |
| Console / Network 报错 | 几乎不可能有 | 自动附带 ERROR 堆栈与失败请求 |
分诊质量的自检指标
| 指标 | 健康值 | 说明 |
|---|---|---|
| 报告首次响应时间 | < 24h | 从提交到被分诊决策 |
| 「待定」积压 | < 5% | 长期待定说明定级标准不清 |
| 重复报告率 | 下降趋势 | 台账与查重机制有效 |
| P0 数量 | 下降趋势 | 持续偏高说明上游质量活动不足 |
| 报告人复测反馈率 | 高 | 外部测试者满意度与留存 |