从5000条用例到500条，回归时间从6小时降到40分钟，我们到底怎么做到的？
大家好，我是某互联网公司质量效能团队的测试架构师，负责测试资产治理和效能优化。
今天想分享一个让测试经理追着我跑的项目——用AI给测试用例库“瘦身” 。
先上结果：5000条回归用例，AI识别并建议删除/合并了4500条，去重率90% 。全量回归执行时间从6个多小时压缩到40分钟，线上漏测率反而下降了18% 。
测试经理看到数据后第一句话是：“源码给我看看。”
一、用例库是怎么“胖”起来的？
先说说我们的用例库是怎么从“精干”变成“臃肿”的。
我们的回归用例库跑了五年多，积累到5000条。每次全量回归，要跑六个多小时。
没有人敢删用例。每个人都怕删掉的那一条，恰好是某次事故复盘后加进去的“保命用例”。结果就是只增不减——新功能上线加用例，没有人会同步审查旧用例是否还有存在的必要。
直到一次容量评估，我们才认真算了一笔账：跑一次全量回归的机器成本和人力成本，已经高到影响了发布节奏。
但“找冗余”这件事，人工做几乎不可行。5000条用例，两两比较判断是否覆盖同一逻辑，组合数是天文数字。测试团队哪怕全员上阵，一个月也看不完。
这正是适合交给AI处理的场景：规则可以显式化，工作量巨大但单步判断不复杂。
二、先定义清楚：什么样的用例算“冗余”？
动手之前，必须先把“冗余”定义清楚——这是整个项目最容易出错的一步，定义错了，AI再精准也是错的方向。
我们最终确定了三类冗余，而不是笼统的“重复”：
第一类：完全重复型
两条用例的输入、操作步骤、预期结果完全一致，只是用例标题或编号不同。
这种最容易识别。成因也很简单——不同人不知道已有用例，重复创建。我们这次发现的完全重复用例有380条，占总量的7.6%，主要集中在团队人员流动较多的几个模块。
第二类：等价覆盖型（占比最高、最难识别）
两条用例验证的是同一个等价类。比如“输入合法手机号13800138000”和“输入合法手机号13900139000”，验证的是同一条业务规则——合法手机号格式校验。
这是占比最高的一类，也是人工最难批量识别的一类——因为用例的标题、编写人、创建时间都不一样，字面上看完全是两条独立的用例，只有深入理解它验证的业务规则，才能判断它们本质上在测同一件事。
我们最终发现的等价覆盖型冗余用例占了总量的60%以上。
第三类：被包含型
A用例的验证路径完全覆盖B用例的验证路径，且多验证了额外的步骤。
比如“用户登录”和“用户登录后修改密码”——后者的执行路径包含了前者的全部步骤和断言。这种情况下，前者可以被后者替代。
明确不算冗余的情况：同一等价类但覆盖不同环境（不同浏览器、不同设备）、同一逻辑但验证不同的异常分支、看起来相似但实际命中不同代码路径的用例。我们专门写了一 份“保留清单”规则，在AI分析阶段就主动排除这些场景，防止误判为冗余。
三类冗余定义清楚之后，AI要做什么也就明确了——找出这三种类型的冗余，而不是简单地去重。
三、技术方案：四步走
第一步：结构化提取——让AI“读懂”用例
5000条用例原始格式是Excel和Markdown混杂，字段不统一。
第一步是把每条用例标准化提取成统一字段：
{
"id": "TC-1024",
"module": "用户注册",
"preconditions": "未注册账号",
"input_params": {"手机号": "合法格式", "验证码": "正确"},
"steps": ["输入手机号", "获取验证码", "输入验证码", "提交"],
"expected": "注册成功，跳转首页",
"equivalence_class": "合法手机号+正确验证码"
}
关键字段是equivalence_class——这是AI根据用例的输入条件和业务规则，推断出的等价类标签。这一步本质上是让AI读懂每条用例在测试什么“业务规则”，而不只是字面上的“操作了什么”。
第二步：向量化 + 聚类——把用例“投影”到语义空间
结构化之后，我们做了两件事：
向量化：用Embedding模型（我们用的是nomic-embed-text-v2-moe和structbert的组合方案）把每条用例转换成语义向量。相似语义的用例在向量空间里距离更近。
聚类：用聚类算法（K-means + 层次聚类）把向量空间里“挨得近”的用例聚成一簇。同一簇里的用例，大概率测试的是同一个业务场景。
这一步解决了“等价覆盖型”冗余的识别问题——不管用例标题怎么起、步骤怎么写，只要语义向量接近，就会被聚到一起。
效果：5000条用例被聚成了430个簇。平均每个簇11.6条用例——意味着大量用例在测同一件事。
第三步：AI智能分析——从“相似”到“冗余”
聚类只是告诉你“这些用例很像”，但“像”不等于“冗余”。还需要AI做更精细的判断。
我们给大模型喂了每个簇里的所有用例，让它按照三类冗余的定义逐一分析：
完全重复：直接标记删除
等价覆盖：推荐保留哪一条（保留最全面、最清晰的）
被包含：推荐删除被包含的那一条
同时，AI还会做跨簇分析——有些用例虽然不在同一个簇里，但存在“被包含”关系。比如“登录”用例在一个簇，“登录后修改密码”在另一个簇，但后者包含了前者。
我们用的是内部部署的Qwen模型，配合Few-shot示例教会它“什么算冗余、什么不算”。经过三轮迭代，AI的判断准确率从最初的72%提升到了91% 。
第四步：人工裁决——AI提建议，人做决定
AI的输出结果，不是一个“删除列表”，而是一个“待决策候选集”——机器提出疑问，人来做最终裁决。
我们建了一个简单的审核面板：
簇ID
用例数
AI判定
推荐保留
风险等级
C-023
18条
等价覆盖
TC-1024
低
C-089
12条
等价覆盖
TC-3401
中
C-156
8条
完全重复
TC-5602
低
...
...
...
...
...
测试经理花了一天时间审核，确认了AI的95%建议——只有不到5%需要调整（主要是业务敏感模块，AI不了解最新业务背景）。
最终结果：5000条 → 500条。去重率90%。
四、踩过的坑（说三个最痛的）
坑一：相似度阈值设错了
刚开始我们把阈值设在了0.95——两条用例的语义相似度超过95%才算冗余。
结果只找出了完全重复的那380条，等价覆盖型的基本没发现。
后来把阈值逐步降到0.85，等价覆盖型的召回率才上来。但降到0.8以下又开始误报——把“边界测试”和“正常流程测试”也判成了重复。
教训：相似度阈值的设定，不是一个技术问题，而是一个业务决策。每个团队的用例风格不同，阈值要自己调。我们最终稳定在0.87。
坑二：上下文信息缺失导致误判
同样 是“用户无法登录”的测试场景，在安全模块和在兼容性模块，其测试意图截然不同，但向量距离可能很 近。
AI把安全模块的“登录失败-账户锁定测试”和兼容性模块的“登录失败-不同浏览器测试”判成了重复——但这两条用例的价值完全不同。
解法：在向量化时加入了模块标签作为额外特征。同一个模块内的相似才算冗余，跨模块的不算。这个改动让误报率从23%降到了8% 。
坑三：AI的“幻觉”问题
AI有时候会“脑补”一些不存在的覆盖关系。比如两条用例明明测的是不同场景，AI愣是说“A覆盖了B”。
解法：引入交叉验证——不光靠大模型分析文本，同时用代码调用图做二次验证。如果两条用例在代码层面调用了不同的函数路径，即使文本相似也不判冗余。
五、效果数据
说几个硬数据：
指标
优化前
优化后
用例总数
5000条
500条
全量回归耗时
6+小时
40分钟
去重率
-
90%
AI判断准确率
-
91%
人工审核工作量
不可行
1人天
线上漏测率
基线
↓18%
最意外的是：这次梳理顺带发现了40多条“僵尸用例” ——验证的功能在历史版本里已经下线了，但用例还留在库里。这些用例跑了几年，从来没人质疑过它们存在的意义。
六、给同行的一些建议
- 先定义“冗余”，再动AI
定义错了，AI再精准也是错的方向。花一周时间跟团队达成共识——“什么样的用例算冗余”——比直接写代码重要得多。
- 从小范围开始
别一上来就全量跑。先选一个模块（比如“用户登录”），完整跑通“AI识别→人工决策→执行验证”的闭环。积累信任和经验之后再扩展。我们第一个月只跑了“用户注册”这一个模块。
- 相似度阈值要自己调
不要照搬别人的阈值。每个团队的用例风格、粒度、命名习惯都不一样。我们从0.95一路试到0.87，花了三周才找到最佳值。
- AI提建议，人做决定
AI的输出不应该是“删除列表”，而应该是“待决策候选集”。机器提出疑问，人来做最终裁决。把边界划清楚，是避免AI误操作的核心前提。
- 别忘了“僵尸用例”
AI去重主要解决“冗余”，但“僵尸用例”（验证已下线功能的用例）是另一类问题。建议在AI分析之前，先用代码覆盖率工具扫一遍——那些覆盖率长期为零的用例，基本可以标记为“待确认”。
最后
AI做测试用例去重，本质上是把“人工判断冗余”这件不可能完成的任务变成了可能。
5000条用例两两比较，人工永远做不完。但AI可以在几小时内完成语义分析、聚类、智能判断——然后让人来做最后的裁决。
测试经理后来跟我说了一句话让我印象很深：“以前不敢删用例，是因为不知道删了会怎样。现在AI告诉我删了没问题，我就敢了。 ”
信任不是凭空来的——是靠91%的准确率、95%的建议被采纳、以及上线后漏测率反而下降换来的。
如果你团队的用例库也在“只增不减”地膨胀，我建议你试试这个方向。技术门槛真不高——一个Embedding模型 + 一个聚类算法 + 一个大模型，就能搭起来。
关键是：你愿不愿意让AI动你的用例库？
本文部分内容参考了霍格沃兹测试开发学社整理的相关技术资料，主要涉及软件测试、自动化测试、测试开发及 AI 测试等内容，侧重测试实践、工具应用与工程经验整理。
