缺陷修复进度表把每个缺陷从发现到关闭的关键信息放在同一行，便于测试、开发和项目负责人共同查看修复进展。本文提供一张可直接复制到表格工具中的空白模板，并说明各字段的填写口径、必填与选填的取舍、一条缺陷的完整填写示例，以及模板长期使用时的维护规则。适用范围覆盖缺陷提交、分派、修复、提交验证到关闭，变更后的整体回归测试不在本文展开。
要点总览（TL;DR）
- 缺陷修复进度表按缺陷逐行记录，覆盖发现、分派、修复、提交验证到关闭的主线，可直接复制表头与空白行使用。
- 核心字段包括缺陷编号、缺陷标题、严重程度、优先级、当前状态、责任人、发现版本、修复版本、提交验证时间、验证结论、关闭时间与备注。
- 必填字段为缺陷编号、缺陷标题、当前状态、责任人、严重程度；版本、验证结论与关闭时间等按团队发布节奏和统计需要选填。
- 填写时状态与时间同步更新：转为待验证时填提交验证时间，关闭时填验证结论与关闭时间，退回时保留原记录并追加新一轮。
- 长期维护围绕字段增删、更新责任人与工具衔接展开，缺陷量增大后可将字段映射为缺陷管理工具的工作项属性。
可复制空白缺陷修复进度表
下表按缺陷处理主线排列字段，可直接复制表头与空白行到 Excel、在线表格或缺陷管理工具的自定义视图中使用。建议一行只记录一个缺陷，同一缺陷的多次返修在“备注”中追加轮次说明，保持行数与缺陷数一一对应。
| 缺陷编号 | 缺陷标题 | 严重程度 | 优先级 | 当前状态 | 责任人 | 发现版本 | 修复版本 | 提交验证时间 | 验证结论 | 关闭时间 | 备注 |
|---|---|---|---|---|---|---|---|---|---|---|---|
复制时保留表头文字不变，便于后续与字段说明、填写示例逐项对照。若团队已有缺陷管理工具，可将这张表作为字段设计清单，把相同字段映射为工具中的工作项属性。
每个字段记录什么：字段说明
字段说明解决“这一格该填什么、由谁填”的问题。下表给出每个字段的含义、常见取值与主要填写人，取值口径以团队约定为准，关键是同一字段在不同缺陷行中保持一致的写法。
| 字段 | 含义与填写口径 | 取值示例 | 主要填写人 |
|---|---|---|---|
| 缺陷编号 | 缺陷的唯一标识，提交时由工具自动生成或按团队规则手工编号，全表不重复 | BUG-1024 | 提交人/系统 |
| 缺陷标题 | 用一句话描述现象与位置，包含操作对象和异常表现，避免只写“有问题” | 订单列表页筛选日期后结果为空 | 提交人 |
| 严重程度 | 描述缺陷对功能的影响程度，按团队分级标准填写，反映影响而非排期 | 致命/严重/一般/轻微 | 提交人，测试负责人可复核 |
| 优先级 | 描述修复的紧急程度，由项目或开发负责人结合版本计划确定 | 高/中/低 | 开发负责人/项目经理 |
| 当前状态 | 缺陷所处环节，随处理推进更新，取值与团队状态定义一致 | 新建/已分派/修复中/待验证/已关闭/重新打开 | 当前处理人 |
| 责任人 | 当前对下一步动作负责的人，分派后为开发人员，提交验证后为测试人员 | 张明 | 分派人/当前处理人 |
| 发现版本 | 缺陷被发现的构建或发布版本号，用于定位问题引入范围 | V2.3.1 | 提交人 |
| 修复版本 | 包含修复代码的版本号，开发完成修复并提交验证时填写 | V2.3.2 | 开发人员 |
| 提交验证时间 | 开发将缺陷转为待验证的时点，精确到日期，必要时加时间 | 2025-03-12 | 开发人员 |
| 验证结论 | 测试对修复结果的判定，通过则进入关闭，不通过则记录现象并退回 | 通过/不通过，附简要说明 | 测试人员 |
| 关闭时间 | 验证通过并确认关闭的时点，未关闭的缺陷此格留空 | 2025-03-13 | 测试人员 |
| 备注 | 记录返修轮次、阻塞原因、关联需求或环境差异等补充信息 | 第二轮返修，依赖接口联调 | 当前处理人 |
状态字段与时间字段需要配合填写：状态变为“待验证”时同步填写提交验证时间，状态变为“已关闭”时填写验证结论与关闭时间。缺陷被退回时，状态改为“重新打开”，责任人回到开发人员，原验证结论保留并在备注中说明退回原因，避免覆盖历史记录。
必填与选填：按团队流程取舍
最小可用字段集保证任何一条缺陷都能被找到、被分派、被判断是否关闭。字段越多，填写负担越重，遗漏和随意填写的概率也越高，因此建议先跑通必填集，再按实际需要增加选填字段。
| 类别 | 字段 | 取舍理由与适用条件 |
|---|---|---|
| 必填 | 缺陷编号、缺陷标题、当前状态、责任人、严重程度 | 编号用于唯一识别与检索；标题让人不看详情也能判断问题；状态和责任人决定这条缺陷是否有人推进；严重程度支撑修复排序与质量判断 |
| 建议填写 | 优先级、发现版本、修复版本、提交验证时间、验证结论、关闭时间 | 有版本发布节奏或需要统计修复周期的团队应填写；单人维护的小项目可先省略版本字段，但验证结论与关闭时间建议保留，否则无法区分“已修复”与“已验证” |
| 按需扩展 | 备注、缺陷类型、所属模块、关联需求、复现环境 | 缺陷量大、跨模块协作或需要按模块统计时增加；字段增加后应指定填写人和填写时点，否则容易长期空白 |
字段增减会直接影响跟踪效果：删掉责任人，缺陷容易停在“已分派”无人推进；删掉验证结论，关闭依据只剩开发自述；增加过多分类字段而无人维护，会让筛选和统计失真。调整字段时优先保证“谁负责、到哪一步、是否验证通过”三类信息完整。
填写示例：一条缺陷从提交到关闭
以下示例演示同一缺陷在四个关键节点的填写变化，字段与前面的模板、字段说明保持一致。示例为演示情景，人员与版本信息均为虚构。
| 节点 | 当前状态 | 责任人 | 修复版本 | 提交验证时间 | 验证结论 | 关闭时间 | 备注 |
|---|---|---|---|---|---|---|---|
| 提交 | 新建 | 测试负责人待分派 | — | — | — | — | 附复现步骤与截图 |
| 分派 | 已分派 | 张明 | — | — | — | — | 优先级定为高 |
| 提交验证 | 待验证 | 李婷 | V2.3.2 | 2025-03-12 | — | — | 已合入修复分支 |
| 验证不通过 | 重新打开 | 张明 | V2.3.2 | 2025-03-12 | 不通过：筛选后仍缺部分数据 | — | 第二轮返修 |
| 再次提交验证 | 待验证 | 李婷 | V2.3.3 | 2025-03-14 | — | — | 补充边界条件处理 |
| 关闭 | 已关闭 | 李婷 | V2.3.3 | 2025-03-14 | 通过 | 2025-03-15 | 回归相关用例均通过 |
这条示例的固定字段为：缺陷编号 BUG-1024，标题“订单列表页筛选日期后结果为空”，严重程度“严重”，发现版本 V2.3.1。可以看到，编号、标题、严重程度在整条生命周期内不变；状态、责任人随处理环节切换；修复版本在返修后更新为新的版本号；验证结论与关闭时间只在验证环节填写，退回时保留原提交验证时间并追加新一轮记录。
填写时有两个常见偏差值得注意。一是把“已修复”直接写成“已关闭”，跳过了验证结论，导致关闭依据不足；二是返修时覆盖上一轮的验证结论，丢失退回原因。按示例逐节点追加记录，可以保留完整的修复轨迹，也方便后续统计返修次数。
调整与维护：让进度表长期可用
模板用起来之后，问题通常不在字段设计，而在更新不及时和字段越加越多。维护规则围绕三件事展开：字段怎么调、谁来更新、与工具如何衔接。
字段增删的调整原则
- 新增字段前先确认用途：要支撑哪类筛选、统计或交接，没有明确用途的字段不加。
- 一次只调整少量字段，并在表头下方注明启用日期，避免历史行与新增行口径混乱。
- 删除字段前先导出一次历史数据，确认统计和追溯不依赖该字段。
- 字段名称保持稳定，改名时同步更新字段说明，防止不同角色理解不一致。
更新频率与责任人
- 状态、责任人由当前处理人在动作发生时即时更新，不等到例会集中补填。
- 项目负责人或测试负责人按固定节奏（如每日或每个迭代节点）核对“待验证”和“重新打开”的缺陷是否有人跟进。
- 关闭时间与验证结论由测试人员填写，其他人不代填，保证关闭依据可追溯。
- 每周或每个版本结束时检查空值率，长期空白的选填字段考虑删除或明确填写人。
与缺陷管理工具的衔接
当缺陷数量增加、多人并行处理时，手工表格容易出现版本不一致。此时可把进度表字段映射为缺陷管理工具中的工作项属性，让状态流转和责任人变更在工具内完成，表格转为导出视图或统计口径。ONES 测试管理解决方案提供覆盖全生命周期的缺陷管理，缺陷可关联至迭代；在缺陷追踪场景中支持一键创建并关联缺陷，便于团队围绕缺陷协作。ONES Project 支持一键提交 Bug 至对应项目或迭代，记录和跟踪缺陷修复情况，并统计缺陷状态分布；其筛选器支持全局与项目内多重条件筛选，可用于按状态、责任人快速定位待处理缺陷。将本文的字段与这些工作项属性对应设置，可以让表格中的填写规范延续到工具使用中。
无论使用表格还是工具，维护的核心是让每条缺陷在任何时刻都能回答三个问题：现在由谁负责、处于哪个环节、是否已经验证通过。围绕这三点定期检查，进度表就能持续反映真实的修复进展。
常见问题
缺陷被退回后，进度表里的验证结论和提交验证时间应该怎么处理？
退回时把状态改为“重新打开”，责任人切回开发人员，原验证结论和提交验证时间保留，不覆盖。新一轮修复完成后，用新的提交验证时间与修复版本追加记录，备注中写明退回原因和返修轮次。这样同一缺陷的每轮验证都有据可查，返修次数也能直接统计。
团队规模小、缺陷不多，可以只保留必填字段吗？
可以。缺陷编号、缺陷标题、当前状态、责任人、严重程度这五项能支撑“找到缺陷、有人推进、判断影响”的基本跟踪。建议至少再保留验证结论与关闭时间，否则无法区分“开发说已修复”和“测试确认通过”。版本类字段在单人维护、没有并行发布时可以先省略，等出现多版本并行再补上。
进度表里的严重程度和优先级由谁定，两者冲突时以哪个为准？
严重程度通常由提交人按影响范围填写，测试负责人可复核；优先级由开发负责人或项目经理结合版本计划确定。两者描述的是不同维度：严重程度反映功能受影响的程度，优先级反映修复排期的紧急程度。排期时以优先级为准，同时参考严重程度，避免出现影响大但被长期排在后面的缺陷无人解释。
手工表格和缺陷管理工具应该怎么分工？
缺陷数量少、参与人少时，表格足够用。缺陷增多、多人并行处理后，手工表容易出现版本不一致和漏更新，此时可把进度表字段映射为工具中的工作项属性，让状态流转和责任人变更在工具内完成，表格转为导出视图或统计口径。ONES 测试管理解决方案提供覆盖全生命周期的缺陷管理，缺陷可关联至迭代；ONES Project 支持一键提交 Bug 至对应项目或迭代，记录和跟踪缺陷修复情况，并统计缺陷状态分布。迁移时保持字段名称与填写口径不变，团队适应成本更低。
进度表需要多久检查一次，检查什么？
状态和责任人由当前处理人在动作发生时即时更新，不依赖集中补填。项目负责人或测试负责人可按每日或每个迭代节点核对“待验证”和“重新打开”的缺陷是否有人跟进，每周或每个版本结束时检查一次空值率。重点看三类信息是否完整：谁负责、处于哪个环节、是否已验证通过。长期空白的选填字段考虑删除或明确填写人。
