评估一批AI测试用例草稿的质量，需要把“好不好用”拆成覆盖率、可执行性、冗余度和人工修改量四个可复算的指标，并统一评估范围、分子分母和缺失值处理方式。单个指标容易给出误导性结论，组合解读才能支撑准入、抽检或迭代改进的判断。评估过程中的需求与用例映射、评审意见和修改留痕，可以在ONES测试管理相关流程中承载，便于后续复核。
要点总览（TL;DR）
- 评估AI测试用例草稿质量，需要先固定评估对象、用途和范围（需求批次、版本、时间窗、用例层级），再统一四个指标的分子、分母、单位和缺失值处理方式。
- 需求覆盖率按“已覆盖需求点数/需求点总数”计算，前提是先拆分需求点并约定粒度；可执行性按“可直接执行用例数/抽检用例数”计算，判定标准写成前置条件、步骤、预期结果和测试数据四项检查。
- 冗余度按“重复或高度相似用例数/用例总数”计算，相似口径需事先约定；人工修改量可用修改字段数或修改工时除以草稿规模，并说明统计字段和是否含整条重写。
- 评估按建立需求—用例映射、逐条判定、统计修改量、按公式计算、交叉分析五步执行，保留中间数据以便复算；分母为零或样本过少时只报告绝对条数并注明样本不足。
- 四个指标需组合解读：高覆盖可能伴随高冗余，低修改量可能只是草稿保守；阈值应结合自身基线和业务风险确定，评估结果反馈到提示词、模板和评审流程形成闭环。
评估目标：先明确草稿质量要回答什么问题
评估开始前先写一份目标说明，固定三件事：评估对象、评估用途、评估范围。三要素确定后，指标取舍和严格程度才有依据，不同批次之间也才具备可比性。
评估对象是AI生成的用例草稿，关注草稿本身是否覆盖需求、能否直接执行、是否重复、需要人工改多少。用例执行后的通过率、缺陷发现能力属于执行结果评估，与本方法分开统计，避免把两类数据混在一张表里。
评估用途决定指标的权重和判定严格程度。常见用途有四类：
- 准入判断：决定这批草稿能否进入正式用例库，通常对可执行性和覆盖率的判定更严。
- 抽检：按周期抽查草稿质量趋势，样本量可以小一些，但口径必须稳定。
- 供应商或模型对比：在同一批需求、同一评审标准下比较不同来源的草稿，重点看修改量和冗余度差异。
- 迭代改进：定位草稿的薄弱环节，反馈到提示词、用例模板和评审流程。
评估范围需要写清四项：需求批次（哪一批需求或哪个需求文档）、版本（对应的产品版本或迭代）、时间窗（草稿生成到评审完成的时间段）、用例层级（功能用例、接口用例或端到端场景用例）。范围不同，指标数值不可直接比较，例如只统计核心功能用例的覆盖率通常高于全量统计。
指标与范围：覆盖率、可执行性、冗余度、修改量怎么定义
四个指标各自回答一个独立问题，定义时要同时给出公式、分子、分母、单位和统计时间窗。下表给出建议口径，团队可在此基础上调整，但同一评估周期内应保持一致。
| 指标 | 公式 | 分子 | 分母 | 单位 | 缺失值处理 |
|---|---|---|---|---|---|
| 需求覆盖率 | 已覆盖需求点数 / 需求点总数 | 至少被一条草稿用例覆盖的需求点数量，同一需求点被多条用例覆盖只计一次 | 评估范围内拆分出的需求点总数 | 百分比 | 需求描述不清、无法拆分的条目单列为“待澄清”，不计入分母，单独报告数量 |
| 可执行性 | 可直接执行用例数 / 抽检用例数 | 前置条件、操作步骤、预期结果齐全，且引用的测试数据可获取的用例数 | 纳入评审的草稿用例数 | 百分比 | 评审人无法判定的用例记为“待定”，不计入分子，在结果中注明待定条数 |
| 冗余度 | 重复或高度相似用例数 / 用例总数 | 与同批其他用例在步骤和预期结果上高度重合的用例数，保留一条计为有效，其余计为冗余 | 草稿用例总数 | 百分比 | 相似判定存在分歧时由第二评审人复核，复核前不计入分子 |
| 人工修改量 | 修改字段数 / 草稿字段总数，或修改工时 / 草稿用例数 | 评审后被修改的字段数量或投入的修改工时 | 草稿字段总数或用例条数 | 百分比或小时/条 | 整条重写的用例单独标记，其修改量按重写工时计入并注明条数 |
需求覆盖率的计算前提是先建立需求点清单。需求点按可独立验证的行为拆分，例如一条需求包含“新增、编辑、删除、权限校验”四个行为，就拆为四个需求点。拆分粒度需要在评估前约定并写入说明，粒度过粗会高估覆盖率，过细会放大分母、压低数值。
可执行性的判定标准建议写成检查项：前置条件是否写明环境与数据准备、操作步骤是否可照着操作、预期结果是否可观察和比对、是否引用了实际可获取的测试数据。四项齐全才算可直接执行，缺一项即计入不可执行，并记录缺失类型，便于后续分析。
冗余度的相似判定需要事先约定口径，常用做法是步骤与预期结果的重合程度达到约定比例即视为高度相似。口径不统一时，不同批次的冗余度没有可比性。人工修改量要说明统计哪些字段（如标题、步骤、预期结果、优先级）、由谁统计、是否包含评审驳回后的整条重写。
指标有适用边界。需求点尚未澄清、需求文档频繁变更的批次，覆盖率数值参考价值有限；草稿数量很少时，百分比波动大，应同时报告绝对条数；修改量受评审人严格程度影响明显，跨团队比较前需确认评审标准一致。
数据口径与证据：草稿、需求和评审记录怎么取数
取数的第一步是建立需求点与草稿用例的对应关系。可以从需求文档拆出需求点清单，为每个需求点编号，再在每条草稿用例上标注其覆盖的需求点编号。一条用例覆盖多个需求点时全部标注，统计覆盖率时按需求点去重计数。对应关系建立后，覆盖状态分为已覆盖、未覆盖、待澄清三类，逐条可查。
全量与抽样的选择取决于评估用途。准入判断和供应商对比建议全量评审，结论更稳；周期性抽检可以抽样，但需说明抽样方法（如按用例层级分层随机抽取）和样本量。样本量过小时，结果只作趋势参考，并在报告中注明样本条数。
多人评分时要做一致性检查。可行做法是双人独立打分，对判定不一致的用例进行复核并记录最终结论；一致性比例过低时，先修订判定标准再继续评分，避免把评分分歧误读为草稿质量问题。
定性证据用于解释定量结果，需要同步留存：评审意见原文、驳回原因分类、修改前后的字段对比、整条重写的用例清单。这些记录让“修改量为什么高”可以被追溯到具体原因，例如前置条件缺失集中出现，说明提示词或模板需要补充环境描述要求。
缺失数据和不可比情况要单独记录：哪些需求点因描述不清未纳入统计、哪些用例评审未完成、哪些批次因口径调整不能与历史数据直接比较。记录本身也是评估报告的一部分，避免读者把不完整数据当成完整结论。
计算与评估步骤：从打分到汇总的可复算流程
评估按以下五步执行，每一步都保留中间数据，保证他人可以按同样口径复算。
- 建立需求点—用例映射并标记覆盖状态。产出需求点清单、用例与需求点编号对照表、覆盖状态列。完成标志是每个需求点都有明确的覆盖状态，待澄清条目单独列出。
- 逐条判定可执行性与冗余。按检查项对每条用例打“可执行/不可执行/待定”，并记录缺失类型；按相似口径标记冗余用例，保留一条为有效。完成标志是每条用例都有判定结果和判定人。
- 统计人工修改量与修改类型。记录被修改的字段数或修改工时，按字段类型和驳回原因分类汇总，整条重写的用例单独计数。
- 按公式计算各指标并保留中间数据。计算表建议包含：需求点编号、覆盖状态、用例编号、可执行判定、冗余标记、修改字段数、修改工时、评审人、评审日期。汇总表按指标列出分子、分母、结果和样本量。
- 交叉分析，识别矛盾信号。把四个指标放在一起看，例如覆盖率与冗余度同时偏高，说明草稿在堆用例而非精准覆盖；修改量低但覆盖率也低，说明草稿写得保守、覆盖不足。
分母为零和样本过少的处理要写进口径：评估范围内没有需求点时，覆盖率不计算，标注“无适用样本”；抽检用例少于约定下限时，只报告绝对条数并注明样本不足，不据此下准入结论。跨批次比较前核对需求点拆分粒度、相似判定口径和评审人是否一致，任一项变化都应在报告中说明。
例子：一批AI用例草稿的完整评估演示
以下为演示情景，数字均为假设，用于说明计算过程，不代表任何真实项目数据。
假设某迭代有40个需求点，AI生成草稿用例120条，评审抽取全部120条，由两名评审人独立判定后复核分歧。
- 需求覆盖率：40个需求点中32个至少被一条用例覆盖，3个因需求描述不清列为待澄清不计入分母，实际分母为37，覆盖率为32/37≈86.5%。
- 可执行性：120条用例中84条前置条件、步骤、预期结果齐全且测试数据可获取，12条待定，可执行性为84/120=70%。不可执行的36条中，21条缺前置条件，9条预期结果不可观察，6条引用了不存在的测试数据。
- 冗余度：按步骤与预期结果高度重合的口径标记，18条与同批其他用例高度相似，冗余度为18/120=15%。
- 人工修改量：120条用例共960个字段，评审后修改了216个字段，修改字段占比为216/960=22.5%；另有8条整条重写，单独记录。
结果组合的解读方式不同：覆盖率86.5%配合冗余度15%，说明覆盖较全但存在一定重复，可优先合并相似用例；可执行性70%偏低，且缺失集中在“前置条件”，提示草稿模板或提示词需要强化环境与数据准备描述；修改字段占比22.5%属于中等水平，结合驳回原因看，多数修改来自补充前置条件，与可执行性问题指向一致。
若另一批草稿出现覆盖率95%、冗余度40%的组合，说明草稿靠大量重复用例堆出覆盖，实际有效覆盖并未同步提升；若出现修改量5%、覆盖率60%的组合，则要警惕草稿写得过于笼统、评审放行过松。演示中的阈值仅用于说明组合关系，实际使用应结合自身基线确定。
解读与限制：指标说明什么、不能说明什么
四个指标需要组合解读。覆盖率反映需求点是否被触及，可执行性反映草稿能否直接使用，冗余度反映草稿的精简程度，修改量反映人工返工成本。任一指标单独拿出来都可能得出片面结论：覆盖率高可能伴随严重冗余，修改量低可能只是草稿保守、覆盖不足。
覆盖率不等于测试有效性。需求点被覆盖只说明有用例对应，用例能否发现缺陷取决于场景设计深度和执行结果，这部分需要结合执行阶段的缺陷数据另行评估。冗余度低也不等于覆盖充分，草稿可能条条不同但都停留在表面路径。
修改量受评审严格程度影响明显。同一批草稿在不同评审标准下，修改字段数可能相差很大，跨批次、跨团队比较前必须确认评审人、判定标准和统计字段一致，否则数值差异更多反映评审尺度而非草稿质量。
不建议设通用达标线。阈值应结合团队自身历史基线和业务风险确定，例如核心交易链路的草稿可执行性要求高于内部工具类需求。首次评估可以先建立基线，后续批次与基线对比看趋势。
评估结果要形成闭环：把不可执行用例的缺失类型反馈到用例模板和提示词，把冗余集中的场景补充到生成约束，把评审分歧点沉淀为判定标准。下一批次用同一口径复评，才能看出改进是否生效。评估过程中的需求与用例关联、评审意见和修改记录如果分散在文档和表格里，复核成本会很高；ONES Assistant 可连接 ONES Project、ONES Wiki 与 ONES TestCase，基于项目、工作项和 Wiki 页面等工作上下文回答问题并执行后续操作，评估所需的映射关系和评审留痕可以在同一套测试管理流程中留存，便于按批次追溯和复算。
常见问题
需求点拆分粒度不同，覆盖率还能跨批次比较吗？
拆分粒度不同，覆盖率的分母就不同，跨批次直接比较会失真。可行做法是在首次评估时把拆分规则写入说明，例如按可独立验证的行为拆分，一条需求包含新增、编辑、删除、权限校验就拆为四个需求点。后续批次沿用同一规则；确需调整时，在报告中注明调整点和影响范围，并把调整前后的数据分开呈现，避免把口径变化误读为质量变化。
评审人之间对“可执行”判定不一致时怎么处理？
先做双人独立打分，再对不一致的用例复核并记录最终结论。如果一致性比例持续偏低，说明判定标准本身有歧义，应先修订检查项再继续评分，例如把“预期结果可观察”细化为可比对的具体字段或状态。评分分歧属于标准问题，不宜直接算作草稿质量缺陷；复核结论和修订后的标准都应留档，供下一批次沿用。
人工修改量统计字段数还是工时更合适？
两种口径回答的问题不同。字段数适合比较草稿在结构上的返工范围，统计成本低，但无法反映修改难度；工时能体现实际投入，适合评估返工成本，但受评审人熟练度影响。建议主口径选一种并保持稳定，另一种作为辅助参考。无论选哪种，都要说明统计哪些字段、由谁统计、整条重写的用例如何计入，否则跨批次数据不可比。
草稿数量很少时，四个指标还有参考价值吗？
样本很少时百分比波动大，单个批次的数值参考价值有限。此时应同时报告绝对条数，例如“12条中9条可执行”，并注明样本不足，不据此下准入结论。可以把多个小批次按同一口径合并统计，或延长观察周期看趋势。若必须对小批次做判断，优先看具体缺失类型和评审意见，而不是只看百分比。
评估结果如何反馈到下一批草稿的生成和评审？
把不可执行用例的缺失类型归类，反馈到用例模板和提示词，例如前置条件缺失集中出现，就在模板中补充环境与数据准备要求；把冗余集中的场景补充为生成约束；把评审分歧点沉淀为判定标准。下一批次用同一口径复评，与基线对比看趋势。评估过程中的需求与用例关联、评审意见和修改记录如果分散保存，复核成本会很高；ONES Assistant 可连接 ONES Project、ONES Wiki 与 ONES TestCase，基于项目、工作项和 Wiki 页面等工作上下文回答问题并执行后续操作，相关映射关系和评审留痕可以在同一套测试管理流程中留存，便于按批次追溯。
