关注 霍格沃兹软件测试开发 公众号回复「资料」, 领取人工智能测试开发技术合集从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-02318条等价覆盖TC-1024低C-08912条等价覆盖TC-3401中C-1568条完全重复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 测试等内容侧重测试实践、工具应用与工程经验整理。