衡量AI测试用例草稿的质量，需要把“需求覆盖率”和“可执行性”拆成有明确分母、时间窗和取数规则的指标，再用抽样评审证据校验。本文给出一套可复算的口径：覆盖率以需求条目或验收条件为分母，可执行性以用例总数为分母，冗余度和人工修改量作为辅助指标，最后说明这些比例能说明什么、不能说明什么。
要点总览（TL;DR）
- 需求覆盖率以评估时点的需求条目或验收条件为分母，分别统计条目覆盖与条件覆盖；条目覆盖率高不代表验收条件覆盖充分。
- 可执行性通过率以本批用例总数为分母，先定义可执行的最低要素（前置条件、操作步骤、输入数据、预期结果），再统计评审通过比例；缺要素用例计入分母、不计入分子。
- 冗余度与人工修改量作为辅助指标，与覆盖率、可执行性组合解读；人工修改量需按修改类型分类计数，才能定位返工原因。
- 评估前固定需求版本、用例批次、时间窗与缺失值处理规则；分母为零的指标记为不适用，跨批次或跨团队比较前先统一口径。
- 指标用于改进生成提示与评审重点，不宜直接作为个人绩效依据，否则容易诱导评审放宽标准、削弱指标可信度。
评估目标：草稿质量要回答哪几个问题
评估对象是AI根据需求生成的测试用例草稿，处于评审和采纳之前的状态，尚未成为最终执行脚本。评估的目标是判断这批草稿能否进入下一环节，以及需要返工到什么程度，因此需要回答四个问题。
- 需求是否被覆盖：评估范围内的需求条目和验收条件，有多少被至少一条有效用例对应上。这个问题决定草稿是否存在明显遗漏。
- 用例能否直接执行：草稿是否具备前置条件、操作步骤、输入数据和预期结果，测试人员拿到后能否按步骤操作并判断结果。这个问题决定草稿的可用程度。
- 是否存在重复：同一需求或同一验证点是否被多条用例反复覆盖，造成评审和执行成本浪费。
- 人工改动有多大：评审人修改了多少条、改了哪些类型的内容，例如补充步骤、修正预期结果、调整输入数据。这个问题反映草稿与可用状态之间的距离。
四个问题的结果共同支撑一个决策：整批采纳、部分返工，还是调整生成提示与评审流程后重新生成。单独看覆盖率或单独看可执行性，都不足以支撑这个决策。
指标与范围：覆盖率与可执行性的计算口径
两类核心指标都需要固定分子、分母、单位和统计时间窗。下表给出定义，其中“评估范围”指本次纳入统计的需求基线与用例批次。
| 指标 | 公式 | 分子 | 分母 | 单位 | 时间窗 |
|---|---|---|---|---|---|
| 需求条目覆盖率 | 被有效用例覆盖的需求条目数 ÷ 评估范围内需求条目总数 | 至少被一条有效用例覆盖的需求条目数 | 评估时点需求基线中的需求条目总数 | 百分比 | 与用例批次对应的需求版本，统计截止到评审完成日 |
| 验收条件覆盖率 | 被有效用例覆盖的验收条件数 ÷ 评估范围内验收条件总数 | 至少被一条有效用例覆盖的验收条件数 | 需求基线中已拆出的验收条件总数 | 百分比 | 同上 |
| 可执行性通过率 | 评审通过的可执行用例数 ÷ 用例总数 | 具备最低要素且评审通过的用例数 | 本批次用例总数（含缺要素用例） | 百分比 | 本批次评审周期内 |
| 冗余度 | 重复验证同一验证点的用例数 ÷ 用例总数 | 被判定为重复覆盖的用例数 | 本批次用例总数 | 百分比 | 本批次 |
| 人工修改量 | 评审中被修改的用例数 ÷ 用例总数；另按修改类型分别计数 | 被修改的用例数 | 本批次用例总数 | 百分比，辅以条数 | 本批次评审周期内 |
可执行的最低要素需要在评估前写清楚，通常包括：明确的前置条件、可操作的操作步骤、具体的输入数据、可判断的预期结果。四项齐全且表述无歧义，才进入“可执行”候选；再经评审确认，才计入分子。条目覆盖与条件覆盖分开统计，是因为一条需求可能包含多个验收条件，条目覆盖率高不代表条件覆盖充分。
评估范围要同时锁定三件事：需求版本（以哪一次基线为准）、用例批次（哪一批AI生成草稿）、纳入排除规则（例如关联到已废弃需求的用例是否计入）。范围一旦变动，前后两批数据就不可直接比较。
数据口径与证据：分母、缺失值与评审证据怎么取
取数来源有两类：需求管理中的需求条目与验收条件清单，以及用例库中的草稿记录。分母以评估时点的需求基线为准，评估开始后新增或变更的需求不回溯计入，避免分母漂移。需求与用例之间的关联关系是计算覆盖率的前提，关联缺失时应先补录再统计，不能默认视为未覆盖。
缺失值处理需要事先约定并写入口径：
- 缺少预期结果或缺少操作步骤的用例，仍计入用例总数分母，但不计入可执行分子。这样可执行性通过率能反映草稿的真实完整程度。
- 无法判断关联到哪条需求的用例，计入用例总数，在覆盖率统计中不计为有效覆盖，同时单独记录“关联不明”条数，供后续排查。
- 需求条目没有拆出验收条件时，条件覆盖率的分母为零，该指标记为“不适用”，不用零值参与汇总或跨批次平均。
可执行性的评审证据建议包含三类：评审记录（谁在何时对哪条用例给出通过或退回结论）、字段完整率（前置条件、步骤、输入数据、预期结果四项的填写比例）、抽样复核结果（对已判定通过的用例再抽一部分由第二人复核）。抽样比例可按批次规模设定，例如每批抽取通过用例的10%至20%，并覆盖不同需求模块；评审人应包含熟悉该需求的测试人员和需求提出方代表。证据保留用例编号、评审人、结论和时间，保证结论可追溯。
在工具层面，ONES 的需求、测试用例与评审记录可以在同一套权限体系下管理，ONES Assistant 连接 ONES Project、ONES Wiki 与 ONES TestCase，基于项目与工作项上下文执行操作，输出过程可追踪、结果可审计。这为“需求条目—用例—评审结论”的关联取数提供了承载，具体字段完整率与评审记录的统计方式需结合团队实际配置确认。
计算与评估步骤：从取数到出结论的流程
按以下五步执行，每步都有明确产出，便于复算和复核。
- 锁定需求基线与用例批次。导出评估时点的需求条目与验收条件清单，标记版本号；导出本批AI生成用例，记录生成时间与提示版本。产出：需求基线清单、用例批次清单。
- 统计覆盖率与可执行性通过率。按上表公式逐项计算条目覆盖率、条件覆盖率和可执行性通过率，同时记录关联不明条数与缺要素条数。产出：指标计算表。
- 抽样评审核对判断。对判定为可执行的用例抽样复核，核对四项要素是否真实齐全、预期结果是否可判断；对判定为未覆盖的需求抽查是否存在漏关联。产出：抽样复核记录与差异清单。
- 统计冗余度与人工修改量。标记重复验证同一验证点的用例，统计修改条数并按修改类型分类计数。产出：冗余清单、修改类型分布。
- 汇总并处理分歧。将指标与抽样证据合并成一份评估结论；评审人对某条用例是否“可执行”存在分歧时，回到最低要素定义逐项核对，仍无法一致的记为“存疑”，单独列示，不强行归入通过或退回。产出：评估结论与存疑清单。
算例：一个批次草稿的指标计算
以下为演示情景，数值仅用于说明计算过程。某批次AI生成草稿对应需求基线中40条需求，已拆出验收条件120条；本批生成用例200条，评审通过的可执行用例140条，判定为重复覆盖的用例16条，评审中被修改的用例90条。
| 指标 | 代入计算 | 结果 |
|---|---|---|
| 需求条目覆盖率 | 34 ÷ 40 | 85% |
| 验收条件覆盖率 | 96 ÷ 120 | 80% |
| 可执行性通过率 | 140 ÷ 200 | 70% |
| 冗余度 | 16 ÷ 200 | 8% |
| 人工修改量 | 90 ÷ 200 | 45%，共90条 |
解读这组数据时，条目覆盖率85%与条件覆盖率80%的差距提示部分需求虽被覆盖，但验收条件未拆全；可执行性通过率70%意味着约三成用例需要补充要素或退回重写；45%的修改量说明草稿可用但返工成本不低，可进一步看修改类型分布，若集中在预期结果，说明生成环节对判定标准的理解需要加强。
异常情形处理：若某需求未拆出验收条件，条件覆盖率分母为零，该需求不参与条件覆盖率计算，并在报告中注明“不适用”；若两批草稿对应的需求版本不同或提示版本不同，指标不可直接比较，应分别报告或先统一基线再比较，不做简单平均。
解读与限制：指标能说明什么、不能说明什么
覆盖率反映需求与用例之间的对应关系，高覆盖率说明遗漏少，与缺陷发现能力之间还需要用例有效性来连接。一条覆盖了需求但验证点选得浅的用例，同样可能漏掉关键缺陷，因此覆盖率应与抽样评审中的用例有效性判断一起看。
可执行性通过率受评审标准松紧的直接影响。两个团队对“预期结果是否明确”的尺度不同，通过率就不可直接比较；跨团队比较前需统一最低要素定义和评审人培训口径。冗余度与人工修改量同样依赖判定规则，重复的认定标准和修改类型的分类需要在评估前固定。
单指标不能代表草稿整体质量。覆盖率高的批次可能修改量也高，可执行性通过率高的批次可能冗余度偏高，需要组合解读并回到具体用例查看原因。这些指标适合用于改进生成提示、调整评审重点和跟踪批次间变化，作为流程改进的依据；将其直接用作个人绩效评价，容易诱导评审人放宽标准，反而削弱指标的可信度。
常见问题
AI生成的用例草稿关联不到具体需求时，覆盖率该怎么算？
关联不明的用例仍计入用例总数，参与可执行性等以用例为分母的指标；在覆盖率统计中不计为有效覆盖，同时单独记录“关联不明”条数。更稳妥的做法是先补录需求与用例的关联关系再统计，避免把取数问题误判为覆盖遗漏。若补录后确认该用例对应的需求不在本次基线内，则按纳入排除规则处理，并在报告中注明。
同一批草稿由不同评审人判断可执行性，结论不一致怎么办？
分歧通常来自对“预期结果是否明确”“步骤是否可操作”的尺度不同。处理方式是回到评估前写好的最低要素定义，逐项核对四项要素是否齐全、表述是否可判断；仍无法达成一致的用例记为“存疑”，单独列示，不强行归入通过或退回。若分歧集中出现，说明最低要素定义需要细化，应在下一批次评估前补充判定示例并统一评审人培训口径。
人工修改量高，是否说明这批草稿不该采纳？
修改量高说明草稿与可用状态之间距离较大，是否采纳要结合修改类型分布判断。若修改集中在补充步骤或输入数据，属于可批量返工的问题，调整生成提示后重新生成可能更划算；若修改集中在预期结果的判定标准，说明生成环节对验收条件的理解有偏差，需要先补充需求侧的判定依据。修改量低但覆盖率也低的批次同样需要警惕，可能只是草稿生成得少而浅。
需求条目覆盖率和验收条件覆盖率应该看哪一个？
两个都看，并关注两者差距。条目覆盖率回答“有没有需求被整体漏掉”，条件覆盖率回答“每条需求内部的验证点是否拆全”。条目覆盖率高而条件覆盖率明显偏低，通常意味着部分需求只被浅层覆盖，验收条件没有逐条对应到用例。若某条需求尚未拆出验收条件，条件覆盖率分母为零，该需求不参与条件覆盖率计算，报告中注明“不适用”，不用零值参与汇总。
这些指标能否跨批次、跨团队直接比较？
需要先统一口径再比较。跨批次比较的前提是需求版本与提示版本一致，否则分母范围和生成条件都变了，比例不可直接对照，应分别报告或先统一基线。跨团队比较还受评审标准松紧影响，最低要素定义、重复的认定标准、修改类型的分类都要一致。口径统一之前，指标更适合用于团队内部的批次跟踪和流程改进。
