如何评估AI测试用例草稿的质量：四项指标与判定方法

评估AI测试用例草稿的质量，需要一套可复算的口径，而不是凭评审时的整体印象。建议围绕需求覆盖率、可执行率、冗余率和人工修改率四项指标，先固定需求基线与草稿范围，再逐条判定、汇总计算，并结合抽样复核给出采用、返工或进入评审的结论。指标反映草稿与需求、执行条件之间的匹配程度，需要与缺陷发现情况一起解读。

要点总览（TL;DR）

• 评估AI测试用例草稿，先锁定需求基线版本和草稿用例清单，再按需求覆盖率、可执行率、冗余率、人工修改率四项指标逐条判定、汇总计算。
• 四项指标都以草稿用例清单为统计对象，分母为零时记为“不适用”；需求点拆分粒度、“少量补充”的界限、冗余判定规则和实质性修改的认定标准需事先约定。
• 评估流程为确定范围、选择全量或分层抽样、逐条判定四类状态、汇总计算、评审给出通过或有条件通过或返工结论，结论与计算表一并归档。
• 指标只反映草稿与需求、执行条件的匹配程度：高覆盖率不代表用例有效，低冗余不代表设计充分，人工修改率受评审人习惯影响，需与缺陷发现率、回归通过率交叉验证。
• 达标线结合团队历史基线和业务风险确定，高风险模块可提高覆盖率与可执行率要求，一般模块适当放宽。

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

评估对象是AI根据需求生成的测试用例草稿，包括用例标题、前置条件、操作步骤和预期结果。执行脚本、自动化代码和模型本身的调优不在评估范围内。明确这一边界，可以避免把“模型好不好”与“这批草稿能不能用”混为一谈。

针对一份草稿，评估要回答四个问题：需求中的每个测试点是否至少有一条用例对应；用例写出的步骤和预期结果在当前环境下能否直接执行；草稿内部是否存在重复或高度相似的用例；评审人为了让它可用，实际改动了多少。这四个问题分别对应覆盖率、可执行性、冗余度和人工修改量。

评估结论用于做三类决定：达到约定标准的草稿直接进入正式评审或纳入用例库；部分指标偏低的草稿有条件通过，限定补充范围；多项指标同时偏低的草稿退回重新生成或人工重写。结论应写明依据的指标值和抽样范围，便于后续复查。

指标与范围：四项指标的定义与计算口径

四项指标都以草稿用例清单为统计对象，统计单位是“条用例”或“个需求点”，统计时间窗为本次评估所覆盖的草稿批次。计算前先确定分母，分母为零时该指标记为“不适用”，不按0%处理，也不参与综合判断。

指标	定义	公式	分母与单位
需求覆盖率	被至少一条草稿用例覆盖的需求点占全部需求点的比例	被覆盖需求点数 ÷ 需求点总数 × 100%	分母为需求基线中的需求点总数，单位为个
可执行率	可直接执行或仅需少量补充即可执行的用例占比	可执行用例数 ÷ 草稿用例总数 × 100%	分母为草稿用例总数，单位为条
冗余率	重复或高度相似的用例占比	重复或高度相似用例数 ÷ 草稿用例总数 × 100%	分母为草稿用例总数，单位为条
人工修改率	被人工修改过的用例占比，辅以修改行数或字段数	被修改用例数 ÷ 草稿用例总数 × 100%	分母为草稿用例总数，单位为条；辅助记录修改行数、字段数

几个口径需要事先约定。需求点的拆分粒度决定覆盖率的分母，建议以需求条目下的可验证功能点为单位，同一功能点不重复计数。可执行性的“少量补充”要给出明确界限，例如只允许补充测试数据或环境说明，步骤和预期结果需要重写的计为不可执行。冗余判定采用统一规则，例如同一需求点下操作步骤和预期结果实质相同的用例计为重复，仅数据不同的参数化用例不计入冗余。人工修改率要区分实质性修改与格式调整，只把影响步骤、预期结果或前置条件的改动计入，并记录修改原因分类。

数据口径与证据：需求基线、用例清单和修改记录怎么取

结果可复算的前提是数据来源固定。评估开始前锁定需求基线版本，导出需求条目清单，包含需求编号、名称、所属模块和版本号，这份清单就是覆盖率的分母。草稿生成后若需求发生变更，应重新锁定基线并说明变更范围，不能把两个版本的需求混在一起统计。

草稿用例清单需要包含用例编号、关联需求编号、前置条件、操作步骤、预期结果和生成批次。关联需求字段是计算覆盖率的关键，缺失关联的用例单独列出，由评审人补判归属后再计入统计，不能默认视为已覆盖。

可执行性判定需要环境证据：测试环境是否可用、所需账号和测试数据是否具备、前置条件是否能在当前版本复现。评审人逐条核对后标记“可直接执行”“少量补充可执行”“不可执行”三种状态，并写明不可执行的原因，例如缺少测试数据、步骤指向不存在的入口、预期结果无法验证。

修改记录通过对比人工编辑前后的用例内容获得，保留修改前后的版本或差异记录，并按原因分类，例如补充边界条件、修正预期结果、拆分步骤、调整表述。抽样复核记录同样要留痕：抽样比例、抽样方式、复核人和每条用例的判定结论。抽样建议覆盖不同需求模块和不同生成批次，避免只抽容易判断的用例。

评估步骤：从抽样到判定的操作流程

第一步，确定评估范围和需求基线版本，明确本次评估覆盖哪些需求模块、哪一批草稿用例，以及统计截止时间。范围一旦确定，中途新增的用例不计入本批次。

第二步，选择全量统计或抽样统计。草稿量较小时建议全量判定；草稿量较大时按需求模块分层抽样，抽样比例根据评审资源确定，并在报告中写明。抽样统计的结论只代表抽样范围，不外推到未抽中的用例。

第三步，逐条判定四类状态：该用例关联的需求点是否被覆盖、用例是否可执行、是否与已有用例重复或高度相似、人工是否做过实质性修改。每条判定都要有依据，覆盖看关联关系，可执行看环境与步骤，冗余看比对结果，修改看差异记录。

第四步，汇总计算。先统计各指标的分母，再统计分子，按公式计算比例，保留一位小数。分母为零的指标标注“不适用”。同时记录辅助数据，例如平均每条用例的修改行数、不可执行原因分布。

第五步，组织评审给出结论。评审会上对照事先约定的标准逐项确认，形成“通过”“有条件通过”“返工”三类结论之一，并写明后续动作、责任人和复查时间。结论记录与指标计算表一并归档，作为下一批次评估的对比基线。

在需求条目、用例草稿和评审记录分散于不同工具时，取数和比对会消耗大量时间。ONES 的需求管理与 TestCase 可以在同一平台内关联需求与用例，ONES Assistant 智能助手连接 ONES Project、ONES Wiki 与 ONES TestCase，能够理解项目、工作项和迭代等真实工作上下文，并基于相关项目数据回答问题、执行后续操作，便于在评估时按需求追溯对应用例和评审记录。具体可用的统计口径仍需按团队配置确认。

例子：一份草稿的四项指标怎么算

以下为演示情景，数字用于说明计算过程。某需求模块锁定基线后共有40个需求点，AI生成草稿用例120条，评审团队全量判定，同时抽取30条做二次复核。

覆盖率：40个需求点中，有34个至少被一条草稿用例关联覆盖，需求覆盖率 = 34 ÷ 40 × 100% = 85.0%。剩余6个需求点中，3个完全没有对应用例，3个只有关联标记但用例内容与需求点不符，按未覆盖处理。

可执行率：120条用例中，82条可直接执行，20条补充测试数据后可执行，18条因步骤指向不存在的入口或预期结果无法验证判为不可执行。可执行率 = (82 + 20) ÷ 120 × 100% = 85.0%。

冗余率：比对后发现9条用例与同模块其他用例在步骤和预期结果上实质相同，冗余率 = 9 ÷ 120 × 100% = 7.5%。

人工修改率：评审过程中有46条用例被实质性修改，人工修改率 = 46 ÷ 120 × 100% = 38.3%，平均每条被修改用例改动3.2行。若某指标分母为零，例如本批次没有生成任何用例，则该指标记为不适用，不参与结论判断。

结果解读：覆盖率85.0%说明多数需求点已有对应用例，但仍有6个需求点需要补充；可执行率85.0%中的18条不可执行用例需要优先处理，因为它们会直接阻塞执行；冗余率7.5%处于可接受范围，可合并重复用例；人工修改率38.3%偏高，提示草稿在步骤完整性和预期结果准确性上需要改进。综合来看，这份草稿适合“有条件通过”，补充缺失需求点、修复不可执行用例后进入正式评审。

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

高覆盖率只说明需求点有对应用例，不说明用例能发现缺陷。一条覆盖了需求点但步骤笼统、预期结果模糊的用例，覆盖率统计会计入，实际执行时可能什么都验证不了。因此覆盖率要与可执行率和缺陷发现情况一起看，覆盖率高的批次如果执行后缺陷发现很少，需要复查用例的验证深度。

冗余率低也不代表用例设计充分。冗余率只衡量重复程度，用例数量少、覆盖浅的草稿同样可以做到低冗余。判断设计是否充分，要看覆盖率、边界条件和异常场景的覆盖情况，必要时补充场景维度的检查。

人工修改率受评审人习惯影响明显。有的评审人倾向逐字改写，有的只做必要修正，同一份草稿在不同评审人手里的修改率可能相差很大。使用这一指标前要统一修改判定标准，明确哪些改动计入、哪些不计入，并尽量保持评审人相对稳定，否则跨批次比较没有意义。

四项指标适合判断草稿是否达到进入评审或执行的门槛，不适合单独作为模型效果或团队绩效的评价依据。建议与缺陷发现率、回归通过率、用例维护成本等结果指标交叉验证：草稿进入用例库后，跟踪其发现的缺陷数量和后续修改频次，用实际结果校正指标口径和判定标准。达标线应结合团队历史基线和业务风险确定，高风险模块可以提高覆盖率与可执行率的要求，一般模块可以适当放宽。

常见问题

草稿用例数量很大，全量判定成本太高，抽样评估的结论能用到什么程度？

抽样评估的结论只代表抽样范围，不能直接外推到未抽中的用例。建议按需求模块分层抽样，覆盖不同模块和不同生成批次，避免只抽容易判断的用例，并在报告中写明抽样比例、抽样方式和复核人。如果抽样结果中不可执行或未覆盖的比例明显偏高，可以扩大抽样范围或转为全量判定，再给出最终结论。

需求点在评估期间发生变更，覆盖率分母应该怎么处理？

评估开始前锁定需求基线版本，变更发生后重新锁定基线并说明变更范围，不能把两个版本的需求混在一起统计。如果变更只影响少数需求点，可以按新基线重算覆盖率，并在报告中注明变更前后的数值；如果变更范围较大，建议对受影响模块重新评估，其余模块沿用原结论。

人工修改率在不同评审人之间差异很大，跨批次比较还有意义吗？

跨批次比较的前提是修改判定标准一致、评审人相对稳定。使用这一指标前要明确哪些改动计入实质性修改，例如影响步骤、预期结果或前置条件的改动计入，格式调整不计入，并记录修改原因分类。评审人频繁轮换时，可以固定一名复核人对修改记录做二次确认，或者把修改率与修改行数、字段数等辅助数据一起看，减少个人习惯带来的波动。

四项指标都达到约定标准，草稿是否就可以直接纳入用例库？

指标达标说明草稿在覆盖、可执行、冗余和修改量上达到了进入评审的门槛，是否纳入用例库还要看评审结论和后续执行效果。建议先让草稿进入正式评审或小范围执行，跟踪其发现的缺陷数量和后续修改频次，用实际结果校正指标口径和判定标准。高风险模块即使指标达标，也可以增加人工复核环节。

评估过程中需求、用例和评审记录分散在不同工具里，怎么减少取数比对的工作量？

取数比对的工作量主要来自需求与用例的关联关系、修改前后差异和评审记录的分散存放。ONES 的需求管理与 TestCase 可以在同一平台内关联需求与用例；ONES Assistant 智能助手连接 ONES Project、ONES Wiki 与 ONES TestCase，能够理解项目、工作项和迭代等真实工作上下文，并基于相关项目数据回答问题、执行后续操作，便于按需求追溯对应用例和评审记录。具体可用的统计口径仍需按团队配置确认。