缺陷修复进度跟踪要解决的是：每条缺陷当前在谁手里、下一步做什么、验证证据是否齐备。本文围绕缺陷从确认到验证关闭这一段，给出状态节点划分、角色分工、台账字段、填写示例和完成检查，帮助团队建立一套能日常运转的跟踪机制。
要点总览（TL;DR）
- 缺陷修复进度跟踪的对象是缺陷从“已确认”到“已验证关闭”的路径，判断进度看三件事：当前状态、责任人、进入下一状态还缺什么。
- 状态节点建议划分为已提交、已确认、修复中、待验证、验证通过、关闭、重新打开，每个节点绑定进入条件、完成标志和责任人。
- 提交人、测试负责人、开发责任人、验证人和项目或质量负责人各有明确交付物，字段缺失时状态不推进，比事后检查更有效。
- 缺陷台账至少记录编号、标题、严重级别、当前状态、责任人、发现版本、修复版本、验证人和更新时间，让任何人无需翻聊天记录即可判断进度。
- 机制是否运转可用状态一致性、超期处理记录、验证证据、关联追溯和字段完整性五项检查，每个迭代复查一次，连续两个周期通过可视为稳定。
缺陷修复进度跟踪的核心答案与操作步骤
跟踪对象是缺陷从“已确认”到“已验证关闭”的完整路径。判断进度时看三个问题：当前停在哪个状态、该状态的责任人是谁、进入下一状态还缺什么。把这三个问题固定到状态节点和台账字段上，跟踪就不再依赖口头询问。
状态节点建议按以下方式划分。节点数量可按团队规模调整，但每个节点都要有明确的进入条件和完成标志，否则状态会变成随手填写的标签。
| 状态 | 进入条件 | 完成标志 | 责任人 |
|---|---|---|---|
| 已提交 | 提交人填写标题、复现步骤、环境、期望与实际结果 | 信息完整，可被他人按步骤复现 | 提交人 |
| 已确认 | 测试或缺陷负责人复现成功，完成定级并指派开发责任人 | 严重级别、优先级、责任人字段齐全 | 测试负责人 |
| 修复中 | 开发责任人接受指派并开始处理 | 提交修复说明与影响范围，代码合入对应版本 | 开发责任人 |
| 待验证 | 修复完成，修复版本已部署到可验证环境 | 验证人收到验证请求，环境与版本信息明确 | 开发责任人 |
| 验证通过 | 验证人按原复现步骤执行，结果符合期望 | 验证结论与证据记录完整 | 验证人 |
| 关闭 | 验证通过且无关联遗留问题 | 关闭时间、关闭人记录在案 | 验证人或测试负责人 |
| 重新打开 | 验证不通过，或关闭后再次复现 | 写明失败现象，退回修复中并通知原开发责任人 | 验证人 |
跟踪节奏由两部分组成。日常层面，每天用一次短会或看板巡检过一遍状态有变化的缺陷，重点看“修复中”停留过久和“待验证”积压的条目；时限层面，按严重级别设定响应与修复时限，例如阻断级缺陷当日响应、当日给出处理方案，一般缺陷按迭代节奏处理。时限数值由团队根据发布节奏确定，关键是超期后有人跟进。
缺陷台账至少记录以下字段：编号、标题、严重级别、当前状态、责任人、发现版本、修复版本、验证人、更新时间。字段的作用是让任何人在不看聊天记录的情况下，判断这条缺陷走到哪一步、卡了多久。
当缺陷数量增多、跨版本并行时，状态和责任人需要落在统一的工作项上而不是分散在表格和聊天里。ONES Project 支持一键提交 Bug 至对应项目或迭代，记录和跟踪缺陷修复情况；ONES 测试管理支持一键创建并关联缺陷，让成员围绕缺陷协作。缺陷关联到迭代后，看板可以直接呈现各状态的分布，便于每日巡检时按状态列逐条过。
角色分工与各环节交付物
缺陷卡住最常见的原因是交接处没有明确交付物：开发说修好了，验证人不知道在哪个版本验证；验证人说没通过，开发不知道失败现象是什么。按角色固定交接物，可以让每次状态推进都有据可查。
| 角色 | 主要动作 | 交付物 | 交接完成标志 |
|---|---|---|---|
| 提交人 | 描述问题并提交 | 复现步骤、测试环境、期望结果与实际结果，必要时附截图或日志 | 他人可按步骤复现 |
| 测试负责人或缺陷负责人 | 复现确认、定级、指派 | 严重级别与优先级判断、开发责任人 | 缺陷进入已确认状态，责任人明确 |
| 开发责任人 | 定位与修复 | 修复说明、影响范围、修复版本 | 缺陷进入待验证，验证环境可用 |
| 验证人 | 按原步骤验证 | 验证结论、验证证据、验证时间 | 状态变为验证通过或重新打开 |
| 项目或质量负责人 | 跟踪超期缺陷、协调跨团队阻塞 | 超期清单、升级记录、协调结论 | 阻塞解除或明确处理方案 |
交接时的必填字段要与状态绑定：进入“待验证”必须填修复版本，进入“验证通过”必须填验证结论和证据，重新打开必须写失败现象。字段缺失时状态不应推进，这条规则比事后检查更有效。
权限安排上，缺陷的编辑、状态流转和关闭可以按角色区分。ONES Project 提供产品、项目、任务多层级权限，可按组织架构、用户组、项目角色分配，适合把关闭权限收敛到测试角色、把修复字段维护交给开发角色。
跟踪示例：一条缺陷从提交到验证关闭的完整记录
以下为演示情景，用于说明台账如何填写，不代表真实项目数据。
初始信息：编号 BUG-1042，标题“订单列表按金额排序后翻页结果重复”，严重级别为严重，发现版本 V2.3.1，提交人填写复现步骤——进入订单列表、选择按金额升序、翻至第二页，期望第二页不出现第一页已展示的订单，实际出现 3 条重复记录，附截图一张。
确认与定级：测试负责人按步骤复现成功，判断影响用户核对订单，定为严重级别，指派开发责任人张某，状态改为已确认，更新时间记录为当日。
修复中：张某定位为分页参数未携带排序条件，状态改为修复中。期间发现该问题与另一处查询逻辑相关，在缺陷下记录阻塞说明与预计处理时间，避免状态长期无更新。
待验证：修复合入 V2.3.2，张某填写修复说明与影响范围，状态改为待验证，修复版本填 V2.3.2。
验证通过：验证人李某在 V2.3.2 环境按原步骤验证，翻页结果无重复，填写验证结论“按原步骤验证通过”，附验证截图，状态改为验证通过，随后关闭并记录关闭时间。
重新打开的处理：若验证时仍出现重复，李某将状态改为重新打开，写明失败现象与复现环境，退回张某处理，台账中保留两次验证记录，便于判断是修复不彻底还是环境不一致。
可迁移的记录习惯有三条：状态每次变化都更新时间和操作人；修复说明写清原因和影响范围，而不只写“已修复”；验证结论附可复核的证据，让后来的人能独立判断。
完成检查：跟踪机制是否真正运转
机制是否落地，可以用下面这份清单逐项核对。建议每个迭代结束复查一次，连续两个周期全部通过，可视为机制稳定运转。
| 检查项 | 核对方式 | 通过标准 |
|---|---|---|
| 状态与实际动作一致 | 抽查若干缺陷，比对状态变更时间与代码合入、验证记录 | 无长期停留状态，状态变更时间与实际行动吻合 |
| 超期缺陷有处理记录 | 筛选超过时限的缺陷 | 每条都有升级或协调记录，而非仅停留在列表中 |
| 验证结论有证据 | 抽查已关闭缺陷 | 验证结论、验证人、验证时间齐全，证据可复核 |
| 关联关系可追溯 | 从缺陷反查所属迭代、关联用例与版本 | 能定位缺陷来源与影响范围 |
| 字段完整性 | 检查严重级别、责任人、发现版本、修复版本等字段 | 关键字段无空缺，缺失时状态未推进 |
需要说明边界：缺陷验证通过后的整体回归测试安排、回归范围确定和回归结果管理，属于回归测试管理的内容，本文不展开。本文的检查范围止于单条缺陷的验证闭环。
复查周期可与迭代节奏对齐，每次复查输出一份超期清单和字段缺失清单，作为下一周期改进的输入。ONES Project 提供看板、燃尽图等工具实时查看进度，并支持统计缺陷状态分布，可作为复查时的数据来源；具体视图配置以实际部署版本为准。
常见问题
缺陷在“修复中”停留很久，跟踪时应该怎么处理？
先看这条缺陷是否记录了阻塞说明和预计处理时间。有记录时，按记录的时间点跟进，确认阻塞是否解除；没有记录时，要求开发责任人补充当前进展和卡点，再判断是否需要项目或质量负责人协调。
如果同一责任人的多条缺陷长期停留在修复中，可在每日巡检时集中过一遍，区分是排期问题还是技术难点，分别给出调整优先级或增加支持的处理方案。
验证不通过重新打开缺陷时，需要保留哪些信息？
重新打开时要写明失败现象、复现环境和验证时间，并退回原开发责任人。台账中保留前后两次验证记录，便于判断是修复不彻底还是环境不一致。
如果重新打开后再次修复，修复说明应针对上次失败现象作出回应，避免同一问题反复流转而缺少可追溯的处理依据。
团队规模较小，是否必须设置全部七个状态节点？
节点数量可以按团队规模调整，例如合并“验证通过”和“关闭”，或把“已提交”和“已确认”合并处理。调整的前提是每个保留的节点仍有明确的进入条件、完成标志和责任人。
节点减少后，台账字段和交接规则要同步对齐，确保状态变化仍能反映实际动作，避免状态变成随手填写的标签。
缺陷修复跟踪和回归测试管理的边界在哪里？
本文的跟踪范围止于单条缺陷从确认到验证关闭的闭环，包括状态流转、责任人交接和验证证据记录。缺陷验证通过后，因变更引发的整体回归范围确定、回归执行安排和回归结果管理，属于回归测试管理的内容。
实际执行时，可在缺陷关闭记录中标注是否需要纳入回归，把后续安排交给回归测试管理流程承接。
用工作项承载缺陷跟踪时，ONES 能提供哪些支撑？
ONES Project 支持一键提交 Bug 至对应项目或迭代，记录和跟踪缺陷修复情况；ONES 测试管理支持一键创建并关联缺陷，让成员围绕缺陷协作。缺陷关联到迭代后，看板可呈现各状态分布，便于每日巡检按状态列逐条过。
权限方面，ONES Project 提供产品、项目、任务多层级权限，可按组织架构、用户组、项目角色分配，适合把关闭权限收敛到测试角色、把修复字段维护交给开发角色。具体字段与流程配置以实际部署版本为准。
