AI研发管理软件生成测试用例，覆盖率上去了，重复和漏测也会上去

接入AI研发管理软件后，很多团队会看到一组矛盾结果：一个订单需求生成上百条用例，覆盖率报表很好看，上线后却因跨月退款这类场景出事；用例数量翻倍，线上缺陷没有同步下降，评审时还出现大量语义重复的用例。问题通常不在生成能力，而在生成速度超过用例治理能力。覆盖率只能说明测试触达了多少范围，不能证明重复更少、关键风险被真正验证。治理缺位时，覆盖率越高，重复和漏测越容易被数字掩盖。

一、覆盖率上升不等于漏测减少

1. 覆盖率只说明执行，不证明验证有效

先区分两类覆盖：需求覆盖率看业务规则有没有被覆盖，代码覆盖率看代码路径有没有被执行。本文重点讨论前者，但两者的共同问题是触达不等于验证。没有明确预期结果、只确认页面能打开的用例，同样能贡献覆盖率，却无法证明业务规则正确。覆盖率是过程指标，不是缺陷检出的成绩单。

2. 故障暴露比故障覆盖更接近漏测

2025年公开的TestCase-Eval基准评估了19个大模型。该基准以算法题为对象，不能直接等同于业务系统，但结果说明同一条规律：生成数量增加后，故障覆盖可以升到较高水平；而针对具体错误实现生成有效输入的故障暴露任务，最好的模型不足一半，人类专家超过九成。生成更多用例，和生成能击中关键缺陷的用例，是两种能力。

二、AI生成测试用例为什么会重复

1. 缺少用例资产基线导致重复

需求、用例和缺陷分散在不同项目、文档与表格里，AI只能基于眼前材料生成。它看不到半年前覆盖过的异常场景，也不知道另一条用例只是前置条件不同，于是同一规则被反复写成新用例。重复的根源往往不是模型偷懒，而是生成时缺少完整的测试用例资产。

2. 生成目标趋同造成语义重复

如果提示词只是要求根据需求生成测试用例，模型通常围绕正常流程、空值、格式错误和边界值展开。不同批次的结果结构和验证点高度相似，只是措辞、步骤或数据不同。这类用例文本不完全相同，测试意图却重复。只按标题或步骤查重，抓不住语义重复。

3. 用例粒度不统一放大重复

有人按操作步骤写，有人按业务场景写，有人把前置条件拆成独立用例。同一规则被拆成多条或被写成不同描述，AI生成得越多，用例库越难比较，重复率越难降。

三、AI生成测试用例的漏测盲区

1. 需求不完整直接造成漏测

AI只能基于已提供的需求、验收标准和业务规则生成；需求只写主流程，没有说明角色权限、状态转换、异常回退、并发限制和数据边界，结果就只覆盖显式内容。需求里的空白，会原样变成用例里的空白。

2. 隐性业务约束未进入生成上下文

模型擅长展开已写出的内容，却不会自动知道团队默认规则：订单不能跨月退款、状态不能重复提交、关键操作要留审计记录。这些约束未进入上下文，就不会进入用例。漏测往往不是模型不会写，而是它不知道要写。

3. 预期结果模糊削弱用例判定力

用例缺少可观察、可判定的预期结果，执行时只能凭感觉判断。系统正常、提示成功、页面刷新这类结果，无法说明响应字段、数据状态、权限变化和审计记录应该是什么。预期结果模糊，是用例数量增长后最容易被放大的质量问题。

4. 变更影响未关联导致回归漏测

需求变更、缺陷修复和配置调整都会改变测试范围。生成时若只读取当前需求，没有关联历史缺陷、变更记录和受影响模块，AI就会继续围绕旧路径生成，新增风险反而无人覆盖。没有缺陷追溯，补测只能靠记忆。

四、测试用例治理的四步闭环

治理AI生成测试用例不是再加一条更长的提示词，而是把用例当作持续维护的资产。下面四层控制先看分工，指标口径见第五章。

四层前后依赖：定基准、控输入、定去留、看效果。

1. 资产基线是去重和复用的前提

资产基线统一六类信息：用例编号、需求链接、风险等级、前置条件、预期结果、执行历史。去重不以标题为准，而以需求编号、前置条件、输入等价类和预期行为为判断键。同一判断键保留一条代表用例；仅测试数据不同时，合并为数据变体。没有统一判断键，去重就会退化成删重复文本。

图1：资产基线让需求、风险、前置条件与执行历史可关联。

2. 受约束生成比批量生成更能补缺口

生成前提供四类上下文：需求与验收标准、已有用例摘要、历史缺陷与线上问题、本次变更影响。任务不求输出数量，而要明确找出当前用例集未覆盖的风险场景并说明缺口。每条候选必须带需求编号、风险标签、明确预期结果和不可执行条件。AI负责提出候选，测试负责人决定是否入库。

图2：验证结果回流资产基线，治理链才不会停在一次生成。

3. 语义去重决定用例留什么

先统一同义词、步骤顺序和标点，再做语义相似度聚类，把测试意图相同的用例归组；最后按覆盖贡献保留能区分不同行为、风险和故障模式的用例。高相似用例不要一键删除，先确认前置条件和预期结果是否等价。去重是减少无效执行，不是追求用例库越小越好。

4. 风险补漏与验证形成闭环

用需求风险矩阵检查高风险规则有没有正向、反向、边界和异常用例；用历史逃逸缺陷反推缺口；对核心逻辑引入变异测试或故障注入，看用例能否发现人为改动。线上问题复盘后，把新增场景回写资产基线，形成下一轮生成上下文。验证闭环不建立，AI只会把旧缺口生成得更快。

图3：过程指标看治理动作，结果指标看漏测是否减少。

五、用四类指标验证治理效果

1. 过程指标看生成与治理是否健康

重复用例率、需求关联率、风险场景覆盖率和有效候选率，比生成了多少条更能说明治理质量。重复用例率看语义重复占比，需求关联率看用例是否挂到需求，风险场景覆盖率看高风险规则是否补齐正反向与异常用例，有效候选率看生成结果有多少能通过评审入库。

2. 结果指标看漏测是否真的减少

逃逸缺陷数、变异得分和缺陷定位时长，分别回答漏没漏、测得狠不狠、出了问题能否快速定位。它们不随用例数量自动变好，却能暴露覆盖率背后的真实质量。用例数量是产出，不是效果；覆盖率是范围，不是结论。

3. 三条落地边界防止治理失效

• AI不直接决定入库：生成结果先进候选区，经测试或业务负责人确认后再入库。
• 不用数量替代风险：高风险模块深覆盖，低风险模块抽样，避免平均用力。
• 不把一次提效当长期能力：持续清理失效用例、校准去重规则、复盘误判，才能让AI研发管理软件持续产生价值。

六、常见问题

1. AI生成用例后，原有手工用例还要保留吗

要保留承载业务知识、历史事故和合规要求的用例。先做需求关联和语义比对，确认新用例确实覆盖了原有验证点，再退役重复项；不要按创建时间批量清理。

2. 没有代码覆盖率数据，怎么判断漏测风险

可以从需求风险矩阵、历史逃逸缺陷、线上问题分布和探索式测试记录入手，先看高风险规则有没有正向、反向和异常验证。代码覆盖率不是唯一入口，关键风险有没有被验证，才是判断漏测的起点。

3. 重复用例率降到多少才算合理

不要追求固定阈值。先区分语义重复和有意冗余：同一判断键下只保留代表用例；为降低不稳定风险而保留的少量冗余可以接受。高风险模块优先看语义重复是否清零，再结合逃逸缺陷判断。

数据来源：TestCase-Eval基准论文，arXiv编号2506.12278，2025年；该基准以算法问题为测试对象。