AI生成的测试用例看起来数量不少，但能不能用，要分开回答两个问题：需求里的检查点是否被触达，以及他人能否按步骤复现。本文给出一套可复算的检查方法，包括覆盖性的公式与分母口径、可执行性的四项证据标准、抽样试跑安排，以及结果解读时的限制，帮助测试负责人判断哪些用例进入评审、哪些退回修改。
要点总览（TL;DR）
- 覆盖性检查先把需求与验收条件拆成可判定的检查点清单，覆盖率 = 被命中检查点数 ÷ 检查点总数 × 100%，按检查点计数、不按用例计数，无法判定的条目列入待澄清清单、不进分母。
- 可执行性检查按前置条件、操作步骤、测试数据、预期结果四项逐条核对，再按事先固定的样本量抽样试跑，判定分为通过、部分通过、不通过三档，失败原因归为四类便于定向退回。
- 评估按固定顺序执行：圈定需求版本与用例范围、拆检查点标优先级、比对命中、抽样试跑、汇总复核、输出评审结论与退回修改项，口径在比对前确认。
- 结果解读要限定范围：不同需求规模的覆盖率不可直接横比，分母为零或检查点极少时直接列未覆盖清单，抽样通过率不能外推为全量结论，覆盖率也不替代缺陷发现效果。
- 评估结论要回写流程：高优先级未覆盖项转待补用例任务，含糊需求转澄清任务，不可执行用例退回修改并留痕，评审记录附指标汇总与未覆盖清单。
检查覆盖性和可执行性要回答哪两个问题
覆盖性和可执行性对应两类不同判断，混在一起评估容易得出模糊结论。覆盖性回答的是“需求有没有被问到”：把需求与验收条件拆成可核对的检查点，逐条确认是否有用例触达。可执行性回答的是“用例能不能被跑起来”：换一名测试人员，仅依据用例描述，能否准备环境、执行步骤、得到预期结果。
两项评估的结论用途也不同。覆盖性结果用于判断这批用例是否具备进入评审的完整性，未覆盖的检查点需要补用例或澄清需求；可执行性结果用于判断用例能否进入执行环节，描述缺失、数据不明的用例应退回修改。两者都只服务于用例准入，不能直接当作产品质量结论——用例覆盖得全、写得清楚，与缺陷能否被发现是两件事。
评估对象需要事先圈定：一批AI生成用例，对应某一个确定的需求版本。需求在评估期间发生变更，应重新确定基线版本，否则检查点清单与用例集合对不上，覆盖率失去意义。评估开始前记录三项信息：需求版本号或基线时间、用例集合的范围（哪些批次、哪些模块）、评估执行的时间窗。
覆盖性怎么算：检查点清单、分母与命中口径
覆盖性指标的可信度取决于检查点清单的质量。清单从需求条目和验收条件中拆出，每条检查点应描述一个可判定的行为或结果，例如“手机号格式错误时提交，提示具体错误文案”。一条需求通常拆出多条检查点，拆到无法再拆、能明确回答“有用例覆盖吗”为止。需求描述含糊、无法拆出可判定检查点的部分，单独列入待澄清清单，不计入分母。
覆盖率的基本公式为：覆盖率 = 被命中的检查点数 ÷ 检查点总数 × 100%。分母是本次评估范围内、已确认可判定的检查点总数；分子是至少被一条用例触达的检查点数。单位是百分比，统计时间窗为评估执行当日，评估期间新增的检查点不计入本期分母，留待下期。
一条用例命中多个检查点时，按检查点计数，不按用例计数：分子统计的是被命中的检查点数量，一条用例覆盖三个检查点就贡献三个命中。这样口径下，用例数量多并不自动推高覆盖率，冗余用例不会虚增指标。反过来，一个检查点被多条用例重复覆盖，只计一次命中，重复度另行记录。
| 口径项 | 定义 | 处理规则 |
|---|---|---|
| 检查点来源 | 需求条目与验收条件拆出的可判定条目 | 无法判定的条目列入待澄清清单，不进分母 |
| 分母 | 评估范围内已确认可判定的检查点总数 | 评估期间新增检查点计入下期 |
| 分子 | 至少被一条用例触达的检查点数 | 按检查点计数，同一检查点多次覆盖只计一次 |
| 公式 | 覆盖率 = 分子 ÷ 分母 × 100% | 分母为零时不出百分比，标注“无有效检查点” |
| 缺失值 | 需求缺失或含糊导致的无法判定项 | 记为待澄清，不判为未覆盖 |
除总覆盖率外，建议同时输出未覆盖检查点清单，并标注检查点优先级。高优先级检查点未覆盖，即使总覆盖率尚可，也应视为需要补用例的信号；低优先级检查点未覆盖，可以记录后进入后续迭代。
可执行性怎么评：证据项与通过标准
可执行性按四项证据逐条核对：前置条件、操作步骤、测试数据、预期结果。每项都要能支撑他人独立复现，缺一项即构成执行障碍。核对时以“另一名测试人员能否照做”为判断视角，而不是以写用例的人自己是否看得懂为准。
| 证据项 | 核对内容 | 采集方式 |
|---|---|---|
| 前置条件 | 环境、账号、权限、依赖数据是否写明 | 逐条阅读用例，标记缺失项 |
| 操作步骤 | 步骤是否有序、可操作，是否含跳步或含糊动词 | 抽样试跑时按步骤实际执行 |
| 测试数据 | 输入数据是否具体，边界值与异常值是否给出 | 试跑时检查能否直接取用 |
| 预期结果 | 结果是否可观察、可判定，是否含具体文案或状态 | 试跑后与实际结果对照 |
抽样试跑用于验证书面核对之外的执行问题。样本量在评估前固定，例如按用例总数抽取一定比例，覆盖不同模块和高优先级检查点对应的用例；抽样方式记录在评估说明中，避免事后挑选。每条试跑用例记录：用例编号、执行人、执行日期、四项证据是否齐全、执行结果、失败原因。
判定标准分三档：四项证据齐全且试跑得到预期结果，判为通过；证据基本齐全、试跑结果与预期存在可解释差异（如环境差异导致），判为部分通过，需补充说明；证据缺失导致无法执行，或试跑结果与预期不符且无法归因于环境，判为不通过。失败原因归为四类：前置条件缺失、步骤不可操作、测试数据不足、预期结果不明确，便于汇总后定向退回修改。
评估步骤：从抽样到出结论的操作顺序
把两项检查组织成固定顺序，才能让不同批次的结果具备可比性。以下步骤可由测试负责人牵头、一名测试人员执行核对、一名评审人复核。
- 确定评估范围与需求版本。记录需求基线、用例批次、评估时间窗，形成评估说明。产出：评估范围说明。
- 拆检查点并标注优先级。从需求与验收条件拆出检查点，逐条标注高、中、低优先级，无法判定的列入待澄清清单。产出：检查点清单。
- 逐条比对命中情况。对每个检查点确认是否有用例触达，记录命中用例编号；同时记录重复覆盖情况。产出：覆盖矩阵与未覆盖清单。
- 抽样并试跑。按事先确定的样本量抽取用例，逐条核对四项证据并实际执行，记录结果与失败原因。产出：试跑记录表。
- 汇总计算与复核。按统一口径计算覆盖率与试跑通过率，复核人抽查命中判定和失败归因是否一致。产出：指标汇总表。
- 输出评审结论与退回修改项。区分可进入评审的用例、需补用例的检查点、需退回修改的用例、需澄清的需求条目。产出：评审结论与修改任务清单。
步骤二和步骤三之间建议安排一次口径确认：命中判定由谁做、边界情况如何计，事先说清，避免复核阶段反复返工。步骤五的复核重点不是重算全部数字，而是抽查判定一致性，例如随机抽取若干检查点核对命中结论。
算例：一批AI生成用例的覆盖与执行结果
以下为演示情景，数值仅用于说明计算过程。某需求版本拆出40个可判定检查点，另有3条需求描述含糊，列入待澄清清单，不计入分母。AI生成用例共62条。
覆盖性计算：逐条比对后，40个检查点中有34个至少被一条用例触达，6个未覆盖。覆盖率 = 34 ÷ 40 × 100% = 85%。未覆盖的6个检查点中，2个为高优先级，4个为中低优先级。重复覆盖方面，有5个检查点被3条以上用例重复覆盖，按口径只计一次命中，重复情况单独记录供后续精简参考。
可执行性计算：按固定样本量抽取20条用例试跑。结果为通过13条、部分通过4条、不通过3条。试跑通过率按通过数除以样本量计算：13 ÷ 20 × 100% = 65%；若将部分通过计入可执行，则为17 ÷ 20 × 100% = 85%，两种口径需在报告中注明采用哪一种。3条不通过的用例中，失败原因分别为前置条件缺失1条、测试数据不足1条、预期结果不明确1条。
处理建议：2个高优先级未覆盖检查点转为待补用例任务，优先处理；4个中低优先级未覆盖项记录后进入后续迭代；3条不通过用例退回修改，修改后重新核对四项证据；4条部分通过用例补充环境说明后进入评审；3条待澄清需求条目提交需求方确认。这批用例的整体结论是“有条件进入评审”，而非“覆盖充分、可以执行”。
结果怎么读：可比性、局限与常见误判
覆盖率是范围指标，不同需求规模之间不能直接横向比较。40个检查点覆盖85%与200个检查点覆盖80%，后者未覆盖的绝对数量更多，风险分布也不同。跨批次比较应限定在同一需求或同类需求内，并同时看未覆盖项的优先级构成。
分母为零或检查点极少时，百分比没有解释力。检查点只有三五个时，一个未覆盖就会让覆盖率大幅波动，此时应直接列出未覆盖清单，不用百分比下结论。需求整体缺失导致无法拆检查点时，结论应写“无法评估”，并转入需求澄清流程。
可执行性抽样结果受样本量和抽样方式限制。20条样本的通过率只能说明这批样本的执行情况，不能外推为全部用例的通过率；样本偏向高优先级用例时，结果反映的是关键路径的可执行性。报告中应写明样本量和抽样规则，避免读者把样本结果当成全量结论。
覆盖率不能替代缺陷发现效果。用例覆盖了检查点，不等于执行后能发现缺陷；AI生成用例还可能出现表述不同但实质重复的情况，推高用例数量却不增加有效覆盖。评估时应同时记录重复覆盖情况，并在解读时说明：覆盖率回答的是“问到了没有”，缺陷发现效果需要另设指标观察。
把检查结果接入缺陷与用例管理流程
评估结论只有回写到管理流程，才会转化为后续动作。未覆盖的高优先级检查点转为待补用例任务，指派给用例编写人；需求含糊导致的待澄清项转为需求澄清任务，提交给需求方确认，两类任务分开跟踪，避免把资料空缺记成用例缺陷。不可执行用例退回修改时，保留失败原因分类和修改记录，修改完成后重新核对四项证据再进入评审。
评估结论与用例评审状态关联：通过覆盖性与可执行性检查的用例进入评审，未通过的停留在待修改状态，评审记录中附上本次评估的指标汇总和未覆盖清单，便于评审人判断准入依据。这样一批用例的状态变化有据可查，下一批AI生成用例也能沿用同一口径对比。
这些流转涉及需求、用例、缺陷三类对象的关联。ONES 中，ONES Assistant 连接 ONES Project、ONES Wiki 与 ONES TestCase，可基于项目与工作项上下文执行操作，例如按指令创建缺陷、更新状态并通知负责人；评估中发现的未覆盖项和退回修改项，可以在需求、用例与缺陷之间建立关联并保留处理记录。具体可用范围以实际产品配置为准。
常见问题
需求描述本身含糊、拆不出可判定的检查点，覆盖率还算不算？
这部分内容不进入分母，单独列入待澄清清单，记为待澄清而不是未覆盖。覆盖率只统计已确认可判定的检查点，否则含糊需求会把指标压低，看起来像用例写得差，实际是需求信息不足。待澄清条目应转成需求澄清任务提交需求方确认，确认后再补入下一期检查点清单。如果整份需求都无法拆出可判定检查点，结论直接写“无法评估”，不用百分比下结论。
一条用例覆盖多个检查点，或者多个检查点被同一条用例反复覆盖，怎么计数？
按检查点计数：一条用例覆盖三个检查点就贡献三个命中，一个检查点被多条用例覆盖只计一次命中。这样用例数量多不会自动推高覆盖率，冗余用例也不会虚增指标。重复覆盖情况建议单独记录，作为后续精简用例的参考，但不进入覆盖率公式。计数口径要在比对开始前说清，复核阶段只抽查判定一致性，不重算全部数字。
抽样试跑的样本量怎么定，结果能不能代表全部用例？
样本量在评估前固定，例如按用例总数抽取一定比例，并覆盖不同模块和高优先级检查点对应的用例，抽样方式写入评估说明，避免事后挑选。样本结果只说明这批样本的执行情况，不能外推为全部用例的通过率；样本偏向高优先级用例时，反映的是关键路径的可执行性。报告中写明样本量和抽样规则，读者才能正确理解结论的适用范围。
部分通过的用例算不算可执行，通过率按哪个口径报？
两种口径都可以用，但必须在报告中注明采用哪一种。只计通过数时，通过率 = 通过条数 ÷ 样本量；把部分通过也计入可执行时，分子为通过加部分通过。部分通过通常指证据基本齐全、试跑结果与预期存在可解释差异（如环境差异），需要补充说明后进入评审。同一批评估内口径保持一致，跨批次比较才有意义。
评估发现的未覆盖项和不可执行用例，怎么落到日常管理流程里？
按问题类型分开处理：高优先级未覆盖检查点转为待补用例任务，指派给用例编写人；需求含糊导致的待澄清项转为需求澄清任务，提交需求方确认；不可执行用例退回修改，保留失败原因分类和修改记录，改完重新核对四项证据再进评审。评审记录附上本次指标汇总和未覆盖清单，用例状态变化有据可查。ONES 中，ONES Assistant 连接 ONES Project、ONES Wiki 与 ONES TestCase，可基于项目与工作项上下文执行操作，例如按指令创建缺陷、更新状态并通知负责人，便于在需求、用例与缺陷之间建立关联并保留处理记录，具体可用范围以实际产品配置为准。
