测试时间被压缩后，团队常凭感觉判断“测得少了、风险高了”，却难以说清少了多少、风险高到什么程度。量化评估要把时间不足拆成三层：投入缺口（计划工时与实际可用工时之差）、覆盖损失（需求、用例和风险加权覆盖率的下降）、风险后果（缺陷逃逸概率与数量的上升区间）。结论以区间和条件表达，服务于发布决策或过程复盘，避免用单一覆盖率替代质量判断。
要点总览（TL;DR）
- 把测试时间不足拆成投入缺口、覆盖损失、风险后果三层分别量化：时间压缩率反映资源变化，需求覆盖率、用例执行覆盖率和风险加权覆盖率反映少测了什么，历史逃逸密度乘以未覆盖暴露量估算发布后缺陷区间。
- 核心公式：时间压缩率=（计划测试工时−实际可用测试工时）÷计划测试工时；风险加权覆盖率=Σ（各风险等级已执行用例数×权重）÷Σ（各风险等级计划用例数×权重）；逃逸风险=历史逃逸密度区间×未覆盖暴露量。
- 三类指标必须在同一需求基线、同一时间窗、同一严重级别口径下比较，结论写成区间加条件，例如“预计发布后缺陷1至1.4条，前提是观察窗口与历史版本一致”。
- 覆盖率与逃逸风险的相关性不等于因果，跨版本比较前要确认用例粒度、风险权重和严重级别定义未变；发布后用实际逃逸缺陷数回溯校验，持续偏离区间时校准权重或密度。
- 分母为零或样本过少时不强行计算比率，改为报告绝对数量并标注样本不足；不设通用达标线，内部参考线用于发现异常，不替代发布评审。
评估目标：时间不足要回答哪三个问题
量化评估的第一步是明确要回答什么，否则容易把工时、覆盖率和缺陷数混在一起讨论。建议把评估目标分成三层，每层对应一个可独立计算的问题。
第一层是投入缺口：计划投入多少测试工时，实际可用多少，压缩比例和缺口绝对值分别是多少。这一层只描述资源变化，不涉及质量判断，是后续换算的输入。
第二层是覆盖损失：在压缩后的工时下，需求覆盖率、用例执行覆盖率和风险加权覆盖率分别下降了多少，哪些高风险需求或场景没有被执行到。这一层回答“少测了什么”。
第三层是风险后果：基于历史缺陷逃逸数据，估算本次未覆盖部分可能带来的发布后缺陷数量区间。这一层回答“可能漏出多少问题”。
评估用途决定结论的表达方式。用于发布决策时，结论应写成“在当前需求基线和严重级别口径下，预计发布后缺陷数落在某区间，高风险模块的覆盖缺口集中在某几项需求”，并附上可接受与否的判断条件。用于过程改进时，结论应聚焦缺口成因，例如哪类用例因时间不足被优先舍弃、风险权重设置是否合理。两种用途都需要给出对比基线，例如与上一个版本或同类项目的计划值对比，单独一个版本的覆盖率数字难以解读。
指标与范围：覆盖率与逃逸风险的指标定义
指标定义要写到可以复算的程度：每个指标有明确公式、分子、分母、单位和统计时间窗。下表给出本文使用的指标口径，实际使用时可按团队情况调整权重，但同一轮评估内必须保持一致。
| 指标 | 公式 | 分子 | 分母 | 单位与时间窗 |
|---|---|---|---|---|
| 时间压缩率 | （计划测试工时 − 实际可用测试工时）÷ 计划测试工时 | 工时缺口 | 计划测试工时 | 人时；本版本测试周期 |
| 需求覆盖率 | 已执行验证的需求数 ÷ 需求基线总数 | 至少有一条关联用例执行并通过的需求数 | 本版本需求基线中的需求总数 | 百分比；本版本测试周期 |
| 用例执行覆盖率 | 已执行用例数 ÷ 计划用例数 | 状态为已执行的用例数 | 测试计划中纳入本版本的用例数 | 百分比；本版本测试周期 |
| 风险加权覆盖率 | Σ（各风险等级已执行用例数 × 风险权重）÷ Σ（各风险等级计划用例数 × 风险权重） | 按风险等级加权的已执行用例 | 按风险等级加权的计划用例 | 百分比；本版本测试周期 |
| 历史缺陷逃逸密度 | 发布后发现的缺陷数 ÷ 发布前执行的用例数 | 发布后一定窗口内发现的缺陷数 | 对应版本发布前执行的用例数 | 缺陷数/千用例；取近若干版本滚动窗口 |
范围界定同样影响可比性。需求基线要锁定版本冻结时的需求清单，测试中途新增的需求单独标注，不计入分母或单独计算。严重级别按团队统一定义，例如致命、严重、一般、轻微四级，逃逸缺陷只统计达到约定级别以上的缺陷。环境和版本范围要写明，例如只统计生产环境或预发环境发现的问题，测试环境内发现的不算逃逸。风险权重可按业务影响和失效概率设定，例如致命级用例权重为5、严重级为3、一般为1，权重一旦确定，跨版本比较时保持不变。
数据口径与证据：从哪些记录取数
指标能否复算，取决于取数字段是否稳定。工时数据通常来自项目计划或工时记录，需要区分计划测试工时和实际可用测试工时，后者要扣除被会议、支持、返工占用的时间。用例数据来自测试用例库和测试计划，关键字段包括用例所属需求、风险等级、执行状态和执行时间。缺陷数据来自缺陷单，关键字段包括发现阶段（发布前或发布后）、严重级别、关联版本和关联需求。
同一需求基线与版本对齐是取数的核心动作。需求、用例、缺陷三类记录都要带上版本标识或迭代标识，按同一标识关联，避免把上个版本遗留的用例算进本版本分母。跨版本缺陷按发现版本归属，修复版本不作为统计依据。重复缺陷需要合并，同一根因在多个模块报出的缺陷只计一条，合并规则在评估前写明。
缺失值的处理要提前约定。工时记录缺失时，用同类任务的历史均值估算并标注为估算值；用例执行状态缺失时，按未执行计入分母，避免高估覆盖率；缺陷严重级别缺失时，单独列出不计入分级统计。样本过少时，例如近三个版本发布后缺陷总数不足十条，逃逸密度波动很大，此时报告绝对数量并标注样本不足，不强行给出比率。
这些取数动作分散在需求、用例、计划和缺陷多个工作项中。ONES 测试管理支持测试用例与需求、任务关联，测试计划与迭代关联，未通过的用例可快速创建缺陷任务并在测试与研发团队间流转，质量统计报表和测试报告模板可用于汇总执行与缺陷分布。工时字段、覆盖率与逃逸密度的具体指标口径是否内置，需要按实际配置核验，未内置的部分可从原始记录导出后按本文公式计算。
计算步骤：从时间缺口到风险估算
计算按顺序进行，前一步的输出是后一步的输入。建议固定顺序，避免反复调整口径导致结果不可比。
第一步，计算时间压缩率与工时缺口。时间压缩率 =（计划测试工时 − 实际可用测试工时）÷ 计划测试工时，同时记录缺口绝对值。缺口绝对值用于换算未执行用例数：未执行用例数约等于缺口工时 ÷ 单条用例平均执行工时。单条用例平均执行工时取历史均值，样本不足时用中位数。
第二步，按风险等级加权计算覆盖率。先算需求覆盖率和用例执行覆盖率作为基础口径，再算风险加权覆盖率。风险加权覆盖率更能反映时间压缩的实际影响：如果被舍弃的用例集中在低风险等级，加权覆盖率的下降会明显小于用例执行覆盖率；如果高风险用例被跳过，加权覆盖率会快速下降。两个口径同时报告，差异本身就是信息。
第三步，估算逃逸风险区间。先算历史逃逸密度，取近若干版本的滚动值，得到密度区间而非单点。再估算本次未覆盖的风险暴露量，可用未执行用例数乘以高风险用例占比，或用未覆盖需求数乘以单需求历史缺陷密度。风险估算值 = 历史逃逸密度区间 × 未覆盖暴露量，结果写成区间。区间上下限来自密度区间的上下限，暴露量本身的不确定性可在结论中作为条件说明。
第四步，处理异常情况。分母为零时不计算比率，改为报告绝对数量，例如计划用例为零说明测试计划未建立，属于流程问题而非覆盖率问题。样本过少时只报告绝对值和区间宽度，并注明不足以支撑趋势判断。风险权重未经校准的版本，加权覆盖率只作参考，不与历史版本直接比较。
算例：一次压缩两周的测试窗口
以下为演示情景，数值为假设，用于说明公式代入过程。
某版本原计划测试周期四周，计划测试工时800人时。因上游延期，实际可用测试工时压缩为480人时，压缩两周。需求基线共60条需求，计划用例400条，实际执行260条。用例按风险分级：致命级40条、严重级120条、一般级240条，权重分别为5、3、1。近三个版本发布后共发现缺陷45条，对应发布前执行用例共9000条。
时间压缩率 =（800 − 480）÷ 800 = 40%，工时缺口320人时。按单条用例平均执行工时1.2人时估算，缺口约对应267条用例未执行，与实际未执行的140条相比偏大，说明部分缺口被加班或并行执行吸收，换算结果作为上限参考。
用例执行覆盖率 = 260 ÷ 400 = 65%。假设已执行用例中致命级30条、严重级80条、一般级150条，风险加权覆盖率 =（30×5 + 80×3 + 150×1）÷（40×5 + 120×3 + 240×1）=（150 + 240 + 150）÷（200 + 360 + 240）= 540 ÷ 800 = 67.5%。加权覆盖率高于执行覆盖率，说明被舍弃的用例中低风险占比较高，但致命级仍有10条未执行，这是需要单独说明的缺口。
历史逃逸密度 = 45 ÷ 9000 = 5条/千用例。取近三个版本波动范围4至6条/千用例作为密度区间。未覆盖用例140条，其中高风险（致命级与严重级）未执行50条，按高风险用例缺陷密度约为一般用例的3倍折算，风险暴露量约等于140 + 50×2 = 240条等效用例。逃逸风险估算区间 = 4至6条/千用例 × 240 ÷ 1000 ≈ 1.0至1.4条发布后缺陷。
结论可写成：本版本测试工时压缩40%，用例执行覆盖率65%，风险加权覆盖率67.5%，致命级用例缺口10条；按历史逃逸密度估算，发布后缺陷预计在1至1.4条区间，前提是发布后观察窗口与历史版本一致、严重级别口径不变。若发布决策要求发布后缺陷不超过1条，当前估算处于边界，建议补执行致命级未覆盖用例后再评估。
解读与限制：指标能说明什么、不能说明什么
覆盖率与逃逸风险的相关性不等于因果。覆盖率下降通常伴随逃逸增加，但逃逸缺陷可能来自需求理解偏差、环境差异或集成问题，这些不在用例覆盖的范围内。把覆盖率当作质量保证，会忽略未覆盖部分之外的风险来源。指标的作用是暴露缺口和排序风险，发布判断仍需结合缺陷趋势、回归结果和业务影响。
跨版本、跨团队比较有明确限制。需求基线规模、用例粒度、风险权重、严重级别定义任何一项变化，都会让覆盖率数字失去可比性。比较前要确认口径一致，口径调整的版本单独标注，不并入趋势线。不同团队的用例编写习惯差异很大，用例执行覆盖率高低更多反映用例设计风格，风险加权覆盖率在同一团队内的版本间比较更有意义。
回溯校验是校准估算的必要动作。每个版本发布后，在约定窗口内统计实际逃逸缺陷数，与预测区间对比。实际值落在区间内说明密度和暴露量估算基本可用；持续高于上限说明风险权重偏低或暴露量低估，需要上调；持续低于下限说明估算过于保守。校准按版本滚动进行，每次调整记录原因，避免频繁改动导致口径漂移。
不设通用达标线，是因为达标线依赖业务容忍度和发布节奏。金融、医疗类业务对逃逸缺陷的容忍度远低于内部工具，同一覆盖率在不同业务下的含义不同。团队可以基于历史数据设定内部参考线，例如近五个版本风险加权覆盖率的中位数，但参考线用于发现异常，不用于替代发布评审。评估结论最终以区间加条件表达，说明在什么前提下风险可接受，比给出一个覆盖率数字更有决策价值。
常见问题
计划测试工时和实际可用测试工时应该怎么记录，才能让时间压缩率可复算？
计划测试工时在版本测试计划确定时锁定，按测试任务估算并汇总，记录在测试计划或项目计划中。实际可用测试工时按人按天记录，扣除会议、线上支持、返工和其他非测试事务占用的时间，只保留真正用于设计、执行和回归的工时。
两类工时都要带版本标识，中途追加的需求单独记录，不混入原计划分母。工时记录缺失时，用同类任务的历史均值估算并在报告中标注为估算值，避免把估算值当成实测值参与跨版本趋势比较。
时间压缩后只执行了部分用例，风险加权覆盖率怎么算才不会被低风险用例拉高？
风险加权覆盖率的关键在权重设置和执行分布。先按业务影响和失效概率给用例分级，例如致命级权重5、严重级3、一般级1，权重在同一轮评估内固定。再分别统计各等级的计划用例数和已执行用例数，代入加权公式。
如果被舍弃的用例集中在低风险等级，加权覆盖率会高于用例执行覆盖率，这个差异本身说明缺口结构；如果致命级用例有未执行项，即使加权覆盖率数字不低，也要在结论中单独列出致命级缺口条数，作为发布决策的独立条件。
历史逃逸密度样本很少时，还能用来估算本次风险吗？
样本过少时，逃逸密度的波动会很大，例如近三个版本发布后缺陷总数不足十条，算出的比率参考价值有限。此时建议报告发布后缺陷的绝对数量和区间宽度，并注明样本不足以支撑趋势判断。
如果仍需要估算，可以扩大统计窗口，例如取近六到八个版本，或按业务模块分别统计密度，用模块级数据替代整体数据。无论哪种方式，结论都要写成区间并说明数据基础，不用单点值作为发布门槛。
预测的逃逸风险区间和发布后实际缺陷数对不上，应该先调整哪个参数？
先看偏差方向。实际值持续高于区间上限，通常是风险权重偏低或未覆盖暴露量被低估，可先复核高风险用例的权重设置和未执行用例的统计口径，再考虑上调历史逃逸密度。实际值持续低于下限，说明估算偏保守，可检查暴露量折算系数是否过大。
调整按版本滚动进行，每次只改一个参数并记录原因，避免多个参数同时变动导致口径漂移。连续两三个版本偏差方向一致再调整，单次偏差可能来自偶发缺陷，不急于改口径。
不同版本之间比较覆盖率数字，需要先统一哪些口径？
至少统一四项：需求基线范围（版本冻结时的需求清单，中途新增单独标注）、用例粒度（同一功能拆成几条用例的习惯保持一致）、风险权重（各等级权重值不变）、严重级别定义（逃逸缺陷统计到哪一级）。
任何一项调整过的版本单独标注，不并入趋势线。跨团队比较的限制更大，用例编写风格差异会让执行覆盖率失去可比性，风险加权覆盖率在同一团队内的版本间比较更有意义。
