要判断基于影响的回归测试是否真的缩小了范围、又没有抬高逃逸缺陷风险，需要把两个指标放在同一批变更、同一时间窗、同一分母口径下对照：范围收缩率回答“少测了多少”，逃逸缺陷率回答“漏没漏、漏了多少”。本文给出一套可复算的度量方法，覆盖指标定义、取数口径、计算步骤、示意算例与解读边界，适合正在试点影响分析选例的测试团队按季度或按版本评估。
要点总览（TL;DR）
- 范围收缩率＝（全量回归用例数−影响分析选中用例数）÷全量回归用例数，按变更逐条计算后汇总，同时报告算术平均与加权值。
- 逃逸缺陷率＝观察窗内逃逸缺陷数÷变更次数（或÷回归执行轮次），分子只计发布后发现且属于本次变更影响面内的既有功能缺陷。
- 两指标须同变更清单、同观察窗、同分母口径对照：收缩率上升且逃逸缺陷率未显著上升，才支持范围缩小未牺牲质量的结论。
- 关键证据是回溯：逐条核查逃逸缺陷是否落在被排除的用例范围内，落在排除范围内的数量与占比直接反映影响分析漏判程度。
- 未记录影响分析过程的变更单列不混入收缩率；分母为零时比率记为不可计算；样本量小时看多期趋势，不套用外部达标线。
评估目标：同时回答范围收益与质量风险
这次评估要同时验证两个命题。第一个是范围收益命题：在变更后的回归验证中，基于影响分析选出的用例数是否稳定少于全量回归用例数，且减少的部分确实属于本次变更影响不到的范围。第二个是质量风险命题：在同样的变更集合上，发布后发现的逃逸缺陷是否维持在基线水平附近，尤其要确认没有缺陷落在影响分析判定为“不受影响”而排除的区域内。
两个命题必须成对评估。只看范围收缩率，选例越激进数字越好看，但可能把关键路径排除在外；只看逃逸缺陷数，缺陷少也可能只是因为发布节奏放缓或上报不及时。把两者放在同一变更清单上，才能回答“缩小范围是否以牺牲质量为代价”。
评估对象限定为变更后既有能力的回归验证，即本次改动可能波及的已有功能是否仍然正常。新功能本身的验收测试、性能与安全专项测试不计入本次范围收缩率的分子分母，否则会把新增测试量混进回归口径。
评估周期建议按固定节奏设定，例如以一个季度为评估期，取此前一个或两个季度作为基线期。基线期应处于尚未启用影响分析选例、或选例规则稳定的阶段，两期的变更类型、模块分布和发布节奏尽量接近。周期一旦确定，两期使用相同的观察窗长度，避免评估期观察窗更长而多计逃逸缺陷。
指标与范围：范围收缩率与逃逸缺陷率怎么定义
两个指标各自回答一个问题，定义时需要把分子、分母、单位和时间窗写清楚，否则不同人算出的数字无法比较。下表给出建议口径。
| 指标 | 公式 | 分子 | 分母 | 单位与时间窗 |
|---|---|---|---|---|
| 范围收缩率 | （全量回归用例数 − 影响分析选中用例数）÷ 全量回归用例数 | 被影响分析排除的回归用例数 | 该变更对应的全量回归用例数 | 百分比，按单个变更计算后再汇总 |
| 逃逸缺陷率（按变更） | 观察窗内逃逸缺陷数 ÷ 变更次数 | 符合判定口径的逃逸缺陷数 | 纳入评估的变更次数 | 个/百次变更，观察窗自发布日起固定天数 |
| 逃逸缺陷率（按轮次） | 观察窗内逃逸缺陷数 ÷ 回归执行轮次 | 同上 | 同期回归执行轮次 | 个/百轮，适合按轮次组织的团队 |
范围收缩率按单个变更计算后汇总，建议同时报告两个汇总值：变更级收缩率的算术平均，以及“排除用例总数 ÷ 全量用例总数”的加权值。前者反映典型变更的收缩程度，后者反映整体测试工作量的节省，两者差异大时说明收缩效果集中在少数大变更上，需要单独查看这些变更的逃逸情况。
逃逸缺陷的判定口径要事先写死：发布后发现、且属于本次变更影响面内的既有功能缺陷。具体操作上，缺陷需同时满足三个条件——在生产或灰度环境被发现，对应功能在本次发布前已存在，缺陷根因可追溯到本次变更涉及的模块或调用链。不属于影响面的缺陷，例如环境问题、第三方服务故障、与本次变更无关的历史遗留问题，单列统计，不进入分子。
统计范围需要明确三件事：纳入哪些变更类型（例如功能迭代、缺陷修复、配置变更是否都算）、覆盖哪些模块或服务、观察窗多长。建议首轮评估只纳入规则最清晰的功能迭代类变更，配置变更和依赖升级单独观察；观察窗按自身缺陷发现周期设定，常见做法是发布后 14 天或 30 天，两期必须一致。
数据口径与证据：从哪里取数、如何保证可比
这套度量依赖三类记录互相关联，取数前先确认字段是否齐全。
- 用例选取记录：变更单编号、全量回归用例数、影响分析选中用例数、排除用例清单及排除理由、分析人、分析时间。缺少排除清单时，收缩率只能算总数，无法做逃逸回溯。
- 变更记录：变更单编号、所属模块、变更类型、变更规模（例如改动文件数、涉及需求数）、发布时间、关联的回归执行轮次。
- 缺陷记录：缺陷编号、发现环境、发现时间、关联变更单或发布版本、根因模块、是否属于既有功能。
可比性检查是结论成立的前提。对比两期数据前，先核对三项分布：变更类型构成是否接近，模块分布是否偏移，单变更平均规模是否相差过大。如果评估期集中上线了几个大型重构，收缩率和逃逸率都会被少数变更主导，此时应按模块或变更规模分层比较，而不是直接比总比率。发布频次差异同样影响逃逸缺陷的暴露机会，发布越频繁，观察窗内可发现的缺陷越多，需要在解读时说明。
缺失值处理遵循“不混入、单列报”的原则。没有记录影响分析过程的变更，无法判断其用例是主动排除还是本来就没选，这类变更不进入收缩率计算，单独统计数量并在报告中说明占比；占比过高时，收缩率结论的可信度要打折扣。缺陷记录缺少关联变更单的，先通过版本和模块做匹配，仍无法匹配的归入“未归属”单列，不强行计入逃逸分子。
分母为零的情况分两种。某期没有变更时，收缩率和逃逸缺陷率都记为不可计算，只报告绝对数；某期有变更但观察窗内没有逃逸缺陷时，逃逸缺陷率记为零，这是有效数据，应正常参与趋势比较，不能当作缺失值剔除，否则会系统性高估逃逸水平。
计算与评估步骤：从取数到结论的五步
以下五步可以按顺序复算，每一步都产出可核对的中间结果。
第一步，锁定变更清单与两期边界。确定基线期和评估期的起止日期，从变更记录中导出两期全部变更单，剔除未上线、回滚且未重新发布、以及不属于评估范围的变更类型。产出两期变更清单及各自数量，作为后续所有比率的分母基础。
第二步，逐变更计算收缩率。对评估期每条变更，取全量回归用例数和影响分析选中用例数，代入公式得到单变更收缩率；同时记录排除用例清单。汇总时给出算术平均收缩率和加权收缩率，并统计未记录影响分析过程的变更占比。基线期若未做影响分析，收缩率按零处理，仅作为对照说明。
第三步，按观察窗统计逃逸缺陷。对两期每条变更，从发布日起截取固定长度的观察窗，收集窗内发现的缺陷，按判定口径筛选出逃逸缺陷，计算每百次变更逃逸数。同时记录缺陷的根因模块和关联变更，供第四步回溯使用。
第四步，逐条回溯逃逸缺陷。对每条逃逸缺陷，找到对应变更当时的排除用例清单，判断该缺陷所涉功能是否在被排除的用例覆盖范围内。结果分三类：落在排除范围内，说明影响分析漏判，是范围收缩的直接代价；落在选中用例范围内但用例未发现，属于用例有效性或执行问题；无法归属，单列待查。第一类的数量和占比是判断“缩小范围是否安全”的关键证据。
第五步，联合判定。把收缩率与逃逸缺陷率放在一起看：收缩率明显上升、逃逸缺陷率与基线期相比未显著上升、且第一类回溯结果很少或为零，可以判定范围确实缩小且质量未受损；收缩率上升但逃逸缺陷率同步上升，或第一类回溯结果集中出现，说明排除逻辑存在系统性偏差，需要回补范围并修正影响分析规则；收缩率没有变化，则说明影响分析尚未真正作用于选例，应先检查流程执行而非调整指标。
例子：一个季度的对照计算
以下数值均为示意，用于演示公式代入和结论形成过程，不代表任何真实团队数据。
假设基线期为第一季度，评估期为第二季度，两期均纳入功能迭代类变更，观察窗为发布后 14 天。基线期 40 次变更，全量回归用例合计 8000 条，未启用影响分析，收缩率记为 0；观察窗内逃逸缺陷 6 个，逃逸缺陷率为 6 ÷ 40 × 100 = 15 个/百次变更。评估期 50 次变更，全量回归用例合计 10000 条，影响分析选中 6500 条，排除 3500 条，加权收缩率为 3500 ÷ 10000 = 35%；单变更收缩率的算术平均为 32%，说明收缩效果略集中于部分大变更。评估期观察窗内逃逸缺陷 9 个，逃逸缺陷率为 9 ÷ 50 × 100 = 18 个/百次变更。
逐条回溯这 9 个逃逸缺陷：3 个落在被排除的用例范围内，涉及两个变更的支付回调与权限校验模块，属于影响分析漏判；4 个落在选中用例范围内，用例执行了但未覆盖该输入组合，属于用例设计问题；2 个无法关联到具体变更，单列待查。第一类占比 3 ÷ 9 ≈ 33%，且集中在两个变更上。
结论形成：收缩率从 0 升至 35%，逃逸缺陷率从 15 升至 18 个/百次变更，升幅 20%，同时出现 3 个落在排除范围内的逃逸缺陷。这一组数据不能支持“范围缩小且风险未升”的结论，应判定为需要回补范围：优先复查支付回调与权限校验两个模块的影响分析规则，把相关调用链纳入必选范围，再观察下一期这两类缺陷是否消失、逃逸率是否回落到基线附近。如果下一期收缩率维持在 30% 以上、逃逸率回到 15 个/百次变更左右、第一类回溯结果为零，才可以给出正向结论。
解读与限制：哪些结论不能从指标直接推出
收缩率上升本身只说明选例变少，不能直接推出测试更高效。效率提升还需要看单位变更的测试执行工时、缺陷发现前置率等数据；如果收缩后执行轮次反而增加，或缺陷更多地在生产环境才被发现，范围缩小带来的工作量节省可能被返工抵消。
逃逸缺陷率受发布节奏和上报习惯影响明显。发布越频繁、灰度覆盖越广，缺陷越容易被发现并计入；缺陷上报流程不规范时，部分逃逸缺陷会滞留在反馈渠道而未进入缺陷库，导致比率偏低。跨团队比较时这些差异会被放大，建议只在同一团队、同一产品线的不同时期之间做纵向比较。
样本量小时比率波动大。一个季度只有十几次变更时，多一个逃逸缺陷就可能让比率跳变十几个百分点，此时应看连续多期的趋势，或把相邻两期合并计算，避免用单期数值下结论。同理，单个变更的收缩率没有独立解读意义，必须放回汇总口径中看。
本文不设通用达标线。收缩率多少算合理、逃逸率上升多少算显著，取决于产品自身的缺陷容忍度、发布频率和基线水平。可行的做法是以基线期数值为参照，事先约定一个可接受的波动区间，例如逃逸率不超过基线的 1.2 倍，并在评估结束后根据实际结果调整区间，而不是套用外部标准。
最后，两个指标同时向好只能说明“在这批变更、这个观察窗内没有观察到质量恶化”，属于相关性证据。要确认因果关系，还需要结合回溯结果——尤其是落在排除范围内的逃逸缺陷数量——以及影响分析规则的变更记录，判断改善究竟来自选例准确还是来自其他因素。
把度量落到协作流程：记录、回溯与复盘
这套度量的可行性取决于日常协作中是否留下了可追溯的记录。评估期结束后再补数据，往往只能拿到总数，拿不到排除清单，第四步的回溯就无法进行。因此需要把关键信息固化在变更流转过程中。
变更单上应设置影响分析结论字段，记录本次分析选中的模块、排除的模块及理由、分析人和时间；回归用例的选取结果与执行结果关联到同一变更单，使得“全量多少条、选中多少条、执行结果如何”可以在一个视图内核对。逃逸缺陷登记时填写关联变更单和根因模块，回溯时才能定位到当时的排除范围。缺陷从用例执行失败到提交、流转、关闭的过程，需要在测试与研发之间保持同一条记录链路。
ONES 测试管理支持测试用例与需求、任务关联，测试计划与迭代关联，未通过的用例可快速创建缺陷任务并在测试与研发团队间流转，缺陷可关联至迭代，还支持自动生成测试报告和自定义报告模板。这些能力可以承载上述记录链路：变更对应的需求与任务、选中的回归用例、执行结果和逃逸缺陷挂在同一条链路上，周期复盘时按变更汇总导出，作为下一轮范围调整的依据。影响分析结论字段、排除清单的留存方式以及范围收缩率、逃逸缺陷率的专项统计，需要在具体项目中通过字段配置和报告模板组合实现，实际支持范围以配置结果为准。
复盘按固定周期进行，输入是两期的收缩率、逃逸缺陷率、回溯分类结果和未归属缺陷清单，输出是三类动作：修正影响分析规则（针对落在排除范围内的逃逸缺陷）、补充或改写用例（针对选中但未发现的缺陷）、清理数据口径（针对未记录分析过程的变更和无法归属的缺陷）。下一期评估沿用同一口径，把本轮动作的效果作为新的观察点，度量才真正进入循环。
常见问题
影响分析过程没有留痕的变更，能不能补录后计入收缩率？
不建议补录后计入。收缩率的分子是“被影响分析排除的用例数”，补录时很难还原当时的排除理由和排除清单，事后填写的数字容易偏向结果，使收缩率失真。
可行做法是把这类变更单列统计并报告占比：占比低时，收缩率结论仍可参考；占比高时，应在报告中说明结论可信度有限，先推动变更单上的影响分析结论字段落地，下一期再纳入计算。补录数据可用于逃逸缺陷回溯的辅助参考，但不进入收缩率分子分母。
逃逸缺陷率上升了，如何判断是范围缩小导致的还是发布节奏变化导致的？
先做两项拆分再看结论。第一项是按变更回溯：统计逃逸缺陷中落在被排除用例范围内的数量，这类缺陷与范围缩小直接相关；如果上升主要来自选中用例范围内未发现的缺陷，问题更可能出在用例设计或执行，而非选例范围。
第二项是控制发布变量：比较两期的发布频次和观察窗内可暴露缺陷的机会，发布明显更频繁时，同样的缺陷密度会表现为更高的逃逸数。必要时按发布批次分层比较，或把观察窗统一为发布后固定天数，再判断逃逸率的变化是否超出基线波动区间。
一个季度变更次数很少，算出来的比率波动很大，怎么处理？
小样本下比率不稳定是正常现象。可以合并相邻两到三个季度作为一个观察单元，或把变更按模块分组后分别计算，用多组数据观察方向是否一致。
报告时同时给出绝对数和比率，例如“本期 12 次变更、2 个逃逸缺陷”，让读者看到分母规模。单期数值只作为趋势中的一个点，结论表述为“暂未观察到明显恶化”比“质量未受影响”更准确。等积累到足够期数后，再确定适合自身的波动区间。
基线期没有启用影响分析，收缩率怎么算、还能不能比较？
基线期未启用影响分析时，收缩率按零处理，仅作为对照说明，不参与“收缩率变化”的计算。此时可比较的是逃逸缺陷率：两期使用相同的判定口径和观察窗长度，看评估期逃逸率相对基线期的变化幅度。
如果基线期数据本身也不完整，例如缺陷未关联变更单，建议先补齐或改用更早的、数据完整的时期作为基线，再启动评估。基线不可比时得出的结论，说服力有限。
评估结论显示需要回补范围，具体先做哪些动作？
优先处理落在排除范围内的逃逸缺陷：逐条找到对应变更的排除清单，复查影响分析规则为何漏判，把涉及的调用链或模块纳入必选范围，并在下一期观察同类缺陷是否消失。
其次处理选中但未发现的缺陷，补充或改写对应用例的输入组合与断言。最后清理数据口径，把未记录分析过程的变更和无法归属的缺陷单独列出，减少下一期统计中的噪声。三类动作完成后沿用同一口径复评，用新一期数据验证回补效果。
