缺陷修复进度跟踪的依据由四类信息构成：缺陷本身的完整记录、修复过程的状态与责任人记录、验证环节的证据，以及时间与变更记录。跟踪时以缺陷单为唯一载体，把“谁在什么时间做了什么、依据什么判断”沉淀为可查记录，进度判断才不依赖口头同步。本文覆盖从缺陷提交到验证关闭的环节，给出字段表、操作步骤、角色分工与完成检查。
要点总览（TL;DR）
- 缺陷修复进度跟踪的依据分四类：缺陷本身的完整记录、修复过程的状态与责任人记录、验证环节的证据、时间与变更记录，全部沉淀在同一张缺陷单上。
- 字段设计以“可复现、可追溯、可判断”为标准，优先保证复现步骤、严重度、责任人、修复说明、修复版本、验证结论与验证人稳定填写。
- 流程按提交与受理、修复中、待验证、验证与关闭四阶段推进，状态变更与时间记录同步发生，重开必须写明未通过现象。
- 提交人/测试、开发、缺陷管理或质量角色各有交付物与交接时点，角色可兼任但职责不能空缺。
- 机制有效性靠抽样检查与例会核对四类信号：超期未受理、修复中停留过久、待验证积压、重开次数异常。
跟踪缺陷修复进度，先明确要回答的四个问题
“进度”是一个容易含糊的词。说某个缺陷“在跟进”，可能指刚收到报告、正在定位、已经改完等不同状态。要让跟踪有依据，先把进度拆成四个可以用记录回答的问题，再为每个问题准备最小依据。
| 要回答的问题 | 最小依据 | 依据缺失时的判断偏差 |
|---|---|---|
| 是否已受理 | 受理时间、受理人、严重度定级、指派对象 | 缺陷停留在“新建”却无人认领，被误认为已在处理 |
| 是否在修 | 当前状态、责任人、最近一次状态变更时间 | 状态长期停在“修复中”，无法区分在推进还是被搁置 |
| 修到什么程度 | 修复说明、修复版本、关联提交或变更记录 | 只知道“改了”，不知道改了什么、影响哪些范围，验证无从下手 |
| 是否验证通过 | 验证环境、验证用例、验证结论、验证人、验证时间 | 以开发口头确认代替验证，缺陷关闭后问题复现 |
四个问题对应四类依据：缺陷记录本身、修复过程记录、验证证据、时间与变更记录。它们共同回答“这个缺陷现在处于什么位置、下一步该谁做什么”。缺少任何一类，进度判断就会退回到询问和记忆，跟踪例会也容易变成逐条口头确认。
缺陷单需要记录哪些字段作为跟踪依据
字段设计的目标是让一条缺陷单能独立支撑判断：他人看单子就能复现问题、了解修复内容、核对验证结论。下表按四类依据组织，团队可据此对照现有缺陷模板补齐缺项。
| 类别 | 字段 | 在跟踪中的作用 | 填写要求 | 主要责任人 |
|---|---|---|---|---|
| 基本信息 | 标题 | 快速识别问题，便于检索与归类 | 一句话描述现象与位置，避免“页面报错”这类笼统表述 | 提交人 |
| 基本信息 | 复现步骤 | 判断缺陷是否可复现，是受理的前提 | 按操作顺序写清前置条件、操作、实际结果与预期结果 | 提交人 |
| 基本信息 | 环境 | 区分问题出在哪个版本、哪套配置 | 记录版本号、部署环境、必要的数据或账号条件 | 提交人 |
| 基本信息 | 严重度 | 决定处理优先级与排期顺序 | 按团队约定的分级标准定级，受理时由责任人复核 | 提交人初判，受理人确认 |
| 基本信息 | 影响版本与影响范围 | 判断是否需要补丁、是否波及已发布功能 | 写明受影响版本与功能模块，范围不清时标注待确认 | 提交人，开发补充 |
| 修复信息 | 责任人 | 明确当前由谁推进 | 指派到具体人，转派时更新并说明原因 | 受理人 |
| 修复信息 | 修复说明 | 说明改了什么、为什么这样改 | 描述根因与修改内容，避免只写“已修复” | 开发 |
| 修复信息 | 修复版本 | 确定验证对象 | 填写包含修复的构建或版本号 | 开发 |
| 修复信息 | 关联提交或变更 | 建立缺陷与代码变更的可追溯关系 | 关联对应的提交、合并请求或变更单 | 开发 |
| 验证信息 | 验证环境 | 确认验证结论的适用范围 | 记录验证所用版本与环境，与修复版本对应 | 验证人 |
| 验证信息 | 验证用例 | 说明依据什么场景判断通过 | 引用原复现步骤或关联的测试用例，覆盖边界情况 | 验证人 |
| 验证信息 | 验证结论与验证人 | 作为关闭缺陷的直接证据 | 写明通过或未通过及判断依据，署名到人 | 验证人 |
| 时间信息 | 提交、受理、修复完成、验证时间 | 计算各环节停留时长，识别积压 | 由状态流转自动记录，减少手工填写 | 系统记录 |
| 时间信息 | 重开次数与重开原因 | 识别修复质量与沟通问题 | 每次重开写明未通过的具体现象 | 验证人 |
字段并非越多越好。每增加一个必填项，都要有人负责填写并在评审中使用它，否则会变成形式化记录。建议先保证复现步骤、严重度、责任人、修复说明、修复版本、验证结论、验证人这几项稳定填写，再按项目需要扩展。
从提交到验证的操作步骤
字段解决“记什么”，流程解决“什么时候记、由谁推进”。以下按四个阶段给出输入、动作、输出与完成标志，团队可据此约定状态流转规则。
提交与受理
- 输入：发现的问题现象、复现环境。
- 动作：提交人填写基本信息并尝试复现；受理人确认可复现性、复核严重度、指派责任人，必要时退回补充信息。
- 输出：字段完整、已指派责任人的缺陷单。
- 完成标志：状态由“新建”变为“已受理”，受理时间与责任人可查。
修复中
- 输入：已受理的缺陷单。
- 动作：开发定位根因，更新状态为“修复中”；完成修改后填写修复说明、修复版本，关联提交或变更，标注影响范围；如判断无需修复，写明理由并走确认流程。
- 输出：带修复说明与修复版本的缺陷单。
- 完成标志：状态变为“待验证”，修复完成时间被记录。
待验证
- 输入：待验证的缺陷单与包含修复的版本。
- 动作：开发提交验证申请，说明验证环境、修复内容与需要重点关注的场景；验证人据此准备验证用例。
- 输出：明确的验证任务与关注点清单。
- 完成标志：验证人已接收并开始验证，等待时长可统计。
验证与关闭
- 输入：验证环境、验证用例、待验证缺陷单。
- 动作：验证人按用例执行，记录验证环境与结论；通过则关闭，未通过则重开并写明未通过现象与复现步骤。
- 输出：带验证结论与验证人的关闭记录，或带重开原因的重开记录。
- 完成标志：状态为“已关闭”或“已重开”，验证时间可查。
四个阶段中，状态变更与时间记录应同步发生。若允许先改状态后补说明，时间数据就会失真，后续统计各环节停留时长便失去参考价值。
角色分工与各环节交付物
跟踪断链通常发生在交接处：提交人以为开发已知晓，开发以为测试会验证，测试以为缺陷已关闭。把每个角色的交付物和交接时点写清楚，可以减少这类悬空。
| 角色 | 主要职责 | 交付物 | 交接时点 |
|---|---|---|---|
| 提交人/测试 | 保证复现信息完整，执行验证并给出结论 | 可复现的缺陷记录、验证用例、验证结论 | 提交后交受理人；修复完成后接收验证申请并反馈结论 |
| 开发 | 更新修复状态，写清修复说明与影响范围 | 修复说明、修复版本、关联变更、影响范围说明 | 修复完成时交验证人，并说明验证关注点 |
| 缺陷管理或质量角色 | 维护状态流转规则，跟进超期与重开，组织跟踪例会 | 状态规则说明、超期清单、重开分析、跟踪结论 | 按固定节奏向团队同步跟踪结论 |
角色可以兼任，但职责不能空缺。小团队中开发也可能承担验证，此时仍应保留“验证人”字段并如实填写，避免自己改自己验却无记录可查。缺陷管理角色不必是专职岗位，关键是有人对状态规则的一致性和超期跟进负责。
一个缺陷从提交到关闭的记录示例
以下为演示情景，用于说明依据如何串联，不代表真实项目数据。
某版本中，测试人员发现“订单导出在数据量超过一万条时超时”。提交时填写：标题为“订单导出超过一万条时请求超时”；复现步骤为登录测试环境、进入订单列表、选择全部数据导出、等待超过六十秒后请求失败；环境为测试环境某构建版本；严重度为高；影响版本为该版本及上一版本；影响范围为订单导出功能。
受理人复核后可稳定复现，确认严重度并指派给开发甲，状态变为“已受理”，受理时间被记录。开发甲定位为导出查询未分页，状态改为“修复中”；完成后填写修复说明“导出改为分批查询并增加超时提示”，填写修复版本，关联对应提交，标注影响范围为订单导出及相邻的报表导出，状态改为“待验证”。
验证人按原复现步骤与边界数据执行验证，首次发现数据量接近上限时仍偶发超时，于是重开缺陷，写明未通过现象、所用数据量与验证环境，重开次数记为一次。开发甲补充修复说明后再次提交待验证。验证人复验通过，记录验证环境、验证用例、结论“通过”与验证人，缺陷关闭。
这条记录中，进度判断的依据依次是：受理时间证明已进入处理；修复说明与关联提交证明改了什么；重开记录证明第一次修复未达标；验证结论与验证人证明关闭有据。任何一环缺失，后续复盘都只能依赖回忆。
跟踪机制落地与完成检查
机制能否持续，取决于规则是否简单、检查是否可执行。建议先约定状态流转规则：明确允许的状态、每种状态的责任人、进入下一状态的条件，以及重开必须填写原因。超期提醒可按阶段设置阈值，例如受理超过约定时长未指派、修复中停留超过约定天数、待验证积压超过约定数量，触发后通知责任人与缺陷管理角色。阈值应结合团队节奏设定，并在复盘中调整。
周度跟踪例会只看记录，不做逐条口头汇报。建议核对四类信号：超期未受理的缺陷、修复中停留过久的缺陷、待验证积压的缺陷、重开次数异常的缺陷。会议产出是更新后的责任人与下一步动作，而非泛泛的进度描述。
完成检查可采用抽样方式，每周随机抽取若干缺陷单逐项核对：
- 基本信息完整：复现步骤可被他人重现，环境与影响版本已填写。
- 状态与时间一致：每次状态变更都有对应时间记录，无先改状态后补说明的情况。
- 修复信息可追溯：修复说明说明根因与改动，修复版本与关联变更可查。
- 验证结论可查：验证环境、验证用例、结论与验证人齐全，重开有原因。
- 跟踪结论有落点：例会发现的超期与异常已指派到人并更新状态。
记录需要载体。ONES 测试管理支持一键创建并关联缺陷，缺陷任务在测试与研发团队间流转，并可关联至迭代；测试用例可与需求、任务关联，测试计划与迭代关联，形成测试流程闭环；同时支持自动生成测试报告与项目缺陷分布统计。团队可以用工作项承载缺陷与状态流转，用文档沉淀验证结论与跟踪结论，再通过关联关系把两者衔接起来，使“提交—修复—验证—关闭”的证据链在同一处可查。具体字段与流转规则的配置方式，以团队实际使用的工具设置为准。
常见问题
缺陷单字段很多，团队刚开始跟踪时应该先保证哪些字段？
建议先保证能支撑判断的最小集合：复现步骤、严重度、责任人、修复说明、修复版本、验证结论与验证人。这几项覆盖了“能否受理、谁在修、改了什么、是否验证通过”四个问题。其余字段如影响范围、关联提交、重开原因，可以按项目需要逐步设为必填。每增加一个必填项，都要有人负责填写并在评审中实际使用，否则会退化为形式化记录。
开发自己修复自己验证，在小团队里可以接受吗？
可以接受，但记录不能省。小团队中开发兼任验证是常见安排，此时仍应保留“验证人”字段并如实填写，验证环境、验证用例与结论照常记录。这样即使同一人完成修复与验证，后续复盘仍能查到依据。若缺陷涉及高严重度或已发布功能，建议安排另一人复核，降低自验自过的风险。
缺陷关闭后又在线上复现，应该新建缺陷还是重开原缺陷？
取决于问题是否同一根因。若现象、触发条件与根因都与原缺陷一致，说明原修复未彻底，应重开原缺陷并写明复现环境与现象，保留重开次数，便于统计修复质量。若现象相似但根因不同，或由新的变更引入，则新建缺陷并关联原缺陷，避免把两个问题混在一条记录里。无论哪种方式，都要把新证据补进记录，而不是只在聊天中同步。
跟踪例会怎样开才不至于变成逐条口头汇报？
会前由缺陷管理或质量角色按记录筛出四类信号：超期未受理、修复中停留过久、待验证积压、重开次数异常。会上只讨论这些条目，逐条确认责任人与下一步动作，并当场更新状态。常规推进中的缺陷不在会上逐条过。这样会议产出是可查的更新记录，而不是口头进度描述。
用工具承载缺陷记录时，需要关注哪些衔接点？
关注三点：缺陷与测试用例、测试计划的关联，让验证有据可依；缺陷与迭代、变更的关联，让修复版本可追溯；缺陷记录与验证结论、跟踪结论文档的关联，让证据链在同一处可查。以 ONES 测试管理为例，支持未通过的用例快速创建缺陷任务，缺陷任务在测试与研发团队间流转，缺陷可关联至迭代，并支持自动生成测试报告与项目缺陷分布统计。具体字段与流转规则的配置方式，以团队实际使用的工具设置为准。
