评估一批AI测试用例草稿是否可用，需要把“看起来完整”拆成可复算的指标。建议围绕需求覆盖率、可执行性、冗余度和人工修改量建立统一口径：先固定需求基线与统计范围，再明确每项指标的分子、分母和单位，抽样人工核验后计算得分。四项指标分别反映草稿的完整度、落地成本与信息密度，单项结果不足以判断整批草稿的质量。
要点总览（TL;DR）
- 评估AI测试用例草稿质量，建议同时统计需求覆盖率、可执行性、冗余度和人工修改量四项指标，单项结果不足以判断整批草稿是否可用。
- 每项指标都要写清分子、分母、单位和时间窗：覆盖率按验收点计，可执行性按抽检用例计，冗余度按相似用例计，修改量按字段或工时摊薄到每条用例。
- 评估流程为冻结需求基线、分层抽样、双人独立核验并记录分歧、按口径计算、汇总时标注样本量与置信范围，原始记录保留以便复算。
- 指标反映草稿特征，不能等同于最终测试效果；样本偏差、需求变更和相似判定的主观性都会造成失真，宜与项目历史基线对比而非套用通用达标线。
- 解读时结合人工修改的具体内容归类，判断问题出在需求理解、步骤粒度还是去重，据此调整下一轮生成方式与评估口径。
评估目标：草稿质量要回答哪几个问题
评估开始前先写清结论要支持什么决策，否则指标容易越加越多，最后无法回答具体问题。AI测试用例草稿的评估通常服务三类决策：这批草稿能否进入评审或直接采纳；需要投入多少人工返工；当前生成方式是否值得继续使用、应在哪些环节调整提示词或补充上下文。
与这三类决策对应，质量可以拆成四个待回答的问题：
- 完整度：需求中的验收点在草稿里有没有对应的用例，遗漏集中在哪些模块。
- 可执行性：草稿是否具备执行条件，前置条件、操作步骤、预期结果是否清楚到测试人员可以直接照做。
- 信息密度：草稿中是否存在大量重复或高度相似的用例，占用评审与维护成本却不增加覆盖。
- 人工成本：从草稿到可用用例，人工需要改动多少字段、投入多少工时。
评估对象限定为AI生成的用例草稿本身，包括用例标题、前置条件、步骤和预期结果等文本内容。测试执行脚本的编写维护、模型训练与调优不在本文范围内，它们有各自的评估方式，混在一起会让指标失去解释力。
建议在评估启动时形成一页评估目标说明，写明本次评估服务的决策、待回答的问题、评估对象和结论使用人。这份说明同时约束后续的抽样范围和统计口径，避免不同批次评估各算各的。
指标与范围：四项指标的定义与边界
四项指标各自衡量草稿的一个侧面，需要同时统计、分别解释。下表给出定义与统计对象，具体公式在下一节展开。
| 指标 | 衡量什么 | 统计对象 | 回答的问题 |
|---|---|---|---|
| 需求覆盖率 | 草稿对需求验收点的覆盖程度 | 需求基线中的验收点与草稿用例的对应关系 | 有没有漏测 |
| 可执行性 | 草稿达到可执行标准的比例 | 抽检的草稿用例 | 能不能直接拿去测 |
| 冗余度 | 重复或高度相似用例的占比 | 整批草稿用例 | 信息密度是否过低 |
| 人工修改量 | 把草稿修到可用所需的人工投入 | 被修改的字段或工时，按草稿用例数摊薄 | 返工成本有多高 |
统计范围要在评估前固定，至少写明四项内容：本次纳入评估的需求清单及其版本、涉及的模块或功能域、参与评估的草稿批次（例如某次生成任务产出的全部用例）、数据统计的时间窗。范围一旦变动，前后两批结果就不具备可比性，需要在报告中注明。
四项指标之间不能互相替代。覆盖率高的草稿可能步骤含糊、无法执行；可执行性好的草稿可能在同一验收点上反复生成相似用例；冗余度低的草稿也可能因为大量字段需要改写而推高人工成本。用单一指标给草稿下“合格”或“不合格”的结论，容易掩盖真正需要改进的环节。实践中更合适的做法是四项并列呈现，再结合评估目标判断哪一项是当前的主要瓶颈。
数据口径：分子分母、单位与缺失值处理
口径的作用是让不同人、不同批次按同一方式复算。每项指标都要写清分子、分母、单位和分母来源，下面给出建议口径，团队可在此基础上按项目情况微调，但调整后应保持稳定。
需求覆盖率
需求覆盖率 = 被草稿覆盖的验收点数量 ÷ 需求基线验收点总数 × 100%。分母来自评估前冻结的需求基线，验收点需要逐条编号，便于核对。判定“被覆盖”的标准要事先约定，例如草稿中存在至少一条用例，其步骤或预期结果能够验证该验收点的主要行为。一个验收点被多条用例覆盖时只计一次。
可执行性
可执行性 = 按既定标准通过人工核验的用例数 ÷ 抽检用例数 × 100%。核验标准建议列成检查项：前置条件是否具备、操作步骤是否可照做、预期结果是否可判定、测试数据是否明确。全部检查项通过才计为通过，部分通过不计入分子，但可在记录中标注缺失项，供后续分析使用。
冗余度
冗余度 = 重复或高度相似用例数 ÷ 草稿用例总数 × 100%。这项指标的前提是先定义相似判定规则，例如两条用例的验证目标相同且步骤重合度超过约定比例即判为相似，保留其中一条，其余计入冗余。相似判定带有主观性，规则需要书面化，并由核验人员在评估前统一试判一批样本、对齐尺度。
人工修改量
人工修改量 = 人工修改的字段数 ÷ 草稿用例数，单位为“字段/条”；也可以按工时统计，即修改总工时 ÷ 草稿用例数，单位为“分钟/条”或“小时/条”。两种口径选其一并注明，字段口径需要列出纳入统计的字段范围，例如标题、前置条件、步骤、预期结果，未列入的字段不计。
缺失值与边界情形
- 分母为零：某模块没有验收点或没有抽检到用例时，该模块的比率不计算，在报告中标注“不适用”，不用0%或100%代替。
- 需求中途变更：变更发生在评估时间窗内时，以评估启动时冻结的基线为准计算，变更后的需求另起一批评估，两批结果不合并。
- 草稿未覆盖的模块：在覆盖率计算中计入分母、不计入分子，同时在报告中单列未覆盖模块清单，避免被总体比率稀释。
- 核验数据缺失：个别用例因信息不足无法判定时，从该项指标的分母中剔除并记录数量，剔除比例过高时需说明对结果的影响。
评估步骤：从抽样到出分的操作流程
流程的目标是让不同评估人按同一顺序操作，得到可以横向比较的结果。建议按以下五步执行，并为每一步留下记录。
- 确定需求基线与验收点清单。从需求文档或需求管理工具中导出本次评估范围内的需求，逐条拆出验收点并编号，冻结版本。完成标志是验收点清单经过需求负责人确认，后续计算以此为准。
- 分层抽样草稿用例。按模块或风险等级分层，高风险模块提高抽样比例，低风险模块可适当降低。抽样数量要足以支撑结论，抽样比例和实际抽到的条数都记录在案。完成标志是抽样清单确定，且覆盖所有纳入评估的模块。
- 双人独立核验并记录分歧。两名核验人分别按检查项判定可执行性、标注相似用例、记录修改字段，完成后比对结果。分歧逐条讨论，形成判定结论，并把分歧原因归类，例如标准理解不一致、用例信息不足。完成标志是分歧全部有结论，判定标准如有修订则同步更新到检查项。
- 按口径计算四项指标。使用统一的记录表汇总原始数据，逐项代入公式，保留分子、分母和中间结果，便于他人复算。完成标志是四项指标均有计算过程和原始数据支撑。
- 汇总结果并标注样本量与置信范围。报告中写明抽样条数、占整批草稿的比例、核验人数和分歧条数。样本量较小时，结论应表述为趋势判断，并说明扩大样本后可能的变化。
记录表建议至少包含这些列：用例编号、所属模块、对应验收点编号、可执行性判定及缺失项、相似组编号、修改字段数、核验人、分歧标记。原始记录保留下来，下一批评估可以直接复用表结构，减少口径漂移。
评估过程涉及需求、用例与核验记录的流转，如果团队已经在ONES中管理需求和测试用例，可以把验收点清单、草稿用例和核验结论放在同一套工作项与文档体系里，减少跨工具核对。ONES Assistant可连接ONES Project、ONES Wiki与ONES TestCase，理解项目、工作项、迭代和Wiki页面等工作上下文，并基于相关项目数据和团队知识回答问题、执行后续操作，适合在评估前后辅助定位需求背景与整理记录；具体的草稿质量指标统计仍需按本文口径人工或另行配置完成。
示例：一批草稿的四项指标怎么算
以下数据为演示用途，用于说明计算过程，不代表任何项目的达标水平。
假设某次评估纳入两个模块，需求基线共40个验收点，其中订单模块28个、支付模块12个。本次生成草稿共200条用例，按分层抽样抽取50条进行人工核验，其中订单模块35条、支付模块15条。核验结果：50条中38条通过全部可执行性检查；整批200条中判定为重复或高度相似的用例24条；抽检的50条用例人工共修改字段126个。
| 指标 | 计算过程 | 结果 |
|---|---|---|
| 需求覆盖率 | 草稿覆盖验收点34个 ÷ 基线验收点40个 | 85% |
| 可执行性 | 通过核验38条 ÷ 抽检50条 | 76% |
| 冗余度 | 相似用例24条 ÷ 草稿总数200条 | 12% |
| 人工修改量 | 修改字段126个 ÷ 抽检50条 | 2.52字段/条 |
覆盖率计算中，未覆盖的6个验收点需要单列。假设其中5个集中在支付模块，1个在订单模块，说明遗漏并非均匀分布，返工应优先补支付模块的用例。若某个模块在基线中没有任何验收点，该模块覆盖率标注为“不适用”，不参与总体比率的合并计算。
可执行性还可以进一步拆分：未通过的12条中，8条缺少明确的预期结果，3条前置条件不清，1条步骤无法照做。这类拆分不改变指标结果，但能直接指向生成方式的调整方向。
人工修改量按字段口径统计时，需要说明126个字段的构成，例如标题修改18处、步骤修改72处、预期结果修改36处。若团队更关注工时，可改为记录修改总工时，再除以抽检条数，两种口径不混用。
解读与限制：结果怎么看、哪里会失真
四项指标描述的是草稿本身的特征，不能直接等同于最终测试效果。覆盖率高说明验收点在草稿中有对应，不代表这些用例在真实环境中一定能发现缺陷；可执行性高说明用例写得清楚，不代表测试设计思路正确。把指标当作质量保证的因果证明，会高估草稿的实际价值。
结果解读时需要注意几类失真来源：
- 样本偏差：抽样集中在低风险或结构简单的模块，指标会偏乐观。分层抽样和记录抽样比例是基本的控制手段，样本量小时结论只作趋势参考。
- 需求变更：评估期间需求发生调整，旧基线下的覆盖率会失真。冻结基线、变更另起一批评估，可以避免新旧数据混算。
- 相似判定的主观性：冗余度对判定规则敏感，规则模糊时不同核验人可能给出差异较大的结果。评估前试判、评估中记录分歧，是降低主观性的可行做法。
- 修改字段的统计范围：只统计部分字段会让修改量偏低，字段范围需要在多批评估之间保持一致。
不建议为四项指标设定通用达标线。不同项目的需求粒度、测试成熟度和风险承受能力差异很大，统一的阈值容易造成误判。更实用的做法是与本项目的历史基线对比，观察同一生成方式在多批草稿上的变化趋势；跨项目比较时，先确认口径一致再解读差异。
指标之外，还应查看人工修改的具体内容。修改集中在预期结果，往往说明生成时对需求理解不足；修改集中在步骤，可能是拆解粒度过粗；大量用例被判为相似，则提示生成时缺少去重或覆盖视角。把这些修改内容归类统计，比单看修改量数字更能指导下一轮生成方式的调整。评估结论最终应落到具体动作上：哪些模块需要补用例、哪类字段需要加强约束、是否继续采用当前生成方式，以及下一批评估需要调整的口径。
常见问题
四项指标里如果只能先看一项，应该选哪个？
取决于本次评估要支持的决策。如果结论用于判断草稿能否进入评审，先看可执行性，因为它直接决定测试人员能否照做；如果用于评估返工投入，先看人工修改量；如果用于判断生成方式是否值得继续使用，需求覆盖率和冗余度更能说明生成环节的结构性问题。无论先看哪一项，报告中都应保留四项结果，避免后续解读时缺少对照。
抽检多少条用例才算够？
没有统一数量，判断依据是结论需要的精度和模块的风险分布。高风险模块应提高抽样比例，低风险模块可适当降低，但每个纳入评估的模块都要有样本。样本量较小时，结论表述为趋势判断，并说明扩大样本后可能的变化。报告中写明抽样条数、占整批草稿的比例和核验人数，便于他人判断结论的可靠程度。
两名核验人对同一条用例判定不一致时怎么处理？
先逐条讨论，形成最终判定，再把分歧原因归类，例如检查项理解不一致、用例信息不足、相似判定尺度不同。如果分歧来自标准本身模糊，应修订检查项并同步到后续评估；如果来自用例信息缺失，则记录为该项指标的缺失数据。分歧条数和原因分布要写进报告，它是判断口径是否稳定的直接依据。
需求在评估期间发生变更，之前的覆盖率还能用吗？
以评估启动时冻结的需求基线为准计算，变更后的需求另起一批评估，两批结果不合并。这样处理可以保证同一批数据内部口径一致。如果变更影响到已抽检用例的判定，需要在报告中注明变更内容和影响范围，避免读者把新旧基线下的比率直接对比。
评估过程中产生的需求、用例和核验记录怎么管理？
建议把验收点清单、草稿用例和核验结论放在同一套工作项与文档体系中，减少跨工具核对。如果团队使用ONES管理需求和测试用例，可以借助ONES Assistant连接ONES Project、ONES Wiki与ONES TestCase，理解项目、工作项、迭代和Wiki页面等工作上下文，辅助定位需求背景与整理记录；四项指标的具体统计仍需按本文口径人工完成或另行配置。
