缺陷复测通过率、失败率和平均复测周期要算得可比，关键在于先固定“复测事件”的口径：一次复测指缺陷修复提交后由验证角色执行的一次验证动作，记录该次结论和完成时间。三个指标共用这批已复测记录，再分别确定分母、时间窗和单位。下面给出可直接落地的统计范围、字段要求、计算公式和算例，并说明指标异常时如何解读。
要点总览（TL;DR）
- 三个指标共用同一批“已复测缺陷”记录：先定义一次复测为修复提交后由验证角色执行的一次验证动作，记录结论与完成时间。
- 复测通过率=结论为通过的次数÷复测总次数；复测失败率=结论为不通过的次数÷同一分母；两者之和不足100%的差额是待验证或结论缺失。
- 平均复测周期=各缺陷（复测完成时间−修复提交时间）之和÷完成复测的缺陷数，需注明时间窗按复测完成时间还是修复提交时间筛选，以及多轮复测取首轮还是末轮。
- 分母为零时显示“无数据”而非0%；小样本下通过率波动大，适合看趋势，不适合横向比较。
- 指标异常要结合分母规模、缺陷分布和流程节点交叉验证，单指标不能直接归因为质量或效率问题。
评估目标：复测指标要回答哪三个问题
复测指标服务于缺陷修复到验证这一段流程的判断，三个指标各自回答一个独立问题，合起来才能支撑决策。
- 复测通过率回答“修复提交后一次验证就能通过的比例有多高”，反映修复提交的质量和验证环节的顺畅程度。
- 复测失败率回答“验证不通过、需要再次修复的比例有多高”，与通过率互为补充，用于识别返工压力。
- 平均复测周期回答“从修复提交到验证完成平均要等多久”，反映验证环节的响应速度和流转效率。
指标使用者通常是测试负责人、研发负责人和项目经理。测试负责人关注失败率背后的修复质量问题，研发负责人关注周期是否被验证排队拖长，项目经理关注整体流转是否卡在某个节点。使用场景包括迭代复盘、质量周报和流程改进立项。
需要区分复测指标与回归测试管理的边界。复测指标只覆盖“单个缺陷修复后是否验证通过、验证花了多久”，不评价变更后的整体回归范围是否充分，也不衡量测试用例覆盖率。回归测试管理关注变更影响面和用例执行，复测指标关注缺陷个体的验证结果，两者数据来源和使用目的不同，不宜混在同一张报表里下结论。
指标与范围：统计对象、时间窗与单位
口径漂移是复测指标最常见的失真来源。同一批数据换一个时间窗或换一种计数方式，通过率可能相差十几个百分点。统计前需要把以下四项写成书面定义，并在报表上注明。
| 口径项 | 建议定义 | 需要注明的条件 |
|---|---|---|
| 纳入缺陷 | 统计期内发生过至少一次复测事件的缺陷 | 排除未修复、未提交验证的缺陷 |
| 排除缺陷 | 撤销、重复、转为需求、非缺陷类工单 | 排除规则需固定，不随报表调整 |
| 复测事件 | 修复提交后由验证角色执行的一次验证动作，含结论与完成时间 | 同一缺陷多次复测按事件逐条记录 |
| 时间窗 | 按复测完成时间落入统计期筛选 | 与按修复提交时间筛选的结果不同，需二选一并注明 |
| 周期单位 | 小时或天，保留一位小数 | 跨天按自然时间计算，声明是否扣除节假日 |
时间窗的选择直接影响结果。按复测完成时间筛选，统计的是“本期完成的验证”，适合看验证产出；按修复提交时间筛选，统计的是“本期提交修复的缺陷最终验证结果”，适合看修复质量，但期末提交的缺陷可能尚未验证，需要单独标注未完成部分。两种口径都合理，混用则不可比。
周期单位建议与团队节奏匹配：迭代周期以天计，用天更直观；关注验证响应速度时用小时。取整方式统一为四舍五入保留一位小数，避免不同报表精度不一致。
数据口径与证据：从缺陷记录中取哪些字段
三个指标依赖的字段不多，但每个字段的完整性决定结果是否可信。计算前先确认缺陷记录中能稳定取到以下信息。
| 字段 | 用途 | 质量要求 |
|---|---|---|
| 缺陷编号 | 关联多次复测记录 | 唯一且不重复 |
| 修复提交时间 | 计算周期的起点 | 取最近一次修复提交的时间 |
| 复测结论 | 区分通过、不通过 | 枚举值固定，不允许自由文本 |
| 复测完成时间 | 计算周期的终点、确定时间窗归属 | 每次复测都有独立时间 |
| 验证人/角色 | 确认由验证角色执行 | 与开发角色可区分 |
| 缺陷状态 | 判断是否纳入、是否撤销 | 状态流转有记录 |
同一缺陷多次复测时，每条复测记录单独成行，保留轮次序号。这样既能按事件计数算通过率，也能按缺陷取首次或末次结论做另一种口径。两种口径结果不同，报表中必须固定一种并注明，不能在同一张图里混用。
缺失值和特殊状态按以下规则处理：复测结论为空的记录计入分母但单列为“待验证/结论缺失”，不计入通过也不计入失败；缺陷被撤销或判定为重复的，整条记录从统计中剔除；验证不通过后缺陷退回重开、再次修复提交的，新一轮复测作为新事件计入。数据完整性核验可以做三项检查：复测完成时间早于修复提交时间的记录数应为零；结论为空的记录占比应可解释；同一缺陷的复测轮次序号应连续无跳号。
这些字段和状态流转需要在缺陷跟踪工具中稳定记录。ONES Project 支持一键提交 Bug 至对应项目或迭代，记录和跟踪缺陷修复情况，并提供缺陷状态分布统计；ONES 测试管理解决方案覆盖缺陷的全生命周期管理，缺陷可关联至迭代。把修复提交、复测结论和复测完成时间作为必填项配置在状态流转中，上述字段就能从系统中直接导出，减少手工补录带来的口径偏差。
计算步骤：三个指标的公式与分母
三个指标共用同一批复测事件，公式如下。计算时先按时间窗筛出记录集，再分别套用。
| 指标 | 公式 | 分母 | 单位 |
|---|---|---|---|
| 复测通过率 | 结论为通过的复测次数 ÷ 复测总次数 × 100% | 时间窗内全部复测事件数 | 百分比 |
| 复测失败率 | 结论为不通过的复测次数 ÷ 复测总次数 × 100% | 与通过率相同 | 百分比 |
| 平均复测周期 | 各缺陷（复测完成时间 − 修复提交时间）之和 ÷ 完成复测的缺陷数 | 时间窗内完成复测的缺陷数 | 小时或天 |
通过率与失败率分母相同、分子互补，两者之和不一定等于 100%，差额是待验证或结论缺失的部分。报表中应把这三部分同时展示，否则读者容易把差额误读为失败。平均复测周期的分母是缺陷数而非复测次数，同一缺陷多轮复测只计一次，取该缺陷首次复测完成的时间计算周期；若关注返工后的总耗时，可另设“末次复测周期”作为补充指标，但需单独命名。
分母为零时，比率类指标显示为“无数据”，不显示 0%。0% 会被误读为全部失败或全部通过，而实际含义是统计期内没有复测记录。平均复测周期在无完成复测时同样显示“无数据”。
算例：一批缺陷的复测指标计算
以下为演示情景，数据为构造值，用于说明计算过程。
某迭代统计期内共有 8 个缺陷发生复测，复测事件合计 10 次，其中 6 次结论为通过，3 次为不通过，1 次结论缺失。缺陷 D3 经历两轮复测，首轮不通过、次轮通过；缺陷 D7 的复测结论尚未填写。
| 缺陷 | 修复提交时间 | 复测完成时间 | 结论 | 周期（小时） |
|---|---|---|---|---|
| D1 | 第1天 09:00 | 第1天 15:00 | 通过 | 6 |
| D2 | 第1天 10:00 | 第2天 10:00 | 通过 | 24 |
| D3 首轮 | 第1天 11:00 | 第1天 17:00 | 不通过 | 6 |
| D3 次轮 | 第2天 09:00 | 第2天 12:00 | 通过 | 3 |
| D4 | 第2天 14:00 | 第3天 11:00 | 不通过 | 21 |
| D5 | 第3天 09:00 | 第3天 18:00 | 通过 | 9 |
| D6 | 第3天 10:00 | 第4天 16:00 | 通过 | 30 |
| D7 | 第4天 09:00 | 第4天 15:00 | 缺失 | 6 |
| D8 | 第4天 11:00 | 第5天 10:00 | 不通过 | 23 |
按复测事件口径计算：通过率 = 6 ÷ 10 = 60.0%；失败率 = 3 ÷ 10 = 30.0%；结论缺失占 10.0%。三项相加为 100%，说明分母拆分完整。
按缺陷口径计算平均复测周期：完成复测的缺陷为 D1 至 D8 共 8 个，D3 取首轮完成时间计算周期 6 小时。周期之和 = 6 + 24 + 6 + 21 + 9 + 30 + 6 + 23 = 125 小时，平均复测周期 = 125 ÷ 8 ≈ 15.6 小时。若改用 D3 次轮的 3 小时，周期之和变为 122 小时，平均值约 15.3 小时，差异来自多轮复测的取值规则，因此报表必须注明取首轮还是末轮。
结果解读：60% 的通过率意味着每 10 次复测有 3 次需要返工，返工压力集中在 D3、D4、D8 三个缺陷上；平均 15.6 小时的周期中，D6 的 30 小时和 D2 的 24 小时明显高于中位数，说明个别缺陷的验证等待时间拉高了均值，需要看分布而非只看平均值。
指标异常说明什么：常见偏离的解读与限制
指标偏离是线索，不是结论。解读时先看分母规模，再看分布，最后回到流程节点找证据。
| 现象 | 可能原因 | 验证方向 |
|---|---|---|
| 通过率偏低 | 修复不彻底、复现步骤不清、验证环境与开发环境不一致、缺陷描述歧义 | 抽查不通过记录的退回原因分类，看是否集中在某类缺陷或某个模块 |
| 失败率偏高 | 与通过率偏低同源，另需关注是否把需求变更误记为复测失败 | 核对失败记录中缺陷状态是否被正确重开，排除状态误操作 |
| 平均周期偏长 | 验证排队、验证人力不足、缺陷集中在迭代末期提交、跨团队交接等待 | 按提交日期分组看周期分布，确认是否集中在特定时间段 |
| 平均周期偏短 | 验证走过场、复测记录补录、只统计了简单缺陷 | 结合通过率一起看，周期短且通过率异常高时需抽查记录真实性 |
分母规模决定指标的可信度。统计期内只有 5 次复测时，一次结论变化就能让通过率波动 20 个百分点，这类小样本结果适合看趋势而不适合做横向比较。样本代表性还受缺陷分布影响：如果本期缺陷集中在某个新模块，通过率偏低可能反映该模块的成熟度，不能直接推及整体质量。
单指标不能作为因果结论。通过率下降可能来自修复质量，也可能来自验证标准收紧或缺陷提交质量变化，需要结合缺陷分布、退回原因分类和流程节点记录交叉验证。建议的做法是把三个指标与缺陷按模块、按提交阶段的分布放在一起看，再对照复测环节的排队时长和验证人力投入，形成可追溯的解释链。
这些交叉分析依赖缺陷记录中状态、结论和时间字段的完整留存。ONES 为测试活动自动生成多维度测试报告，并提供灵活的报告模板；ONES Project 支持自定义数据范围和维度进行度量，用多种图表呈现项目表现。团队可以按上述口径配置复测事件的数据范围和统计维度，把通过率、失败率与周期分布放在同一份报告中对照查看，减少手工汇总时的口径不一致。
常见问题
同一缺陷经历多轮复测，通过率按事件算还是按缺陷算？
两种口径都成立，但结果不同，报表中必须固定一种并注明。按事件算，每次复测单独计入分母，能反映验证动作的整体返工压力；按缺陷算，每个缺陷只取首次或末次结论，能反映缺陷最终是否修复成功。如果团队关注修复提交质量，按事件算更敏感；如果关注缺陷关闭情况，按缺陷算更直观。混用会让同一批数据得出不同通过率，因此建议在指标定义文档中写明口径，并在报表标题或脚注中标注。
统计期内复测记录很少，指标还能用吗？
可以用来看趋势，不适合做横向比较或下强结论。统计期内只有五六次复测时，一次结论变化就能让通过率波动十几个百分点，样本代表性不足。此时建议把统计窗口拉长到能覆盖足够复测事件的周期，或者把多个迭代的数据合并后再看。同时要说明样本量，让读者知道指标背后的分母规模，避免把小数量的波动当成质量变化。
复测结论为空或缺陷被撤销，应该计入分母吗？
结论为空的记录计入分母，但单列为“待验证/结论缺失”，不计入通过也不计入失败，这样通过率与失败率之和不足100%的差额就有明确解释。缺陷被撤销、判定为重复或转为需求的，整条记录从统计中剔除，剔除规则需要固定，不随报表调整。验证不通过后缺陷退回重开、再次修复提交的，新一轮复测作为新事件计入，轮次序号应连续可查。
平均复测周期偏长，应该先查什么？
先看分布再看均值。按提交日期或模块分组，确认周期偏长是否集中在特定时间段或特定模块；如果集中在迭代末期提交的缺陷，可能是验证排队或验证人力不足；如果集中在跨团队交接的缺陷，可能是交接等待。均值容易被个别长周期缺陷拉高，建议同时看中位数和分位数。周期偏短时则要结合通过率一起看，周期短且通过率异常高时需抽查复测记录是否真实执行。
在缺陷跟踪工具中怎么保证这些字段能稳定导出？
把修复提交时间、复测结论和复测完成时间配置为状态流转中的必填项，结论使用固定枚举值而非自由文本，验证人角色与开发角色可区分。ONES Project 支持一键提交 Bug 至对应项目或迭代，记录和跟踪缺陷修复情况，并提供缺陷状态分布统计；ONES 测试管理解决方案覆盖缺陷全生命周期管理，缺陷可关联至迭代。团队可以在此基础上按本文口径配置数据范围和统计维度，减少手工补录带来的口径偏差。
