AI生成测试用例重复率高？从提示词约束到语义相似度的去重实践

如果你也用AI批量生成测试用例，多半会遇到一个很尴尬的问题：AI确实能在几分钟内给你吐出一大批用例，但里面总觉得“差不太多”。核心功能A的用例生成了三份，只是换了几种说法；同一个校验逻辑既能叫“用户名为空提示”，又能叫“未输入用户名时做校验”，甚至还有一条“用户名留空时给出错误提示”。你辛辛苦苦去重比写用例还累，最后反而怀疑用AI是不是划算。

我在实际项目里也踩过这个坑，后来花了很大精力专门梳理“AI生成测试用例的重复问题”。这里想做一个系统性的总结：为什么AI老生成重复用例、重复会造成哪些隐性成本、以及从生成前到生成后如何建立一套可落地的去重流水线。内容会更偏向功能测试用例和测试平台侧的去重实践，适合QA、测试开发、AI应用开发者参考，尤其是正在搭AI生成用例工具、又不想被重复数据淹没的团队。下面直接进正题。

1. AI生成的测试用例为什么总在“同一条路上反复横跳”

想解决去重，不能只盯结果，得先理解模型是怎么把用例“编”出来的。只要你不了解重复的来源，哪怕加再多的相似度算法，也只是在补救，永远跟不上模型制造重复的速度。

1.1 大模型生成机制本身就是重复的来源

大语言模型本质是一个“根据上文预测下一个词”的概率系统。当你给它一句“生成登录功能测试用例”，它每次输出都是一次独立采样。采样过程中，模型不知道自己刚才在上一条里已经把“空密码校验”写过了，它只知道“现在要输出一条看起来合理的用例”。于是同一条规则换个措辞再生成一次，对它来说没有任何负担。

我之前做登录模块批量生成实验，让模型生成20条登录页面用例，结果出现了三组高度近似的组合：“密码为空时提示请输入密码”“密码栏未填写时校验拦截”“空密码提交显示请输入登录密码”。这三条从功能设计文档角度看，基本就是同一个校验点。但在模型眼里，它们是三次不同的概率采样，自然就当作不同内容输出。

这还只是最表层的重复。更深一层是模型的“归纳能力”会用错地方。比如你要求“覆盖所有异常场景”，模型会下意识把一个边界条件拆成很多语言变体，它认为“空”“为空”“未填写”“留空”都值得单独写一条，其实在产品规则里这些都是同一个等价类。模型并不真正理解等价类边界和测试设计方法，它只是把常见的测试表述凑在一起，凑得越多看起来越专业，重复也就越严重。

1.2 重复用例到底会造成什么实际损失

很多人觉得用例重复顶多“不好看”，删掉就行。等用例量一上来，你就会发现重复的成本远不止阅读体验差。

第一是执行和评审成本。测试用例评审时，同一规则出现三条近似用例，评审会要来回确认是否真的重复、保留哪条、合并哪些步骤。一个模块还好，如果整个系统都这么搞，评审效率直接减半。第二是自动化脚本维护的隐形负担。进入自动化阶段后，重复用例意味着两份脚本做同一件事，业务规则一旦调整，你得同时改两处甚至三处，少改一处就会出现“有的脚本执行通过、有的执行失败”的假异常，排查半天才发现原来是同一规则的重复用例。第三是覆盖率统计失真。你本来覆盖率已经达标，但因为同一场景被拆成多条冗余用例，分母虚高，真正的业务场景覆盖反而看不清。我见过一个团队，AI生成了上千条用例，覆盖率数字很好看，但核心异常流程缺失，就是因为生成的内容大量集中在同一个规则上反复打转。

所以去重这事不只是“清理数据”，它直接关系到测试资产能不能被信任。

1.3 先明确一个边界：什么才算“重复”

做去重前必须先定义“重复”，否则后面的一切算法都没有基准。我的经验里，与其看文案，不如看四个维度：被测对象、前置条件、操作动作、核心预期。如果四条都一致，只是措辞不同，判定为重复。比如“点击登录按钮后不输入密码，系统提示密码不能为空”和“密码框留空，点击登录，页面出现密码必填校验”，被测对象都是登录按钮，前置条件都是密码为空，操作动作都是点击登录，核心预期都是拦截，这就算重复。

但有一条要特别注意：同一条边界规则下的不同参数值不能算重复。比如登录密码长度限制，密码为空、密码为1位、密码为17位，这三条预期的提示可能一样，但不能简单判重，因为它们是边界值的不同档位，对应不同测试数据。这类用例更适合合并成一条数据驱动用例，把参数放到测试数据集里，而不是生成三条“长得像”的独立用例。去重算法如果没想清楚这一点，很容易把边界值全部杀掉。

2. 去重不能靠单一算法，要从生成前到生成后分三层设防

最开始我以为这类问题只要写个脚本做相似度计算就能解决，后来发现不对。如果生成源头不做约束，AI每分钟生成几十条，后置去重再强也只是“事后补救”，而且误判率会很高。真正靠谱的方案，是把去重前移到生成环节，形成生成前、生成中、生成后三层防线。

2.1 生成前约束：把“已有用例清单”和“测试点清单”喂给模型

生成前约束的核心原则就是一句话：别让模型在信息真空里写用例。你如果只给它一个“请为订单模块生成用例”的指令，它就只能靠训练记忆里的通用套路自由发挥，当然容易把行业常见写法都堆一遍。

我在实践中会先在提示词阶段要求模型输出一份“测试点清单”。具体做法是让它按“功能模块-业务规则-校验点”的层级先列出所有测试点，不直接给完整用例。然后告诉它，这份清单必须覆盖需求文档里明确的正常流程和异常拦截，数量不要超过30个。模型先把测试点列出来后，再人工或者用规则脚本过一次，把明显同一规则的测试点合并，最后才让模型基于这份“已经过一轮筛选的测试点清单”逐条展开成完整用例。

同样重要的一件事是把已有用例的标题或摘要传给模型。AI不是人类，你不会在写新用例时翻一下历史用例库，模型更不会。如果我们期望它不要覆盖已有内容，就得主动把“不要重复”的信息喂到上下文里。实际操作时，我会把当前功能模块下历史用例的规范化标题拼成一段，放进提示词，并加一句“以下为已存在的用例，请勿生成与这些用例核心步骤和预期一致的用例”。这个方法简单直接，但因为上下文长度有限，更适合在单模块内做，而不是把整个用例库一股脑塞进去。

2.2 生成中约束：半结构化输出和按模块分桶

生成前约束只能减少一部分重复，因为模型太容易在长文本生成过程中“忘记”自己的输出。这时候需要把输出格式从自然语言改成严格的半结构字段。

我们内部用的生成格式大致是：

• 模块：订单创建
• 标题：订单金额超过单笔限额时拦截
• 前置条件：已登录用户，账户余额充足
• 操作步骤：
  1. 进入订单创建页面
  2. 输入超过单笔限额的金额
  3. 点击提交
• 预期结果：系统提示金额超出限额，订单不提交

这个格式看着简单，但力量在于强约束。如果让模型自由写步骤，它会把“输入订单金额”和“提交订单”混成一段话，将来做去重就没法拆。而结构化输出后，步骤是一个清晰的列表，我们后续可以抽取“操作链”用于判重比对。字段一旦固定，模型就没机会把两个不同测试点塞到一条用例的长文本里，文本之间的相似度分布也会更好处理。

另一个实用技巧是按模块分桶生成。让一个大Prompt生成100条用例，肯定会互相重复。我把生成任务切得非常碎：一次只生成一个接口或一个规则集合的用例，例如“请只针对登录页面的用户名输入规则生成用例，不要涉及密码规则”。这样每批用例内部聚焦，批与批之间的边界也清晰，去重范围从全库缩小到模块内，效果会好很多。

2.3 生成后拦截：精确指纹优先，语义相似度兜底

不管生成前和生成中怎么设防，始终会有漏网之鱼。所以生成后必须做一次系统级的拦截，一般走两条路：精确指纹去重和语义相似度去重。

精确指纹去重听起来技术味很重，其实原理很简单：先把用例文本做规范化处理，比如去空格、统一大小写、把同义词换成标准说法，然后对这段文本计算一个MD5指纹。如果库里已经存在相同指纹，说明这条用例跟已有用例在文本层面完全一致，直接拦截。

但文本层面完全一致的重复毕竟是少数，更常见的是“换个说法”的重复。这时就需要语义相似度计算。思路是对用例文本做向量化，然后计算新用例和历史用例之间的余弦相似度，超过一定阈值就标为疑似重复。这块放到下面一节详细展开，因为参数阈值和工程落地才是真正容易出问题的地方。

3. 从指纹判重到语义判重：一套可以直接落地的实现方案

理论聊再多，不如给出能直接跑的步骤。这一节我会按实际操作顺序来，从文本清洗开始，到指纹计算，再到相似度阈值选择，尽量把实现细节说清楚。

3.1 先把用例文本洗干净再做判断

去重算法处理的是文本，但测试用例不像普通文档，它里面有大量“噪声”会让算法误判。最常见的问题是中文符号差异，比如“密码为空：系统提示”和“密码为空,系统提示”一个是中文冒号，一个是英文逗号，计算机看来是不同字符串，人类看其实完全一样。所以任何去重实现的第一步都是清洗。

清洗至少要处理这几类问题：

• 统一全角半角标点，把中文标点转成英文或统一去掉；
• 去掉文本首尾空格和多余空白符；
• 英文一律转小写；
• 把操作词收拢成标准表达，比如“填写”“键入”“输入”“录入”都归一到“输入”，“提交”和“点击提交”按场景映射为“点击提交”；
• 去掉用例标题里的编号前缀，比如“TC_001”“1.”这类无意义噪声。

清洗规则做得越细，后面的精确指纹才越有价值。如果你跳过这一步直接做MD5，一条用例换个冒号就能绕过判重，那整个精确指纹层形同虚设。

3.2 结构化指纹去重的代码思路

清洗完之后，就可以计算精确指纹了。我给出一个最基础的代码思路，实际使用时你可以把业务里常用的词和格式规范加进去。

import hashlib import re def clean_text(text: str) -> str: # 去掉首尾空格和常见符号 text = text.strip() # 统一全角逗号、冒号为半角 text = text.replace("，", ",").replace("：", ":") # 去除标点符号和多余空格 text = re.sub(r"[\s]+", "", text) text = re.sub(r"[，。！、；,.!;:：()（）\[\]]", "", text) # 英文转小写 text = text.lower() # 同义词归一化 text = text.replace("填写", "输入").replace("键入", "输入") text = text.replace("点击", "单击").replace("校验", "验证") return text def build_fingerprint(case: dict) -> str: raw = f"{case['module']}|{case['title']}|{'->'.join(case['steps'])}|{case['expected']}" cleaned = clean_text(raw) return hashlib.md5(cleaned.encode("utf-8")).hexdigest()

这个函数会把一条用例的模块、标题、步骤、预期结果拼成一个字符串，清洗后计算MD5。如果两条用例的指纹一样，说明它们在这些核心维度上完全一致。实际部署时，我会把指纹字段存在用例表里并加唯一索引，新增用例前先查指纹是否存在，存在就直接拒绝。这个方案成本极低，适合做第一层硬拦截。

有一点要注意，步骤列表的拼接顺序不能随便调整。很多相似度算法喜欢把词袋化处理，排序后比较，但测试用例的步骤顺序是业务逻辑，不能乱动。比如“先登录再下单”和“先下单再登录”在很多业务里是两个完全不同的场景，一旦排序就会误判。所以指纹拼接必须保留原始顺序。

3.3 语义相似度去重的阈值怎么定才靠谱

精确指纹只能拦一模一样的情况，真正的拦路虎是“换一种说法”的重复，这时需要向量相似度。

常见路线有两种：一种是用TF-IDF或SimHash做文本向量，另一种是用BERT系列的中文Embedding模型做语义向量。前者实现简单、速度快，但只能捕捉词面重合，对同义词改写基本无效。后者能识别“请输入密码”和“密码不能为空”这类语义相近的文本，但会引入模型依赖和一定的计算成本。我的建议是先用Embedding模型生成向量，再算余弦相似度。现在中文Embedding生态已经很成熟，单条用例过模型也就几十毫秒，几千条用例全量比对完全可以接受。

向量化之后，最重要的问题是阈值取多少。这个阈值没有标准答案，不同业务文本风格差异极大。我能提供的是标定方法：

先人工从历史数据里挑200到300对用例，标注它们是否重复，要求至少覆盖明显重复、语义相近但不算重复、完全不重复三种情况。然后对这些成对文本计算相似度，画出分布图。一般来说你会看到两个峰，一个集中在0.9以上，基本都是改写重复；另一个集中在0.65到0.85，可能是语义相近但边界不同。阈值选在两个峰之间的低谷处，通常会在0.86到0.92之间。

我实际项目里会把疑似重复分成两档：相似度高于0.92的，自动进入“待确认重复列表”；相似度在0.8到0.92之间的，提示“人工复核”，不自动删除。这样做的原因是高阈值区间误杀率很低，但低阈值区间如果自动处理，很容易把边界值误杀，损失大于收益。宁可让一部分重复进入人工队列，也比让算法把有效用例删掉强。

4. 落地过程中最常见的坑与排查思路

算法本身不复杂，真正的坑往往出现在你以为“逻辑没问题”的时候。下面这些案例都是我实际踩过的，每个都对应一类真实场景。

4.1 把“参数不同”误判成重复：去重粒度搞错了

有一次我们去重脚本上线后，自动拦截了一批用例，当时看上去没问题，结果后续人工复核时发现误杀率很高。印象最深的是一条“密码长度为16位时提交成功”和“密码长度为17位时提示超出最大长度”被标成了疑似重复。

从文本角度看，两条用例的步骤几乎一样：打开登录页，输入密码，点击登录，然后断言页面提示。Embedding模型给它们的相似度高达0.9，因为除了一两个数字不同之外，整体结构完全一样。但作为测试设计，它们覆盖的是同一个限制条件的两侧边界，是需要保留的。

后来我们调整了策略：不能只看步骤和标题的相似度，还要把“参数值”单独抽出来作为特征加入判断。如果两条用例步骤相同，但参数值是紧邻的边界值，就不进入去重候选。更通用的做法是让模型在生成时把“测试数据”和“测试步骤”分离，数据像参数化表格一样单独存放，判重只针对“步骤模板”。这样既保住了数据驱动用例的完整性，又不会让它们因为长得像而被误删。

4.2 步骤顺序不能排序，别让算法教坏业务

另一个坑发生在相似度计算的预处理阶段。试用SimHash时，有同事觉得“文本分词后先排序再哈希”能提高召回率，因为他看到很多重复用例的步骤顺序并不完全一样。这个想法初看合理，但放到业务里就出问题了。“下单后支付”和“支付后下单”是两个流程，不是同一场景的顺序变体。

测试用例的步骤是一个有向动作链，不能当成普通文本的词袋处理。排序去重适合那些“提示文案相同”的场景，比如各种输入框的空值校验，步骤顺序确实不影响“提示不能为空”这一结论。但一旦涉及业务流程，必须保留步骤原始顺序，否则算法会给业务开倒车。我们的做法是，只有同模块且操作动作属于“校验类”时，才允许做顺序无关的相似度比较，其他类型一律保留顺序参与计算。

4.3 向量相似度高不代表一定重复，别让算法直接删用例

这是我见过最危险的自动化思路：相似度超过阈值就直接把新用例删掉。曾有一个AI生成测试用例平台，内部为了控制用例库膨胀，把自动去重阈值设到0.85，每周能拦截几百条“重复用例”。团队一开始很满意，直到一次发版前评审发现，所有关于“订单并发时库存扣减”的用例都被拦截了，因为它们的措辞和“订单重复提交”用例高度相似，但实际验证的是两个完全不同的并发逻辑。

数据不会直接说明业务意图，向量相似度只是从文本层面告诉你“这两句话长得像”，但两条长得像的用例可能因为前置条件不同、验证点不同而对应完全不同的业务风险。所以我把去重系统设计成两级：自动拒绝的只有精确指纹命中的结果；语义相似度标出的疑似重复，一律进入人工确认池，再配合二次评审决定保留还是合并。准确率再高的模型也不能替测试人员做业务决策，它只能帮测试人员缩小审查范围。

4.4 常见问题排查速查表

5. 把去重变成持续迭代的反馈闭环

去重工具上线后，很多人以为这事就结束了，其实没有。AI生成用例的重复模式会随着提示词、模型版本、需求文档风格变化而变化。一套固定算法跑半年，准度很快会下降，必须把它设计成一个能持续从人工评审结果中学习的反馈闭环。

5.1 存量清洗与增量拦截要分开做

我建议把去重拆成两条线。一条是存量清洗，专门处理已经堆在库里的大量历史冗余数据。存量清洗的动作不要一次性做完，先用高阈值挑出“高度疑似重复”的条目，交给业务人或QA确认后合并。一次清洗的数据量控制在几百条以内，确认一批清理一批，避免误删。

另一条是增量拦截，也就是每次AI生成新用例后，走一遍提示词约束、指纹去重、语义相似度筛查的流程。增量侧的目标不是追求“零重复入库”，那样容易把有效用例误杀，而是把重复率控制在一个能接受的范围，比如从最初的20%以上压到5%以下。定一个真实的KPI，去重工作才不会变成没完没了的“救火”。

5.2 把确认后的重复样本回灌给提示词策略

反馈闭环里最重要的一步，是把人工确认过的重复样本变成下一轮生成的“禁令”。我们在系统里会维护一个“已确认重复规则库”，每条记录包含一个标准测试点描述和若干种重复写法。每次构造AI生成提示词时，把当前模块的重复规则库插入上下文，明确告诉模型“这些说法已经存在，不要再生成类似内容”。这一步本质上是在给模型喂更高质量的few-shot负例，效果比单纯在结果端拦截更明显。

实际用过一段时间后你会发现，AI生成测试用例的重复率不是靠一个算法、一次清理就能一劳永逸的，它需要从生成前到生成后持续往下压。我个人在项目里体会最深的一点是：去重的收益不能光看拦截了多少条，还要看有没有误杀有效覆盖率。宁可让少量重复用例混进人工复核池，也别让一个模型或算法替测试团队做业务判断题。这样把去重系统当成持续迭代的测试资产来运营，AI生成用例才能真正从“数量多”变成“质量高”。