AI测试用例草稿的需求覆盖率与可执行性怎么衡量

2026年11月10日

衡量AI测试用例草稿的质量，需要把“覆盖到了什么”和“能不能直接执行”分开统计。需求覆盖率回答需求条目是否被用例映射完整，可执行性回答抽检的草稿能否被测试人员直接执行。两项指标都要先固定分母、时间窗和抽检规则，再配合冗余度与人工修改量一起解读，避免把高覆盖率直接当成质量结论。

Table of Contents

要点总览（TL;DR）

需求覆盖率按“已覆盖需求条目数 ÷ 应覆盖需求条目数”计算，分母在评估启动时固定，并另拆验收条件子项统计，避免总覆盖率掩盖异常分支和边界值的缺口。
可执行性按抽检判定，前置条件、操作步骤、预期结果、测试数据四项全部满足才计为可执行，抽检按需求分层，样本过少时结果只作参考。
冗余度与人工修改量共用草稿总数作分母，统计时间窗从草稿生成到评审修改完成，跨版本比较时时间窗和抽检比例需保持一致。
四项指标组合解读：覆盖率高不代表缺陷发现能力强，可执行性判定存在主观性，需双人判定与复核控制分歧。
指标用于定位改进方向，覆盖率低先查需求输入与拆解，可执行性低先补测试数据模板和步骤书写规范。

评估目标：草稿质量要回答哪几个问题

评估对象是AI生成的测试用例草稿，评估发生在用例评审或进入执行之前。草稿尚未经过测试人员修改，也尚未产生执行结果，因此评估关注的是草稿本身是否具备进入下一环节的条件，执行通过率、缺陷发现数等结果指标不纳入本次统计。

四项指标分别回答不同问题，组合起来才能支撑判断：

指标	回答的问题	判定方向
需求覆盖率	本次范围内应覆盖的需求条目和验收条件，有多少已经被草稿映射到	越高越好，但需结合子项分布看
可执行性	抽检的草稿中，有多少条具备前置条件、步骤、预期结果、测试数据，测试人员可以直接照着执行	越高越好，判定项需逐条核对
冗余度	草稿中有多少条重复或高度相似，占草稿总量的比例	越低越好，需先约定相似判定规则
人工修改量	草稿进入评审后被修改了多少，反映草稿与可用状态之间的距离	越低越好，需固定统计时间窗

四项指标不可互相替代。覆盖率高但可执行性低，说明草稿列出了场景却写不清步骤；可执行性高但冗余度高，说明草稿重复堆量、评审成本上升；人工修改量低也可能只是因为草稿写得少、覆盖不足。评估时需要同时呈现四项结果，再结合具体需求范围判断哪一项是当前的主要问题。

指标与范围：分母、时间窗和抽检口径

指标能否复算，取决于分母是否在评估前固定。建议在评估启动时先写清纳入范围、排除项和时间窗，评估过程中不再调整口径。

指标	公式	分子	分母	单位
需求覆盖率	已覆盖需求条目数 ÷ 应覆盖需求条目数	草稿中至少有一条用例映射到的需求条目数	本次版本范围内、状态为待测试且纳入评估的需求条目数	百分比
验收条件覆盖率	已覆盖验收条件数 ÷ 应覆盖验收条件数	被至少一条用例对应到的验收条件、异常分支或边界值子项数	纳入范围需求下拆出的全部子项数	百分比
可执行性	可执行草稿数 ÷ 抽检草稿数	四项判定全部通过的草稿数	按规则抽出的草稿条数	百分比
冗余度	重复或高度相似草稿数 ÷ 草稿总数	覆盖同一验收条件且步骤基本一致的草稿数	本次生成的草稿总条数	百分比
人工修改量	被修改草稿数 ÷ 草稿总数，或修改字符数 ÷ 草稿总字符数	评审后发生修改的草稿条数或字符数	同一批草稿的总条数或总字符数	百分比

需求覆盖率的分母需要明确三点：需求状态口径，例如只统计进入测试阶段的需求；层级口径，例如按需求条目统计还是按验收条件子项统计；排除规则，例如明确不纳入本版本测试范围的需求要记录排除原因。分母一旦确定，评估期间不因草稿生成情况调整。

可执行性采用抽检方式，抽检比例根据草稿总量确定。草稿总量较少时可以全量判定；数量较大时按需求条目分层抽取，保证每个需求至少抽到一条，抽检总数建议不少于30条，样本过少时结果只作参考。判定项固定为四项：前置条件是否写明、操作步骤是否可照做、预期结果是否明确可核对、测试数据是否给出或说明获取方式。四项全部满足才计为可执行。

冗余度和人工修改量共用草稿总数作为分母，统计时间窗从草稿生成开始，到评审修改完成或进入执行前截止。跨版本比较时，两个版本的时间窗长度和抽检比例应保持一致，否则结果不可比。缺失值处理规则也需要提前约定：需求条目缺少验收条件时，该条目计入覆盖率分母但不计入子项覆盖率分母，并在结果中单独标注；草稿缺少修改记录时，人工修改量记为缺失，不按零处理。

数据口径与证据：从哪些记录取数

指标要可复算，每个数字都应能追溯到具体记录。取数前先确认四类数据的来源和留存方式。

需求条目与验收条件：以需求管理系统中的需求单和验收标准字段为准，导出时保留需求编号、标题、状态、所属版本和验收条件原文。评估范围以导出的需求清单为基线。
用例草稿与映射关系：草稿需保留生成批次、生成时间和对应的需求编号。用例与需求的映射关系应记录在用例字段或关联关系中，便于按需求反查用例。
人工修改记录：评审过程中的修改需要留下版本记录或修改日志，记录修改前后的内容、修改人和修改时间。仅有最终版本、没有修改痕迹时，人工修改量无法计算。
可执行性判定证据：每条抽检草稿的判定结果需附评审记录，写明四项判定中哪一项未通过及原因；有条件时可安排测试人员按草稿尝试执行一步，把执行尝试记录作为佐证。

口径不一致时，以评估启动时确认的基线为准。例如需求在评估期间发生变更，变更后的需求不追溯调整分母，另在备注中记录变更条目；两位评审人对同一条草稿的可执行性判定不一致时，提交第三人复核，以复核结论为准并保留分歧记录。评估过程涉及需求、用例和评审记录的承载，ONES 中需求与测试用例可以通过关联关系组织，ONES Assistant 智能助手连接 ONES Project、ONES Wiki 与 ONES TestCase，基于项目数据回答问题并执行操作，输出过程可追踪、结果可审计，便于把草稿批次、需求映射和评审记录留在同一套系统里取数。

计算与评估步骤：从抽样到出数

按以下顺序操作，可以在一天内完成一个版本的草稿评估，并保证他人能按同样步骤复算出相同结果。

锁定评估基线：导出本次版本纳入评估的需求清单和验收条件，记录导出时间、需求条目数和子项数，写明排除项及原因。这份清单就是覆盖率的分母。
建立需求与草稿的映射表：逐条需求核对草稿中是否有对应用例，记录映射到的用例编号。一条需求对应多条用例时只计一次覆盖；一条用例对应多条需求时分别计入各需求。
拆分验收条件子项：把每条需求的验收条件拆成正常路径、异常分支、边界值等子项，逐项核对是否有用例覆盖，得到子项覆盖率。
抽取可执行性样本：按需求分层抽取草稿，记录抽检总数。逐条按前置条件、操作步骤、预期结果、测试数据四项判定，全部通过计为可执行，任一项缺失或存在歧义计为不可执行，并写明原因。
统计冗余与修改量：按事先约定的相似规则标记重复草稿，统计冗余条数；对照修改记录统计被修改的草稿条数或字符数。
汇总与复核：计算各项比例，保留一位小数。由未参与初判的人员抽取10%的样本复算，复算结果与初判不一致时逐条核对，修正后记录修正原因。
留存结果：把基线清单、映射表、抽检判定表、修改记录和汇总表放在同一目录下，注明评估人、复核人和评估日期，便于下个版本沿用同一口径对比。

算例：一个版本的四项指标怎么算出来

以下为演示情景，数据为假设值，用于说明公式代入和分母处理方式。

需求覆盖率。某版本纳入评估的需求条目共40条，草稿映射到其中34条，需求覆盖率 = 34 ÷ 40 = 85.0%。40条需求共拆出验收条件子项120个，草稿覆盖其中90个，子项覆盖率 = 90 ÷ 120 = 75.0%。两个数字的差距说明部分需求虽有用例，但异常分支和边界值覆盖不足，需要回到子项层面定位缺口。

可执行性。按需求分层抽取草稿50条，逐条判定四项：前置条件齐备42条，步骤可照做38条，预期结果明确40条，测试数据给出35条。四项全部通过的草稿为32条，可执行性 = 32 ÷ 50 = 64.0%。未通过的18条中，测试数据缺失是最常见原因，其次是步骤描述笼统。

冗余度与人工修改量。本批草稿共200条，按“覆盖同一验收条件且步骤基本一致”的规则标记出24条重复，冗余度 = 24 ÷ 200 = 12.0%。评审后有70条草稿发生修改，人工修改量 = 70 ÷ 200 = 35.0%；若按字符统计，修改字符数为5600，草稿总字符数为20000，人工修改量 = 5600 ÷ 20000 = 28.0%。两种口径结果不同，报告中需注明采用哪一种。

分母为零与数据缺失。若某需求没有验收条件，该需求计入需求覆盖率分母，但不计入子项覆盖率分母，并在结果中标注“无验收条件需求1条”；若某版本没有生成任何草稿，覆盖率分母仍为应覆盖需求数，分子为零，结果记为0%，同时注明“本版本无草稿”，不把缺失当作不适用。若修改记录缺失，人工修改量记为“无法计算”，不填0。

解读与限制：指标能说明什么、不能说明什么

覆盖率说明草稿与需求之间的映射完整程度，不说明用例能否发现缺陷。一条覆盖了验收条件的用例，可能只验证了正常路径，对异常输入和状态切换没有设计检查点。因此覆盖率应与子项覆盖率一起看，子项覆盖率的缺口往往比总覆盖率更能指出草稿的问题所在。

可执行性判定带有主观成分，控制方式包括：判定项固定为四项并给出每项通过的具体标准；抽检样本由两人独立判定，分歧提交第三人复核；判定结果附原因说明，便于事后核对。即便如此，可执行性只反映草稿是否写得清楚，不反映用例设计是否有效。

以下情形下指标不可比：两个版本的抽检比例不同、时间窗长度不同、需求拆分粒度不同，或一个版本按需求条目统计而另一个按验收条件统计。跨团队比较时还需考虑业务复杂度差异，同样的覆盖率在不同模块下的含义并不相同。冗余度的相似判定规则如果中途调整，前后结果也不能直接对比。

指标结果适合用来定位改进方向，而不是给草稿打分排名。覆盖率低，优先检查需求拆解和草稿生成时的需求输入是否完整；可执行性低，优先补充测试数据模板和步骤书写规范；冗余度高，调整生成时的去重规则；人工修改量大，回看修改集中在哪些字段，把高频修改点转化为生成约束。下一轮评估沿用同一口径，观察指标变化，才能判断调整是否有效。ONES Assistant 贯穿需求、计划、协作、测试、发布与知识沉淀，草稿评估中形成的需求映射、评审记录和改进结论可以沉淀在项目与知识库中，供后续版本对照使用。

常见问题

需求在评估期间发生变更，覆盖率分母要不要跟着调整？

不追溯调整。评估启动时确认的需求清单就是基线，评估期间发生的需求变更不改变本次分母，另在备注中记录变更条目及原因。这样同一版本内的结果可以复算，也便于和下一版本对比。若变更影响范围较大，可以另起一次评估，用新的基线单独统计，两次结果分别报告，不混在一起计算。

草稿总量很大时，可执行性抽检多少条比较合适？

按需求条目分层抽取，保证每个需求至少抽到一条，抽检总数建议不少于30条。草稿总量较少时直接全量判定，省去抽样环节。样本量偏小时，结果只作参考，适合用来发现共性问题，不适合作为版本质量结论。抽检比例一旦确定，同一版本内不再调整，跨版本比较时保持比例一致。

两位评审人对同一条草稿的可执行性判定不一致怎么办？

提交第三人复核，以复核结论为准，并保留分歧记录。为减少分歧，判定项固定为四项，每项给出通过的具体标准，判定结果附未通过原因。分歧集中的判定项说明标准本身不够清晰，下一轮评估前应先修订判定标准，再沿用同一口径统计。

人工修改量按条数统计和按字符数统计，结果差很多时报告用哪个？

两种口径回答的问题不同：按条数统计反映有多少草稿需要返工，按字符数统计反映修改的深度。报告中注明采用哪一种，同一版本内不混用。若两种结果差距明显，说明修改集中在少数草稿上，可以补充说明修改集中的字段，帮助定位生成环节的问题。

没有修改记录，人工修改量还能算吗？

无法计算时记为“无法计算”，不填0。仅有最终版本、没有修改痕迹时，人工修改量缺少分子，强行按零处理会低估草稿与可用状态之间的距离。这种情况下可以先补齐评审环节的版本记录或修改日志，从下一批草稿开始统计，历史批次在报告中标注为缺失。