缺陷修复进度表以缺陷单为行、以“修复—验证”状态流转为主线，把缺陷标识、严重程度、责任人、修复状态、验证结论和时间节点固定下来。设计时先明确表要回答的问题：谁在修、卡在哪、何时可验证；再定字段与状态口径，最后约定更新节奏和完成检查。本文覆盖从缺陷提交到验证关闭这一段，不展开整体回归测试管理和代码级排查。
要点总览（TL;DR）
- 进度表以缺陷单为行，先固定缺陷编号、模块版本、严重程度、优先级、当前状态、当前责任人和四个时间节点，保证每行能回答“谁在修、卡在哪、何时可验证”。
- 状态集合保持精简，按新建、已受理、处理中、待验证、重新打开、已关闭推进；验证不通过走重新打开并保留原编号，拒绝和延期单独记录理由。
- 更新以状态变更即更新为主、每日巡检为辅，周度汇总新增、关闭、重新打开数量和平均修复时长，超期未受理与反复重开的缺陷进入评审。
- 用一条完整示例核对字段与状态的配合，再按字段完整性、口径一致性、状态可追溯、验证闭环、重新打开可统计、阻断项可见六项检查判断表是否可用。
进度表先定字段：一行缺陷要记录什么
字段设计的目标是让一行记录能独立回答三个问题：这是什么缺陷、现在由谁处理、下一步该谁动作。字段过多会拖慢填写，过少则无法判断进度，建议按“必填保底、选填补充”的方式划分。
必填字段是每张缺陷单都必须有的信息，缺一项就无法正常流转或统计；选填字段用于补充背景，可按团队习惯取舍。
| 字段 | 类型 | 必填/选填 | 填写口径 |
|---|---|---|---|
| 缺陷编号 | 文本/自动编号 | 必填 | 系统生成或按规则编号，全表唯一，作为跨表引用的依据 |
| 缺陷标题 | 文本 | 必填 | 一句话描述现象，包含模块和触发条件，避免只写“页面报错” |
| 所属模块/版本 | 单选/文本 | 必填 | 定位缺陷所在功能范围和引入版本，便于按模块汇总 |
| 严重程度 | 枚举 | 必填 | 描述缺陷本身的影响，如致命、严重、一般、轻微 |
| 优先级 | 枚举 | 必填 | 描述修复的先后安排，如紧急、高、中、低 |
| 当前状态 | 枚举 | 必填 | 按统一状态集合取值，反映缺陷所处环节 |
| 当前责任人 | 人员 | 必填 | 只填一个当前处理人，随状态变更同步调整 |
| 发现人 | 人员 | 必填 | 提交缺陷的测试或使用人员，验证环节通常由其确认 |
| 发现时间 | 日期时间 | 必填 | 缺陷首次提交的时间 |
| 受理时间 | 日期时间 | 必填 | 开发确认接收并开始处理的时间 |
| 修复提交时间 | 日期时间 | 必填 | 开发提交修复、转入待验证的时间 |
| 验证完成时间 | 日期时间 | 必填 | 验证通过或验证不通过结论给出的时间 |
| 验证结论 | 枚举+说明 | 必填 | 通过、不通过、部分通过，附简要验证说明 |
| 关联需求/用例 | 关联项 | 选填 | 指向对应需求或用例，便于追溯影响范围 |
| 复现步骤 | 长文本 | 选填 | 环境、操作步骤、预期与实际结果 |
| 备注 | 长文本 | 选填 | 阻塞原因、依赖项、临时规避方案等 |
状态字段的口径必须提前定义，否则同一状态在不同人手里含义不同。例如“处理中”应明确指开发已受理并正在修改，“待验证”指修复已提交、等待测试确认，避免把“已修复”和“已验证”混为一谈。严重程度与优先级要分开记录：严重程度由缺陷影响决定，通常由测试判定；优先级由排期和业务影响决定，通常由开发负责人或缺陷管理员确认。两者分开，才能在资源紧张时按优先级排序，同时不丢失对严重缺陷的关注。
状态流转怎么设：从受理到验证关闭
状态集合建议保持精简，覆盖缺陷从提交到关闭的主要环节，每个状态对应一个明确的动作完成标志。常见状态集合与流转顺序如下。
| 状态 | 进入条件 | 责任人 | 下一步 |
|---|---|---|---|
| 新建 | 缺陷已提交，尚未受理 | 发现人 | 缺陷管理员分派或开发受理 |
| 已受理 | 开发确认缺陷成立并接收 | 开发 | 开始修复，转入处理中 |
| 处理中 | 开发正在定位或修改 | 开发 | 修复完成，转入待验证 |
| 待验证 | 修复已提交，等待测试确认 | 测试 | 验证通过转已关闭，不通过转重新打开 |
| 重新打开 | 验证不通过或问题复现 | 测试 | 回到处理中，由开发继续修复 |
| 已关闭 | 验证通过并确认闭环 | 测试 | 结束，纳入统计 |
| 已拒绝/延期 | 确认非缺陷、重复或暂不修复 | 缺陷管理员 | 记录理由后关闭或挂起 |
退回与重新打开要区分处理。“已拒绝”用于缺陷不成立、重复提交或经评估暂不修复的情况，需要写明理由并由缺陷管理员确认；“重新打开”用于修复后验证不通过或问题复现，应保留原缺陷编号，记录重新打开的时间和原因，避免另开新单造成重复统计。验证不通过时的回退路径要固定：测试填写验证结论和复现信息，状态回到处理中，责任人切回原开发或重新分派，修复提交时间在下一轮更新时覆盖为最新一次提交时间，历史轮次可在备注中保留。
状态变更的责任人要写进规则：提交和验证由测试负责，受理、修复提交由开发负责，分派、拒绝和关闭确认由缺陷管理员或测试负责人把关。每次状态变更同步更新当前责任人和对应时间字段，保证表里的“当前状态”始终对应一个明确的下一步动作。在工具层面，ONES Project 支持一键提交 Bug 至对应项目或迭代，并记录和跟踪缺陷修复情况；ONES 测试管理与 TestCase 数据互通，可一键创建并关联缺陷，让修复与验证围绕同一张缺陷单交接。状态集合的具体取值以团队约定为准，落地时按实际环境配置。
角色分工与更新节奏
进度表能否反映真实进度，取决于谁填、谁改、何时改。角色职责建议按下表约定，避免出现“大家都能改、没人负责”的情况。
| 角色 | 主要职责 | 更新动作 |
|---|---|---|
| 测试 | 提交缺陷、验证修复、给出验证结论 | 提交时填全必填字段；验证后更新验证结论和验证完成时间 |
| 开发 | 受理缺陷、修复、提交待验证 | 受理时更新受理时间和责任人；修复提交时更新修复提交时间和状态 |
| 缺陷管理员 | 分派、协调、把关状态口径 | 处理新建缺陷的分派；确认拒绝和延期理由；维护状态取值一致性 |
| 项目负责人 | 关注阻断项和整体进度 | 评审时查看超期未处理和反复重新打开的缺陷 |
更新节奏建议采用“状态变更即更新”为主、每日巡检为辅的方式：任何一次状态推进都在当下完成字段更新，保证表随时可用；每日由缺陷管理员巡检一次，重点看新建未受理、待验证超期、重新打开次数多的缺陷。周度汇总适合在迭代评审或项目例会上触发，输出本周新增、关闭、重新打开数量和平均修复时长，用于判断修复节奏是否正常。触发条件可以设为：待验证超过约定时限、同一缺陷重新打开两次以上、严重程度为致命或严重的缺陷未在约定时间内受理，出现任一情况即进入评审或升级处理。
如果团队使用 ONES，缺陷工作项可以直接承载上述字段和状态，责任人随状态流转切换，看板和统计视图用于查看当前进度与缺陷状态分布，减少在表格和工具之间反复同步的成本。
填写示例：一条缺陷从提交到验证
以下为演示情景，缺陷编号、时间和结论均为示例，不代表真实项目数据。
测试人员在支付模块提交缺陷：编号 BUG-1024，标题“订单支付成功后页面未跳转至结果页”，所属模块为支付，严重程度为严重，优先级为高，状态为新建，发现人为测试甲，发现时间为周一 10:00，复现步骤记录环境、操作路径和预期结果。
开发乙当天 11:30 受理，状态改为已受理，责任人改为开发乙，受理时间填 11:30；随后进入处理中。周二 15:00 修复提交，状态改为待验证，修复提交时间填 15:00，责任人改为测试甲。测试甲周三 09:30 验证，发现特定网络条件下仍偶现，验证结论填“不通过”，附复现说明，状态改为重新打开，验证完成时间填 09:30，责任人切回开发乙。
开发乙补充修复后周三 16:00 再次提交，状态回到待验证，修复提交时间更新为 16:00。测试甲周四 10:00 复验通过，验证结论填“通过”，状态改为已关闭，验证完成时间填 10:00。整条记录中，四个时间字段完整，状态推进与责任人切换一一对应，重新打开的原因和轮次可从备注追溯。
这个示例可迁移的规律是：每次状态变化都伴随一个时间字段和一个责任人变化；验证结论必须带说明，不能只填结果；重新打开保留原编号，通过时间字段的更新和备注记录轮次，保证统计时不重复计数。
完成检查：表是否可用的判断标准
设计完成后，用下面的清单逐项核对，判断进度表能否真正支撑修复与验证的交接。
| 检查项 | 判断标准 | 不通过时的修正动作 |
|---|---|---|
| 字段完整性 | 必填字段在每行都有值，无空置的关键字段 | 补设必填校验，清理历史空值 |
| 口径一致性 | 状态、严重程度、优先级取值来自同一套定义，无同义混用 | 发布字段填写说明，统一枚举值 |
| 状态可追溯 | 每个状态变化都有对应时间和责任人记录 | 补齐时间字段，要求变更即更新 |
| 验证闭环 | 关闭的缺陷都有验证结论和验证完成时间 | 排查无结论即关闭的记录，补做验证 |
| 重新打开可统计 | 重新打开沿用原编号，轮次可识别 | 合并重复单，统一重新打开规则 |
| 阻断项可见 | 超期未受理、待验证超时、反复重开的缺陷能被筛出 | 设置筛选视图或提醒规则 |
核对时优先处理阻断项：必填字段大面积缺失或状态口径混乱，会直接导致进度失真，应先修正再投入使用；验证结论未闭环的记录，应回到测试环节补验。全部检查项通过后，这张表就可以作为修复与验证交接的日常依据，并按周度汇总持续校准。
常见问题
缺陷修复进度表和缺陷管理系统里的缺陷列表是什么关系？
两者记录的是同一批缺陷，区别在用途。进度表强调修复到验证这一段的状态、责任人和时间节点，适合评审和汇总；缺陷管理系统承载同一张缺陷单的字段、状态流转和统计视图。团队规模较小、缺陷量不大时，可以先用表格起步；缺陷量增加后，把字段和状态口径迁移到工具中，减少手工同步。ONES Project 支持一键提交 Bug 至对应项目或迭代并记录跟踪缺陷修复情况，ONES 测试管理可与 TestCase 数据互通、一键创建并关联缺陷，适合把进度表的字段和状态落到同一张缺陷单上。
验证不通过时，应该新开一张缺陷单还是重新打开原单？
修复后验证不通过或问题复现，建议重新打开原缺陷单，保留原编号，记录重新打开的时间和原因。这样统计缺陷总数和重新打开次数时不会重复计数，也能看出同一缺陷的修复轮次。只有确认是另一个独立问题时，才新开缺陷单，并在备注中关联原单。若团队选择新开单，需要在进度表中增加“关联原缺陷”字段，否则重复统计难以避免。
缺陷数量多、更新频繁时，怎么保证进度表不失控？
先把必填字段压到最少，只保留判断进度必需的信息，其余放入选填或备注；再把状态变更的责任落到具体角色，谁推进状态谁更新字段，避免集中到一个人维护。每日巡检只筛三类记录：新建未受理、待验证超期、重新打开两次以上。周度汇总用固定口径输出数量与平均修复时长，不再逐条追。缺陷量继续增长时，考虑把字段和状态配置到缺陷管理工具中，用看板和统计视图替代手工汇总。
严重程度和优先级都填了，排期时以哪个为准？
排期以优先级为准，严重程度用于保证严重缺陷不被遗漏。严重程度描述缺陷本身的影响，通常由测试判定；优先级描述修复的先后安排，由开发负责人或缺陷管理员结合业务影响确认。两者分开记录后，资源紧张时可以按优先级排序，同时对严重程度为致命或严重的缺陷设置受理时限，超时即升级处理。
进度表设计好后，怎么判断它真的在起作用？
看三个信号：关闭的缺陷是否都有验证结论和验证完成时间；每个状态变化是否都有对应的时间和责任人记录；超期未受理、待验证超时、反复重开的缺陷能否被快速筛出。三项都成立，说明表能支撑修复与验证的交接。若必填字段大面积缺失或状态取值混用，先统一口径再投入使用，否则统计出的进度会失真。
