缺陷分诊记录要保留四类信息：缺陷标识与来源、受理判断依据、分诊结论与责任归属、后续跟踪所需的变更痕迹。记录的目标是让未参与分诊的人也能还原“为什么这样定级、为什么派给这个人、下一步谁在什么时间做什么”。本文给出字段清单、逐项填写方法、角色分工、完整示例和合格检查表，适用于缺陷受理决策环节。
要点总览（TL;DR）
- 缺陷分诊记录按四组信息组织：缺陷标识与来源、受理判断依据、分诊结论与责任归属、跟踪痕迹；缺一组就难以复核。
- 影响定级、定责和时限的字段设为必填，包括缺陷编号与标题、环境版本、复现步骤与影响范围、严重度与优先级及理由、分诊人与时间、责任模块与责任人、结论及理由；协办人、计划修复版本、关联项按条件填写。
- 提交者提供可复现信息，分诊人负责定级定责与结论记录，模块负责人确认接收或提出异议，记录维护方检查完整性并督促补充；转派、重新定级、时限调整以追加方式留痕，不覆盖历史结论。
- 分诊完成时按检查表逐项核对，信息不完整、无法复现、定级理由缺失、责任人不明、结论无理由或变更未留痕均属阻断项，退回补充后再进入修复排期。
分诊记录先回答哪四个问题
分诊记录按四组信息组织，每组回答一个具体问题。字段数量可以随团队规模调整，四组信息缺一组，记录就难以被复核。
| 信息组 | 回答的问题 | 典型字段 | 填写要求 |
|---|---|---|---|
| 缺陷标识与来源 | 这是哪个缺陷，从哪里来，在什么环境出现 | 缺陷编号、标题、来源渠道、发现环境与版本、提交人、提交时间 | 必填 |
| 受理判断依据 | 凭什么判断它严重、紧急、需要修复 | 复现步骤、实际结果、期望结果、影响范围、严重度、优先级及判定理由 | 必填 |
| 分诊结论与责任归属 | 受理还是驳回，由谁负责，何时修复 | 分诊结论、结论理由、责任模块、责任人、协办人、分诊人、分诊时间、计划修复版本与时限 | 结论、理由、责任人、分诊人及时间为必填；协办人、计划修复版本按条件填写 |
| 跟踪痕迹 | 分诊之后发生了什么变化 | 关联需求或缺陷、状态变更记录、转派记录、补充信息记录 | 状态与责任变更必留痕；关联项按条件填写 |
必填与条件填写的划分依据是“缺少后是否影响复核”。影响定级、定责和时限判断的字段设为必填；只在特定情形下才存在的字段，如多人协作时的协办人、已排期后的计划修复版本，按条件填写。团队可以在项目配置中把必填项设为提交或流转的校验条件，减少事后补录。
逐字段填写：从缺陷标识到责任归属
下表把四组框架落到具体字段，每个字段说明输入来源、填写动作和合格标准。填写时以“他人能否据此复核”为尺度，不以字数多少为标准。
| 字段 | 输入来源 | 填写动作 | 合格标准 |
|---|---|---|---|
| 缺陷编号 | 系统生成 | 提交时自动生成，不在标题或正文中手工改写 | 唯一、可检索，与其他记录引用时保持一致 |
| 标题 | 提交者 | 用“模块＋现象＋条件”概括，如“订单页提交后金额显示为0（使用优惠券时）” | 不看正文也能判断大致问题，避免“有问题”“报错”一类标题 |
| 来源渠道 | 提交者或系统 | 标注来自测试执行、用户反馈、线上监控、内部试用等 | 能区分问题发现场景，便于判断影响面 |
| 发现环境与版本 | 提交者 | 写明环境类型（开发、测试、预发、生产）、应用版本、必要的设备与浏览器信息 | 他人可按同样条件复现；生产问题注明影响版本范围 |
| 复现步骤 | 提交者 | 按操作顺序编号，每步写清操作对象和输入数据 | 按步骤操作能得到相同结果；偶现问题注明出现频率和尝试次数 |
| 实际结果与期望结果 | 提交者 | 分别描述观察到什么、按需求应是什么 | 两者形成明确差异，期望结果有需求或设计依据 |
| 影响范围 | 提交者与分诊人共同补充 | 写明受影响的功能、用户群体、数据范围，以及是否有临时规避方案 | 能支撑严重度判断，如“全部新用户无法完成注册，无规避方案” |
| 严重度 | 分诊人 | 按团队定义选择等级，并在记录中写明判定理由 | 理由包含影响用户范围、是否阻断主流程、有无规避方案等具体事实 |
| 优先级 | 分诊人，必要时与模块负责人协商 | 结合严重度、业务节点、修复成本确定，并写明依据 | 能解释为何与严重度一致或不同，如“严重度高但已有规避方案，优先级降为中” |
| 责任模块 | 分诊人 | 定位到具体功能模块或服务，不停留在“前端”“后端”层面 | 模块划分与团队代码或服务归属一致 |
| 责任人 | 分诊人指定或模块负责人指派 | 填写具体人员，并确认其已知晓 | 责任人为实际处理人，非仅挂名；接收动作有记录 |
| 协办人 | 分诊人或责任人 | 涉及跨模块协作时填写，注明协作内容 | 协办事项具体，如“提供接口日志”“确认数据口径” |
| 分诊人与分诊时间 | 分诊人 | 完成定级定责后填写，时间精确到日 | 可与提交时间区分，便于统计分诊时效 |
| 分诊结论及理由 | 分诊人 | 从受理、驳回、转派、待补充信息中选择，并写明理由 | 理由指向具体依据；驳回与待补充信息须写明下一步由谁在何时处理 |
| 计划修复版本与时限 | 分诊人或模块负责人 | 排期确定后填写版本号与目标日期 | 与迭代计划一致；未排期时注明“待排期”及预计排期时间 |
| 关联需求或缺陷 | 分诊人或提交者 | 关联对应需求、测试用例或重复缺陷 | 重复缺陷指向主缺陷编号，避免多头跟踪 |
结论写法上，四类结论各有要求。受理需写明定级与责任人；驳回需说明不属于缺陷、无法复现或重复的具体理由；转派需记录转出与转入的模块和人员；待补充信息需列出缺什么信息、由谁补充、截止时间。只写“已处理”“转研发”这类结论，无法支撑后续复核。
角色分工：谁填、谁确认、谁维护
分诊记录的质量取决于提交、分诊、接收三个环节的交接是否清楚。每个角色对记录承担不同责任，交接点要有明确的完成标志。
| 角色 | 关键动作 | 交付物 | 完成标志 |
|---|---|---|---|
| 提交者 | 提供可复现的步骤、实际与期望结果、环境版本和影响线索 | 信息完整的缺陷提交 | 他人按步骤可复现，或已注明偶现频率 |
| 分诊人 | 核实信息、判定严重度与优先级、定位责任模块、指定责任人、记录结论与理由 | 分诊结论与定级定责记录 | 结论、理由、责任人、分诊时间均已填写 |
| 模块负责人 | 确认接收或提出异议，安排修复版本与时限 | 接收确认或异议说明 | 接收动作有记录；异议时给出重新分诊的依据 |
| 责任人 | 处理缺陷，更新状态与修复信息 | 修复记录与状态更新 | 状态变更与修复说明可追溯 |
| 记录维护方（通常为测试或质量角色） | 检查字段完整性，督促补充信息，维护变更留痕规则 | 定期检查结果与补录记录 | 检查发现的问题有跟进闭环 |
变更留痕的责任归属需要事先约定：谁修改谁追加，历史结论不覆盖。转派、重新定级、时限调整都以追加记录的方式写入同一条缺陷，保留原结论和调整理由。这样在复盘分诊质量时，能看到判断变化的过程，而不只是最终状态。
当团队使用 ONES 承载缺陷流程时，分诊记录可以落在缺陷工作项的字段、责任人和状态流转上。ONES Project 支持缺陷跟踪管理，与 TestCase 数据互通并可一键提 Bug，支持一键提交 Bug 至对应项目或迭代中记录和跟踪修复情况；ONES TestCase 支持未通过的用例快速创建缺陷任务，使缺陷在测试与研发团队间流转。分诊所需的字段配置需按团队流程在项目中自定义，具体可配置范围以实际版本为准。
一条完整的分诊记录示例
以下为演示情景，用于说明字段如何组合，非真实案例。
背景与原始提交：测试人员在预发环境执行“优惠券下单”用例时发现，使用满减券提交订单后，订单金额显示为原价。缺陷标题为“订单确认页使用满减券后金额未扣减（预发环境）”，来源渠道为测试执行，发现环境为预发环境、应用版本 V3.2.0，复现步骤为：登录测试账号→加入两件商品→选择满100减20券→提交订单→查看订单确认页金额。实际结果为显示原价180元，期望结果为160元。提交者注明该问题在近三次执行中均出现。
分诊判断过程：分诊人核实复现步骤后确认问题稳定出现，影响范围为所有使用满减券的订单，主流程可继续提交但金额错误，存在资损风险，暂无规避方案。据此定为严重度高；结合本周有营销活动上线，优先级定为高。判定理由写入记录：影响全部用券订单、涉及金额准确性、无临时规避方案、临近活动节点。
责任分配与计划：责任模块定为“订单计价服务”，责任人指定为该模块开发人员，协办人为优惠券服务接口负责人，协作内容为确认券金额计算口径。分诊结论为受理，计划修复版本 V3.2.1，时限为活动上线前两个工作日。关联需求为“满减券营销活动”，关联测试用例为“优惠券下单校验”。
后续变更追加：次日优惠券服务确认口径无误，协办人记录追加“券面金额计算正确，问题在订单侧汇总逻辑”。责任人将状态更新为修复中，并追加修复说明。修复完成后追加验证结果与关闭记录。原分诊结论、定级理由和时限均保留，调整时限时另起一条追加记录说明原因。
完成检查：分诊记录是否合格
分诊完成时按下表逐项核对。任一阻断项不通过，记录退回补充，不进入修复排期。
| 检查类别 | 检查项 | 是否阻断 |
|---|---|---|
| 信息完整性 | 缺陷编号、标题、来源渠道、发现环境与版本齐全 | 是 |
| 信息完整性 | 复现步骤、实际结果、期望结果、影响范围可支撑判断 | 是 |
| 判断依据可复核 | 严重度与优先级均有判定理由，理由含具体事实 | 是 |
| 判断依据可复核 | 他人按记录可复现问题，或偶现频率已注明 | 是 |
| 责任与时限 | 责任模块与责任人明确，责任人已确认接收 | 是 |
| 责任与时限 | 分诊人与分诊时间已填写 | 是 |
| 责任与时限 | 计划修复版本与时限明确，或注明待排期及预计排期时间 | 否，但需有跟进记录 |
| 结论规范 | 结论属于受理、驳回、转派、待补充信息之一，并附理由 | 是 |
| 结论规范 | 驳回与待补充信息写明下一步由谁在何时处理 | 是 |
| 变更留痕 | 转派、重新定级、时限调整以追加方式记录，历史结论未被覆盖 | 是 |
| 变更留痕 | 重复缺陷已关联主缺陷编号 | 否，但需在关闭前补齐 |
不通过时的处理方式按阻断程度区分：信息不完整或无法复现的，退回提交者补充，记录保持“待补充信息”状态并注明截止时间；定级理由缺失或责任人不明的，退回分诊人重新判断；责任人提出异议的，由模块负责人组织重新分诊，原结论保留并追加新结论。检查结果本身也建议留一条记录，便于统计分诊返工情况，持续改进字段规范。
常见问题
缺陷提交时信息不全，分诊人可以先定级再让提交者补充吗？
可以，但记录要体现这个顺序。分诊人先按现有信息给出初步判断时，结论应记为“待补充信息”，写明缺哪些信息、由谁补充、截止时间，并保留初步定级及其依据。补充完成后追加正式结论，原记录不覆盖。若缺失的是复现步骤或环境版本这类直接影响判断的信息，建议先退回补充，避免基于不完整信息定责。
严重度和优先级由分诊人定，模块负责人有不同意见怎么办？
由模块负责人提出异议并给出依据，分诊人组织重新分诊，原结论保留，新结论以追加方式写入同一条记录。异议理由应指向具体事实，例如影响范围判断不同、已有规避方案、修复成本与排期冲突。重新分诊后同步更新责任人和计划修复版本，避免记录里同时存在两套有效结论。
驳回的缺陷还需要保留完整分诊记录吗？
需要。驳回同样是一次受理决策，记录应包含驳回理由（不属于缺陷、无法复现、重复等）、判断依据和下一步安排。无法复现的注明尝试次数与环境；重复的关联主缺陷编号；不属于缺陷的说明应转往何处。缺少这些信息，后续同类问题再次提交时无法判断是否已处理过。
分诊记录里的变更痕迹要记到什么程度？
以“能看出判断变化的过程”为准。转派记录转出与转入的模块和人员，重新定级记录新等级与调整理由，时限调整记录原时限、新时限和原因。每次变更以追加方式写入，保留原结论和时间。只保留最终状态、不保留调整过程的记录，在复盘分诊质量时无法区分判断失误与情况变化。
团队用工具承载分诊记录时，字段配置要注意什么？
把必填字段设为提交或流转的校验条件，减少事后补录；分诊人、分诊时间、结论理由这类字段单独配置，便于统计分诊时效和返工情况。使用 ONES 时，分诊记录可以落在缺陷工作项的字段、责任人和状态流转上，ONES Project 支持缺陷跟踪管理，与 TestCase 数据互通并可一键提 Bug；具体字段配置需按团队流程在项目中自定义，可配置范围以实际版本为准。
