缺陷修复及时率的计算可以归结为一个比率：统计周期内按时完成修复并通过验证的缺陷数，除以同期应完成修复的缺陷数，再乘以100%。结果是否可信，取决于三个口径是否先定清楚——从什么时间起算、按什么时限截止、以哪个时点判定完成。本文给出公式、分子分母范围、时间字段、边界处理和可复算的例子，并说明如何在缺陷跟踪工具中落地统计。
要点总览（TL;DR）
- 缺陷修复及时率 = 统计周期内按时完成修复并通过验证的缺陷数 ÷ 同期到期应完成修复的缺陷数 × 100%，结果是否可信取决于起算、截止、完成三个口径是否先定清楚。
- 分母只纳入统计周期内到期应完成的缺陷，剔除重复单、非缺陷单和挂起或延期审批通过的单；分母为零时报告“无到期缺陷”，不写0%或100%。
- 完成时点取验证通过的时间戳，不取状态改为“已修复”的时间；期末仍未关闭的到期缺陷计入分母、不计入分子，跨周期缺陷按到期日归属周期。
- 及时率是流程时效指标，需与平均修复时长、重开率、遗留缺陷数配合观察，按项目、版本或严重级别分组看趋势，不宜直接用于个人绩效排名。
- 落地时先确认缺陷工作项具备严重级别、承诺时限、验证结论与验证通过时间字段，状态流转区分已修复与已验证，再用一个周期手工复算核对系统报表。
这个指标要回答什么问题
缺陷修复及时率衡量的是团队在承诺时限内完成缺陷修复并交付验证的能力。它回答一个具体的决策问题：当前的修复节奏是否匹配团队对外承诺的修复时限。如果及时率持续偏低，说明承诺时限与修复产能之间存在缺口，需要调整分派节奏、时限设定或修复资源；如果及时率稳定，说明修复流程在时效上是可控的。
这个指标与缺陷密度、遗留缺陷数分工不同。缺陷密度反映单位代码或功能规模上的缺陷数量，指向质量投入是否充分；遗留缺陷数反映统计时点尚未关闭的缺陷存量，指向交付风险；修复及时率只关注时间维度，即到期应完成的缺陷中有多少在时限内完成并通过验证。三者不能互相替代，也不宜合并成一个综合分。
修复及时率适合用于过程改进，不适合直接作为个人绩效排名依据。缺陷的严重级别、复现难度、依赖条件差异很大，按个人汇总比率容易把分派不均、时限设定差异误读为个人能力差异。更合理的用法是按项目、版本或严重级别分组观察趋势，把比率变化作为讨论流程问题的起点。
分子分母怎么定：指标与统计范围
缺陷修复及时率的公式为：
缺陷修复及时率 = 统计周期内按时完成修复并通过验证的缺陷数 ÷ 同期应完成修复的缺陷数 × 100%
单位是百分比，保留一位或两位小数即可，不必追求更高精度。分子和分母必须来自同一批缺陷样本、同一统计周期和同一套时限规则，否则比率没有意义。
| 项目 | 定义 | 说明 |
|---|---|---|
| 分子 | 统计周期内按时完成修复并通过验证的缺陷数 | 同时满足两个条件：在承诺时限内完成修复，且验证结论为通过 |
| 分母 | 统计周期内到期应完成修复的缺陷数 | 按到期日归属周期，包含已按时完成、超期完成和期末仍未完成的到期缺陷 |
| 纳入范围 | 缺陷类型工作项，指定项目或版本，指定严重级别 | 严重级别可分档统计，也可合并统计，但同一报表内口径保持一致 |
| 排除项 | 重复单、需求变更单、明确挂起或延期审批通过的单 | 排除理由需在报表中注明，便于复算 |
严重级别分档是常见做法。可以为致命、严重、一般、轻微分别设定承诺修复时限，再分别计算各档及时率，也可以按缺陷数加权合并。分档统计的好处是避免大量轻微缺陷拉高整体比率，掩盖严重缺陷的修复延迟。
重复单应在确认重复后关闭并排除，不能既保留在原统计中又计入分母。需求变更单、优化建议等非缺陷类型工作项不进入样本。明确挂起或经延期审批通过的缺陷，在挂起或延期期间不计入到期应完成数，恢复后按新的到期日重新归属周期。
时间口径与数据来源
及时率的差异往往来自时间口径，而不是修复本身。起算点、截止点、完成时点三个字段必须先定义，并在全周期、全项目统一。
| 时间字段 | 可选口径 | 使用建议 |
|---|---|---|
| 起算时间 | 缺陷提交时间，或确认受理时间 | 二选一，全部缺陷统一使用同一口径；用提交时间更贴近用户感知，用受理时间更贴近团队责任起点 |
| 截止时间 | 起算时间加承诺修复时限 | 按严重级别分档设定，单位可用小时或工作日，需明确是否扣除节假日 |
| 完成时点 | 修复提交并通过验证的时间 | 取验证通过的时间戳，不取状态改为“已修复”的时间 |
数据来源是缺陷跟踪系统中的状态流转记录和验证记录。每条缺陷需要能取到起算时间、承诺时限、验证通过时间三个值，以及严重级别、所属项目或版本、当前状态。若系统只记录状态变更时间而不区分“已修复”和“已验证”，完成时点会被提前，及时率被高估。
跨项目比较时，需统一工作日历、时区和节假日规则。一个项目按自然日计算、另一个按工作日计算，同样的时限会产生不同的到期日，比率不可直接对比。统计周期本身也应固定，例如按自然月或按迭代周期，避免周期长度不同带来的波动。
计算步骤与边界情况处理
计算可以按以下步骤执行，每一步都留下可复核的中间结果：
- 取数：从缺陷跟踪系统导出统计周期内的缺陷工作项，包含严重级别、起算时间、承诺时限、验证结论、验证通过时间、当前状态。
- 按口径过滤：剔除重复单、非缺陷单、挂起或延期审批通过的单，保留纳入范围内的缺陷。
- 计算单条是否按时：用验证通过时间与截止时间比较，通过时间不晚于截止时间且验证结论为通过，记为按时；否则记为未按时。
- 汇总分子分母：分子为按时缺陷数，分母为到期应完成缺陷数。
- 计算比率：分子除以分母乘以100%，保留约定小数位。
边界情况需要事先约定规则：
- 分母为零：统计周期内没有到期应完成的缺陷时，报告“无到期缺陷”，不写0%或100%。这两个数值都会被误读为修复表现。
- 期末仍未关闭的到期缺陷：计入分母，不计入分子。它们已经到期但未完成验证，属于未按时。
- 跨周期缺陷：按到期日归属统计周期，而不是按提交日或关闭日。到期日在周期内、完成在周期外的缺陷，计入该周期分母且不计入分子。
- 验证不通过被重开：以最终通过验证的时间判定是否按时。中间某次修复提交时间不作为完成时点。
- 时限变更：经审批调整承诺时限的缺陷，按调整后的截止时间判定，并在报表中标注变更数量。
一个可复算的例子
假设某项目按自然月统计，起算时间取缺陷提交时间，承诺修复时限为：致命8小时、严重24小时、一般72小时，均按工作日计算。某月到期应完成的缺陷共20条，样本构成与判定如下（示例数据，仅用于演示计算过程）：
| 类别 | 数量 | 判定依据 | 计入分子 | 计入分母 |
|---|---|---|---|---|
| 按时修复并通过验证 | 13 | 验证通过时间不晚于截止时间 | 13 | 13 |
| 超期完成但验证通过 | 3 | 验证通过时间晚于截止时间 | 0 | 3 |
| 期末仍未完成验证 | 2 | 已到期，未取得验证通过时间 | 0 | 2 |
| 验证不通过后重开、最终按时通过 | 2 | 以最终通过验证时间判定，未超过截止时间 | 2 | 2 |
| 重复单（已确认并关闭） | 2 | 剔除，不进入样本 | — | — |
| 延期审批通过 | 1 | 剔除，按新到期日归属后续周期 | — | — |
分子为13加2，等于15；分母为13加3加2加2，等于20。缺陷修复及时率为15除以20乘以100%，等于75%。被剔除的3条样本不计入分子分母，但应在报表附注中说明剔除数量和理由，便于他人复算。
如果按严重级别分档，可以进一步看到致命缺陷的及时率与一般缺陷的及时率是否接近。若整体75%主要由一般缺陷贡献，而严重缺陷存在超期，整体比率会掩盖需要优先处理的问题。
结果怎么读：解读与限制
及时率是一个流程时效指标，比率高低本身不说明修复质量或产品质量。解读时需要结合几个条件：
- 时限设置是否合理：时限过宽会让及时率虚高，时限过紧会让团队疲于应付。可以观察时限调整记录和超期缺陷的分布。
- 样本构成：只统计低难度缺陷、或大量轻微缺陷占多数时，比率会偏高。按严重级别分档观察更可靠。
- 配套指标：与平均修复时长、重开率、遗留缺陷数一起看。及时率高但重开率也高，说明修复提交快而验证不扎实；及时率高但遗留缺陷数上升，说明到期缺陷被快速关闭而新增缺陷在积累。
- 样本量：单月到期缺陷只有几条时，比率会因一两条缺陷大幅波动。样本量小时宜报告分子分母原始数，或用滚动多周期合并计算，避免只呈现百分比。
及时率反映的是从缺陷进入到验证通过这一段流程的时效，不覆盖缺陷发现前的预防活动，也不代表缺陷本身的严重程度分布是否合理。把它作为过程改进的观察窗口，比作为结论性评价更合适。
在缺陷跟踪工具中落地统计
上述口径要稳定执行，需要缺陷工作项具备相应字段，状态流转能区分修复与验证两个节点。落地时可以先检查字段与流转，再决定统计方式。
| 落地要素 | 需要具备的内容 | 作用 |
|---|---|---|
| 缺陷字段 | 严重级别、提交时间、承诺时限、验证结论、验证通过时间 | 支撑起算、截止、完成三个时点的取数 |
| 状态流转 | 区分“已修复”与“已验证”，保留各节点时间戳 | 避免把修复提交时间误当完成时点 |
| 统计方式 | 按周期导出缺陷明细复算，或通过报表按项目、版本、严重级别汇总 | 得到分子分母并保留可复核记录 |
ONES 测试管理提供覆盖全生命周期的缺陷管理，缺陷可关联至迭代，支持一键创建并关联缺陷，团队成员围绕缺陷协作处理；同时可为测试活动生成多维度测试报告。ONES Project 支持缺陷跟踪管理，与 TestCase 数据互通，可一键提交 Bug 至对应项目或迭代，记录和跟踪缺陷修复情况，并提供多种图表形态的报表，支持自定义数据范围和维度。这些能力可以承载缺陷字段、状态流转和按周期汇总的统计动作。
落地时建议先用一个周期导出缺陷明细，按本文口径手工复算一次，核对系统报表结果与手工结果是否一致。重点确认三点：承诺时限是否按严重级别正确套用，完成时点是否取验证通过时间，分母是否只包含到期应完成的缺陷。核对通过后，再把复算规则固化为报表或定期导出流程，并在报表中保留剔除样本的说明。
常见问题
承诺修复时限应该按自然日还是工作日计算？
两种都可以，关键是同一报表内全部缺陷使用同一规则，并在报表中注明。按工作日计算更贴近团队实际可用的修复时间，但需要明确节假日和调休的处理方式；按自然日计算取数简单，跨周末的缺陷会显得时限更紧。跨项目对比时，如果各项目的工作日历不同，应先把时限统一折算到同一基准，再比较及时率。
缺陷在统计期末还没修复完，这个周期要不要算它？
要看它是否已经到期。到期日落在本统计周期内的缺陷，即使期末仍未完成验证，也计入分母、不计入分子，按未按时处理；到期日在下一个周期的缺陷，归入下一个周期统计。这样处理可以避免期末未完成的缺陷被推迟到下期而虚高本期比率。
缺陷被重开后，完成时间以哪一次为准？
以最终通过验证的时间为准。中间某次修复提交或状态改为已修复的时间都不作为完成时点。如果最终通过验证的时间晚于承诺截止时间，这条缺陷记为未按时；如果重开后的修复仍在时限内通过验证，则记为按时。为了让这条规则可执行，缺陷状态流转需要保留每次验证的时间戳。
及时率算出来偏低，应该先调整时限还是先查流程？
先看超期缺陷的分布再决定。如果超期集中在某个严重级别或某个环节，例如验证排队时间长、分派不及时，优先改流程；如果各档普遍超期且时限明显短于同类缺陷的历史修复时长，再考虑调整时限设定。直接放宽时限会让比率上升，但不改变实际修复节奏，下一周期问题仍会重现。
在ONES里能否直接得到这个比率，还是需要导出后自己算？
ONES 测试管理提供覆盖全生命周期的缺陷管理，缺陷可关联至迭代，并可为测试活动生成多维度测试报告；ONES Project 支持缺陷跟踪管理，提供多种图表形态的报表，支持自定义数据范围和维度。是否内置修复及时率这一比率指标，需要按实际环境确认。稳妥的做法是先导出缺陷明细，按本文口径手工复算一个周期，核对承诺时限套用、完成时点取值和分母范围三项无误后，再把复算规则固化为报表或定期导出流程。
