风险覆盖率和高风险用例执行率都以风险清单为分母基础：风险覆盖率看风险项是否被测试用例覆盖，高风险用例执行率看已识别的高风险用例是否在本期真正执行。统计前要先固定风险分级规则、风险与用例的关联方式、纳入范围和统计时间窗，算出的比例再结合缺陷逃逸和测试投入分布解读，避免把单一比例直接当作质量结论。
要点总览（TL;DR）
- 两个指标都以风险清单为分母基础：风险覆盖率=已覆盖风险项数÷本期风险项总数，高风险用例执行率=已执行高风险用例数÷本期应执行高风险用例总数。
- 统计前先固定风险分级规则、风险与用例的关联方式、纳入排除项和时间窗，否则不同版本的比例不可比。
- 未关联风险的用例不计入覆盖率分子但应单列提示；分母为零时标记“不适用”，不用0%或100%代替。
- 比例需结合缺陷逃逸和测试投入分布解读，覆盖率高低取决于风险清单本身是否可靠，执行率高不代表执行有效。
- 两项指标不设通用达标线，参考区间按版本和业务风险自行设定并保持口径一致。
评估目标：这两个指标要回答什么问题
这两个指标服务于风险驱动的测试决策，回答的是“高风险区域有没有被测试设计覆盖、覆盖到的用例有没有按计划执行”。风险覆盖率反映测试设计对风险清单的响应程度，高风险用例执行率反映本期测试活动对高风险用例的落实程度。两者合起来，能帮助测试负责人判断资源是否投向了风险更高的模块，以及计划中的高风险验证是否被临时压缩或跳过。
它们不直接等价于产品质量，也不等于缺陷数量。一个版本风险覆盖率高，说明测试用例与风险项的关联较完整，但用例本身的设计质量、执行深度、环境真实性仍会影响最终质量。执行率高同样只说明用例被执行过，不说明执行结果有效。因此解读时应把这两个指标与缺陷逃逸情况、各模块测试投入分布放在一起看：覆盖率低而缺陷逃逸集中，说明测试设计存在盲区；执行率高但高风险模块仍有逃逸缺陷，说明用例有效性或执行质量需要复查。
指标与范围：风险清单、用例集与统计口径
统计前先形成一张“指标定义卡”，把对象、范围和纳入排除规则写清楚，后续每次统计按同一口径执行，结果才可比较。
风险清单的来源与分级
风险清单应来自本期评审确认的风险识别活动，包含需求风险、架构风险、历史缺陷集中区域、变更影响面等来源。分级标准建议在团队内固定，例如按发生可能性和影响程度划分为高、中、低三级，并明确“高风险”的判定条件。本期范围指纳入本次统计的版本、迭代或发布批次，未纳入本期范围的风险项不计入分母。
用例与风险的关联方式
用例与风险可以一对一关联，也可以一对多关联。一个风险项被多条用例覆盖时，风险覆盖率按风险项计数，不按用例条数计数；一条用例关联多个风险项时，该用例在每个风险项下分别计入覆盖。关联关系应记录在用例字段中，避免统计时靠人工回忆补录。
纳入统计的用例状态与排除项
纳入统计的用例应是本期有效用例，排除作废、重复登记、明确不属于本期的用例。执行状态一般区分未执行、执行中、已执行（通过/失败/阻塞）。高风险用例执行率的分子只计已执行的高风险用例，阻塞是否计入已执行需在口径中事先约定，建议单独列出阻塞数量，避免口径漂移。
统计时间窗与粒度
时间窗与版本或迭代周期对齐，例如“某版本提测日至发布前”。统计粒度可按版本总览、按模块拆分、按迭代拆分。不同粒度的分母范围不同，报告中应标注粒度，避免把模块级比例与版本级比例直接相加或比较。
数据口径与证据：字段、来源和缺失值处理
两项指标能否复算，取决于风险项、用例和执行记录三类数据是否完整、字段是否统一。建议先确定字段清单，再确定取数来源。
| 数据对象 | 关键字段 | 用途 |
|---|---|---|
| 风险项 | 风险编号、风险等级、所属模块、风险状态、是否纳入本期 | 确定分母范围和高风险集合 |
| 测试用例 | 用例编号、关联风险编号、用例优先级、用例状态、所属模块 | 建立风险与用例的关联，识别高风险用例 |
| 执行记录 | 用例编号、执行状态、执行时间、执行人、执行轮次 | 判断用例是否在本期执行 |
| 缺陷记录 | 缺陷编号、关联用例或模块、严重程度、发现阶段 | 配合解读指标，识别逃逸和集中区域 |
取数来源通常是测试管理工具中的风险条目、用例库和执行记录，缺陷数据来自缺陷管理模块。统计时以系统记录为准，手工补录需注明来源和补录时间。缺失值处理遵循三条规则：未关联风险的用例不计入风险覆盖率分子，但可在报告中单列“未关联用例数”提示关联完整度；未执行用例在高风险用例执行率中计入分母、不计入分子；分母为零时该指标标记为“不适用”，不用0%或100%代替，并说明原因，例如本期未识别高风险项或未建立关联。
当风险项与用例的关联在统计期内发生变更时，以统计截止时点的关联关系为准，并在报告中记录变更次数，便于判断数据稳定性。跨版本比较时，应确认两期的风险分级标准和关联规则一致，否则比例不可比。
计算步骤：公式、分母与统计流程
两个指标的核心公式如下，分子分母均以本期范围为准：
- 风险覆盖率 = 已有测试用例覆盖的风险项数 ÷ 风险清单中纳入本期范围的风险项总数 × 100%
- 高风险用例执行率 = 已执行的高风险用例数 ÷ 本期应执行的高风险用例总数 × 100%
其中“已有测试用例覆盖”指至少存在一条有效用例与该风险项关联；“已执行”指执行状态为已执行，阻塞是否计入按事先约定处理；“本期应执行的高风险用例”指关联了高风险项且纳入本期测试范围的用例。
分组计算方式
按模块拆分时，分别取该模块的风险项数和已覆盖风险项数、高风险用例应执行数和已执行数，各自计算比例，不把模块分子分母混算后再拆分。按版本拆分时，以版本为独立统计单元，跨版本累计比例需重新定义分母，不能简单平均各版本比例。
统计频次与复核
建议在提测、测试中期、发布前各统计一次，观察趋势而非只看单点。每次统计后由测试负责人复核分母范围、关联完整度和异常值，例如某模块覆盖率骤降，先检查是否新增了未关联的风险项，再判断是否为真实覆盖缺口。
在测试管理工具中，风险项和用例通常以工作项形式承载，关联关系、执行状态和执行时间随工作项流转记录。ONES 支持在测试用例与需求、风险等工作项之间建立关联，并通过工作项状态和字段汇总执行情况，便于按版本、模块筛选后导出统计所需的数据。统计口径确定后，可以把风险等级、关联风险、执行状态等字段固定为必填或筛选条件，减少每次统计时的数据清洗工作。
算例：一个版本的两项指标怎么算出来
以下为演示情景，数据为示例，用于说明计算过程。
某版本风险清单纳入本期范围的风险项共10项，其中高风险4项、中风险4项、低风险2项。用例库中有效用例30条，其中26条关联了风险项，4条未关联风险。高风险用例共12条，本期已执行9条，未执行2条，阻塞1条（口径约定阻塞不计入已执行）。
风险覆盖率计算
假设10个风险项中有8项至少被一条有效用例关联，则风险覆盖率为8 ÷ 10 × 100% = 80%。4条未关联风险的用例不计入分子，报告中单列“未关联用例4条”，提示关联完整度不足。若按模块拆分，A模块风险项4项、覆盖4项，覆盖率100%；B模块风险项6项、覆盖4项，覆盖率约66.7%，总览80%由8 ÷ 10得出，与模块比例不可直接平均。
高风险用例执行率计算
高风险用例执行率为9 ÷ 12 × 100% = 75%。未执行2条计入分母不计入分子；阻塞1条按口径不计入已执行，报告中单列阻塞数。若某模块本期无高风险用例，该模块执行率标记为“不适用”，不填0%。
结果呈现
结果建议以“总览加模块拆分”的形式呈现：总览给出两个比例、分母规模和未关联用例数、阻塞数等辅助信息；模块拆分列出各模块的风险项数、覆盖数、高风险用例应执行数与已执行数。这样读者既能看整体，也能定位缺口所在模块。
解读与限制：比例高低说明什么、不能说明什么
覆盖率高的前提是风险清单本身可靠。如果风险识别遗漏了关键变更区域，覆盖率再高也只说明测试设计覆盖了已识别的风险，未识别区域仍是盲区。因此应定期回看风险清单的来源和评审记录，结合缺陷逃逸情况检验清单是否完整。
执行率高不代表执行有效。用例被执行过，但断言是否充分、环境是否接近真实、失败是否被正确处理，都会影响验证效果。解读时应结合执行结果分布和缺陷逃逸：高风险模块执行率高但发布后仍有严重逃逸缺陷，说明用例有效性或风险判定需要复查。
测试投入分布用于判断资源是否与风险等级匹配。可以对比各模块的高风险用例数、执行耗时和缺陷发现数，观察投入是否集中在高风险区域。若高风险模块投入占比明显偏低，即使执行率数字尚可，也应检查是否存在赶工执行。
两项指标不设通用达标线。不同版本、不同业务的风险承受度不同，参考区间应结合历史数据和业务风险由团队自行设定，并在版本间保持一致以便比较。单一比例不能作为质量结论或绩效结论，应作为风险驱动测试过程中的观察信号，配合缺陷逃逸、测试投入分布和风险清单评审记录共同使用。
常见问题
风险清单在统计期内新增或调整了风险项，分母按哪个时点算？
建议以统计截止时点的风险清单为准，并在报告中记录统计期内的变更次数和主要变更内容。如果中途新增了风险项且已有关联用例，按截止时点计入分母和分子；新增但尚未关联用例的风险项计入分母、不计入分子，会拉低覆盖率，这恰好反映关联工作尚未跟上。跨期比较时，如果两期风险识别范围差异较大，应在报告中说明，避免把比例变化直接解读为测试质量变化。
一条用例关联多个风险项，或者一个风险项被多条用例覆盖，怎么计数？
风险覆盖率按风险项计数：一个风险项只要至少有一条有效用例关联，就算已覆盖，被多条用例覆盖不重复加分。一条用例关联多个风险项时，该用例在每个风险项下分别计入覆盖，因此一条用例可以同时提升多个风险项的覆盖状态。高风险用例执行率则按用例计数：关联了高风险项的用例，每条独立计入应执行数和已执行数，同一条用例关联多个高风险项时不重复计数，避免执行率被放大。
阻塞状态的用例算不算已执行？
这属于口径约定问题，两种处理都可行，关键是全团队统一并在报告中注明。常见做法是阻塞不计入已执行，单独列出阻塞数量，因为阻塞通常意味着验证未完成，计入已执行会高估落实程度。如果团队选择把阻塞计入已执行，应在指标定义卡中写明，并在解读时结合阻塞占比判断实际验证进度。口径一旦确定，同一版本内的多次统计和跨版本比较都应沿用。
覆盖率算出来偏低，应该先查数据还是先补用例？
先查数据再判断是否为真实缺口。常见的数据侧原因包括：新增风险项尚未建立用例关联、用例关联字段漏填、部分用例被误标为作废。可以先看“未关联用例数”和近期新增风险项清单，确认关联完整度。排除数据问题后，若覆盖率仍低，说明测试设计对已识别风险的响应不足，应优先为高风险且未覆盖的风险项补充用例，再考虑中低风险项。覆盖率骤降时同样先核对分母是否因风险识别范围扩大而变大。
这两个指标能直接用于考核测试团队吗？
不建议单独作为考核依据。风险覆盖率可以通过批量补关联快速抬高，高风险用例执行率可以通过赶工执行提升，两者都不直接反映验证效果。更稳妥的做法是把它们作为过程观察信号，与缺陷逃逸、执行结果分布、测试投入分布一起看，并关注趋势变化而非单点数值。如果确需纳入考核，应同时设定数据质量要求，例如关联完整度、阻塞处理及时性，降低指标被形式化操作的空间。
