缺陷分诊记录把“这条缺陷谁来处理、多急、走哪条路”的受理决策固定在一张表里，避免口头分派后无从追溯。本文提供可直接复制的空白表、逐字段填写口径、必填与选填划分，并用一条完整记录示范填写方式，适用于测试、开发和产品共同参与缺陷受理的团队。
要点总览（TL;DR）
- 缺陷分诊记录以“一条缺陷一行”为单位，固定记录受理决策：缺陷基本信息、复现与影响、分诊判定、结论与流转四类字段。
- 必填项围绕可追溯与可承接设置：记录编号、缺陷标题、发现来源与环境、复现步骤、实际与期望结果、严重程度、优先级、责任模块与责任人、处理去向与分诊时间。
- 线上反馈或监控来源的缺陷，建议把发现时间、影响范围、复现概率一并作为必填，以支撑是否立即介入的判断。
- 填写时严重程度描述损害、优先级描述处理顺序，两者出现偏离时在分诊结论中写明理由。
- 模板维护以真实分诊判断为准：新增字段需对应反复出现的口头追问，口径变更保留旧记录原口径，并定期抽取记录复核。
可复制空白缺陷分诊记录表
缺陷分诊记录以“一条缺陷一行”为基本单位。下表为单条记录表，适合在文档中逐条登记，也适合作为缺陷管理工具中自定义表单的字段蓝本。复制时保留表头，按行填写即可。
| 字段 | 填写内容 |
|---|---|
| 记录编号 | |
| 缺陷标题 | |
| 发现来源 | |
| 发现环境 | |
| 发现时间 | |
| 提交人 | |
| 复现步骤 | |
| 实际结果 | |
| 期望结果 | |
| 复现概率 | |
| 影响范围 | |
| 严重程度 | |
| 优先级 | |
| 责任模块 | |
| 责任人 | |
| 处理去向 | |
| 分诊结论 | |
| 分诊人 | |
| 分诊时间 | |
| 备注 |
当一次分诊需要处理多条缺陷时，可改用批量登记表：每行一条缺陷，列名与上表一致，仅保留分诊环节高频使用的字段，如记录编号、缺陷标题、严重程度、优先级、责任模块、责任人、处理去向、分诊结论、分诊时间。批量表适合分诊会议现场逐条过缺陷，单条记录表适合对复杂缺陷补充复现与影响细节。两种用法共用同一套字段口径，区别只在记录粒度。
每个字段记录什么：分诊字段说明
字段口径统一，不同分诊人对同一条缺陷才能做出可比对的判断。下表按四类分组说明各字段的含义与填写要求。
| 分组 | 字段 | 含义 | 填写口径 |
|---|---|---|---|
| 缺陷基本信息 | 记录编号 | 本条分诊记录的唯一标识 | 沿用缺陷单号或按团队规则生成，保证可回查 |
| 缺陷标题 | 一句话概括缺陷现象 | 写“在什么场景下出现什么异常”，避免只写“有问题” | |
| 发现来源 | 缺陷被发现的渠道 | 如功能测试、回归测试、用户反馈、线上监控 | |
| 发现环境 | 缺陷出现的环境 | 写清环境类型与关键配置，如测试环境、预发布环境、某版本客户端 | |
| 发现时间 | 缺陷首次被记录的时间 | 精确到日期，紧急缺陷可精确到时分 | |
| 提交人 | 录入缺陷的人 | 填写真实姓名或团队内唯一标识 | |
| 复现与影响 | 复现步骤 | 触发缺陷的操作序列 | 按顺序编号，写清前置条件和关键输入 |
| 实际结果 | 系统实际表现 | 客观描述现象，可附报错信息或截图位置 | |
| 期望结果 | 按需求或设计应有的表现 | 引用需求条目或设计说明，便于判断是否为缺陷 | |
| 复现概率 | 按步骤操作时缺陷出现的频率 | 用“必现、高频、偶现、仅一次”等固定档位描述 | |
| 影响范围 | 缺陷波及的用户、功能或数据 | 写清受影响的功能模块、用户群体或数据范围 | |
| 分诊判定 | 严重程度 | 缺陷对业务造成的损害程度 | 按团队定义的档位填写，依据影响范围而非主观感受 |
| 优先级 | 修复的紧急与排序 | 结合严重程度、影响用户量和发布计划确定 | |
| 责任模块 | 缺陷所属的功能或技术模块 | 按产品模块划分填写，便于定位承接团队 | |
| 责任人 | 承接处理的个人 | 填写具体人员，避免只写团队名称 | |
| 结论与流转 | 处理去向 | 分诊后缺陷进入的处理路径 | 如进入修复、转需求评估、判定非缺陷关闭、待补充信息 |
| 分诊结论 | 分诊人对本条缺陷的判定说明 | 简述判定理由，尤其是严重程度与优先级偏离直觉时 | |
| 分诊人 | 做出分诊判定的人 | 填写实际参与判定的人员 | |
| 分诊时间 | 分诊结论形成的时间 | 精确到日期，用于衡量受理时效 | |
| 补充 | 备注 | 其他需要说明的信息 | 记录依赖项、待确认问题或关联缺陷编号 |
严重程度与优先级是两个独立判断：严重程度描述损害，优先级描述处理顺序。一条影响面广但已有规避方案的缺陷，严重程度可以高、优先级可以适度下调，这类偏离应在分诊结论中写明理由。
必填与选填：哪些字段不能空
必填项的作用是保证每条分诊记录都能回答“这是什么缺陷、谁来处理、多急、结论是什么”。下表给出建议划分，团队可结合缺陷来源和紧急程度调整。
| 类别 | 字段 | 缺失后果 |
|---|---|---|
| 必填 | 记录编号 | 无法回查原始缺陷，分诊记录失去索引价值 |
| 缺陷标题 | 分诊会议无法快速识别缺陷内容 | |
| 发现来源 | 难以判断缺陷的可信度与影响面 | |
| 发现环境 | 责任人无法复现，修复验证缺少基准 | |
| 复现步骤 | 缺陷可能被误判为不可复现而搁置 | |
| 实际结果与期望结果 | 无法判断是否构成缺陷 | |
| 严重程度 | 无法排序处理，紧急缺陷可能被延后 | |
| 优先级 | 修复顺序缺少依据 | |
| 责任模块与责任人 | 缺陷无人承接，分诊决策落空 | |
| 处理去向与分诊时间 | 无法追踪受理结果与时效 | |
| 选填 | 发现时间 | 常规缺陷可按提交时间推定；线上缺陷建议填写 |
| 提交人 | 由系统记录提交者时可省略；线下登记建议填写 | |
| 复现概率 | 必现缺陷可省略；偶现缺陷应填写以支持定位 | |
| 影响范围 | 影响面明确的缺陷可省略；涉及多模块或用户数据时应填写 | |
| 分诊结论与备注 | 判定无争议时可简写；存在偏离常规判断或依赖项时应填写 |
按来源调整必填项是常见做法：线上监控或用户反馈产生的缺陷，发现时间、影响范围、复现概率应视为必填，因为这些信息决定是否立即介入；内部测试发现的低风险缺陷，可放宽对影响范围的要求。按紧急程度调整时，紧急缺陷应额外要求填写分诊结论，说明为何升级处理。调整规则应写入模板说明，避免不同分诊人各自执行。
填写示例：一条缺陷从受理到分诊结论
以下示例为演示情景，展示各字段如何协同表达一次完整的分诊决策。
| 字段 | 示例内容 |
|---|---|
| 记录编号 | BUG-2041 |
| 缺陷标题 | 订单列表页在筛选“待发货”后翻页，第二页显示全部订单 |
| 发现来源 | 回归测试 |
| 发现环境 | 预发布环境，Web 端，测试账号含 200 条以上订单 |
| 发现时间 | 2025-03-11 |
| 提交人 | 测试-李敏 |
| 复现步骤 | 1. 登录测试账号；2. 进入订单列表页；3. 筛选条件选择“待发货”；4. 点击翻至第二页 |
| 实际结果 | 第二页展示全部状态的订单，筛选条件失效 |
| 期望结果 | 翻页后仍只展示“待发货”订单，与需求“筛选条件在分页间保持”一致 |
| 复现概率 | 必现 |
| 影响范围 | 订单量超过一页的商家账号，影响订单处理效率 |
| 严重程度 | 高 |
| 优先级 | 高 |
| 责任模块 | 订单列表 |
| 责任人 | 开发-王磊 |
| 处理去向 | 进入修复 |
| 分诊结论 | 筛选条件未随分页参数传递，属功能缺陷；影响商家日常处理，按高优先级排入当前迭代 |
| 分诊人 | 产品-陈卓 |
| 分诊时间 | 2025-03-11 |
| 备注 | 与 BUG-2038 同属订单列表筛选问题，修复时一并核查 |
关键取值理由：严重程度定为高，依据是影响范围覆盖订单量较大的商家账号，而非缺陷出现频率；优先级同样定为高，因为该问题直接妨碍商家处理待发货订单，且当前迭代有修复窗口。责任模块写“订单列表”而非笼统的“订单系统”，是为了让责任人明确。处理去向写“进入修复”，与分诊结论中的排期说明相互对应。备注关联了同类缺陷，便于修复时合并排查。
分诊结论形成后，需要把结论落到责任人可执行的工作项上。ONES Project 支持缺陷管理场景，可一键提交 Bug 至对应项目或迭代，记录和跟踪缺陷修复情况；分诊字段可作为缺陷工作项的属性承载，责任人据此承接处理。若团队用文档维护分诊规范，ONES Wiki 支持文档关联任务，并支持插入 ONES Project 的工作项列表，便于把模板说明与在办缺陷放在同一处对照。
模板的调整与维护方法
模板用久了会出现字段冗余或口径模糊，维护的目标是让字段始终对应真实的分诊判断，而非不断加列。以下规则可作为团队维护清单。
- 新增字段的判断依据：当分诊会议上反复出现同一类口头追问，且该信息影响责任人或优先级判断时，才新增字段。仅“可能有用”的信息放入备注，不单独设列。
- 合并字段的判断依据：当两个字段长期由同一人同时填写、且取值高度相关时，可合并为一个字段并在口径中说明。合并前先统计一段时间内的填写记录，确认没有单独使用的情况。
- 字段口径变更的记录方式：每次修改字段含义或取值档位，在模板说明中记录变更日期、变更内容和影响范围，旧记录保留原口径，不追溯改写，避免历史数据失真。
- 定期复核的触发条件：出现以下情况时启动复核：连续一个季度出现必填项缺失导致的返工；分诊结论中频繁出现“无法判断”类表述；产品模块划分调整导致责任模块失效；团队引入新的缺陷来源渠道。
- 复核的执行方式：抽取近期若干条分诊记录，检查每个字段是否被实际使用、是否存在长期为空的必填项、是否有信息只能写在备注里。据此决定增、删、合并或调整必填划分，并同步更新填写示例。
模板调整后应同步更新字段说明、必填划分和示例三处内容，保持三者一致。状态流转规则与根因分析分别属于缺陷生命周期管理和缺陷分析与预防的范围，不在本模板内展开，需要时另行建立对应规范。
常见问题
分诊会议上临时口头补充的信息，需要回填到记录里吗？
需要。分诊会议中形成的判断，例如为什么把优先级从高下调为中、为什么转给另一个模块，应当回填到分诊结论或备注中。口头结论不留痕，后续责任人接手时只能凭记忆还原，容易产生分歧。回填时写清判断依据和参与人，不必追求完整叙述。
同一条缺陷被多次分诊，记录应该新增一行还是修改原记录？
建议新增一条分诊记录并保留原记录。缺陷在补充信息后重新判定严重程度或改派责任人，属于新的受理决策，新增记录能保留判断变化的过程。原记录保持不变，新记录在备注中注明关联的原记录编号，便于对照两次判定的差异。
团队规模较小、分诊由一人完成时，还需要保留分诊人和分诊时间字段吗？
建议保留。分诊人字段在单人分诊时取值固定，但分诊时间仍用于衡量受理时效，也便于日后回溯某条缺陷何时被判定。人员变动后，历史记录中的分诊人信息能帮助新成员找到当时的判断者。若确实希望精简，可把分诊人与提交人合并理解，但不宜删除时间字段。
分诊结论落到工作项后，表格里的记录还需要继续维护吗？
表格记录的作用是保留受理决策本身，工作项承载的是后续修复过程。分诊结论转入工作项后，表格中的记录可以不再更新修复进展，但应保留原始判定内容，供后续复盘时对照。若团队使用 ONES Project 管理缺陷，可将分诊字段作为缺陷工作项属性承载，责任人据此承接处理。
缺陷被判定为非缺陷或转需求评估时，分诊记录怎么填？
处理去向字段填写实际路径，如“判定非缺陷关闭”或“转需求评估”，分诊结论中写明判定理由，例如与需求描述一致、属于设计预期范围。这类记录同样需要保留记录编号和分诊时间，因为它们是后续同类问题判断的参考，也能避免同一现象被反复提交。
