大模型生成测试用例实战：看懂设计稿、跑通CI才是选型王道

测试用例生成这件事，过去几个月我一直在折腾。起因很简单，团队里后端接口越来越多，前端页面也改得频繁，每次迭代光补回归用例就占掉不少时间，纯手工写单测的性价比越来越低。我陆续试了好几家大模型，也看了不少号称“一键生成测试用例”的方案，最后得出的结论和标题说的一样——选型的关键不是模型参数有多大、榜单分数有多高，而是它能不能真正看懂设计稿、能不能把生成的用例直接丢进CI里跑起来。

这篇文章把我的实测过程、选型思路、踩过的坑全部摊开讲，包含具体的Prompt设计、单测运行逻辑和排查链路。如果你也在评估“AI生成测试用例”这个方向，或者已经试过但效果不理想，这篇应该能帮你省掉不少弯路。

1. 为什么测试用例生成这条赛道，门槛其实比想象中高

测试用例生成不是新概念，从早期的基于规则、基于搜索的自动生成，到后来的基于约束求解、基于符号执行，学术界折腾了几十年。但落到工程实践里，真正能被团队日常用起来的方案一直很少。原因不复杂，一条能进CI的测试用例，要满足的要求远比“生成一段能编译的代码”多得多。

1.1 传统自动生成与LLM生成本质的区别

传统工具（比如基于JUnit的Randoop、基于符号执行的KLEE）走的是“程序分析”路线：读源码、建约束、自动构造输入，目标是提高覆盖率，但生成的用例可读性差、断言薄弱，很多是“跑过了但什么都没验证”的空用例。LLM走的则是“语义理解”路线：它能读懂方法名、注释、参数含义，知道这个接口的业务预期是什么，然后写出带明确断言的用例。

这个差别很关键。Randoop生成的用例是“用随机数据把函数跑一遍，记录下没炸”，而LLM生成的是“给定一个用户名为空、密码为空的登录请求，断言返回400且错误码为PARAM_MISSING”。后者才真正具备回归保护价值。

1.2 为什么“看懂设计稿”直接决定了效果上限

标题里把“看懂设计稿”放在王道的位置，这一点我深有体会。测试用例的本质是“验证实现是否符合预期”，而预期从哪来？从需求、从设计稿、从接口文档中来。如果模型只看到代码本身，它最多只能做“代码覆盖式”的测试，也就是验证“这段代码按当前逻辑跑通了”，但无法验证“这代码做的是不是产品要的事”。

打个比方：一个按钮在页面上显示为红色，但设计稿要求是蓝色。只看代码的测试工具永远发现不了这个问题，因为代码里写的可能就是把按钮渲染成红色，测试跑通了，bug却真实存在。但如果大模型能同时“看到”设计稿和代码，它就能生成一条测试用例：“断言按钮默认色值为#2F54EB”。这就是多模态理解在测试用例生成里的价值——它不是锦上添花，而是从“能测”到“测对”的分水岭。

1.3 自动跑单测：生成只是开始，执行才是终点

很多大模型对话界面里生成一段测试代码很容易，但这段代码要能直接合并进项目、通过编译、通过静态检查、稳定运行，这就是另一回事了。依赖怎么处理？Mock怎么打？测试数据怎么准备？断言怎么设计才不容易误报？运行环境里有没有缺包？

我见过太多团队卡在这一步：模型生成的用例单看质量不错，但一跑就报错，要么import路径不对，要么mock的对象压根不存在，要么生成的用例里包含网络请求导致测试环境不稳定。所以我在这篇文章里花大篇幅讲的是“怎么让生成的东西真正跑起来”，这比单纯比谁的用例“看起来更智能”实际得多。

2. 大模型选型的核心标准：先别比榜单，比这几个硬指标

各家大模型动辄宣称自己在编程榜单上刷到什么分数，但到了测试用例生成这个具体场景，我觉得真正该关注的是下面四个维度。

2.1 多模态输入能力：设计稿能不能直接喂进去

这是第一道分水岭。你要让模型看懂设计稿，首先它得能接收图片输入。有些模型只支持文本，那就只能用“把设计稿描述成文字”的方式变通，但这个过程会丢失大量细节——颜色值、间距、布局层级、交互状态，文字描述很难还原完整。实测下来，支持视觉输入的模型在UI类测试用例生成上的效果，比纯文本模型高出不止一个档次。

具体到操作层面，我通常会直接截图设计稿 + 截图当前实现的前端页面，一起丢给模型，让它做逐像素对比。这个场景下，模型的视觉编码能力直接决定差异识别的准确率。有些模型能精确指出“按钮圆角设计稿是8px，实现里是12px”，有些模型则只能模糊地看出“有些不一样”。差距非常大。

2.2 代码理解与生成质量：上下文窗口里的工程能力

测试用例生成不是纯写代码，它要先读代码、理解代码、再写代码。这意味着模型需要能处理较长的上下文。一个典型的后端接口测试场景，我要把控制器代码、Service层代码、实体定义、以及一条已有的测试用例作为参考，一起放进对话里，这很容易就超过2万token。如果模型上下文不够长，或者进入长上下文后出现“注意力漂移”——开头的内容记不清、后面的内容也理解偏——那生成的用例质量会明显劣化。

我还有一个小指标：它能不能在生成用例时自动对齐项目的测试风格。比如你们项目里统一用Mockito写stub，用AssertJ写断言，模型生成的代码能不能主动使用这些库，而不是生成一套风格截然不同的JUnit裸断言。这一点非常影响“生成代码能否直接合入”，实测不同模型在这个维度上的表现差异极大。

2.3 生成代码的可运行性：能不能直接跑，而不是看起来专业

这是我选型时最重要的一个指标。我会拿同一份源代码分别让不同模型生成测试用例，然后直接放进项目的CI流水线里跑。看几件事：

• 编译通过率：多少模型生成的用例第一次就能编译通过
• 运行通过率：编译通过之外，运行时会不会因为mock不完整、依赖缺失而失败
• 断言有效性：用例跑通后，是不是真的拦截了bug（我会故意注入一个bug来检验）

“生成一段看起来像测试代码的东西”和“生成一段能在你项目里稳定运行的测试代码”，中间隔着一个真实工程的距离。有些模型代码质量不错，但生成的用例一旦涉及Spring上下文加载就各种报错；有些模型则会在不必要时也把整个Spring Boot应用拉起来，导致单测变成集成测试，速度慢得没法用。

2.4 工具链与API的稳定性：能不能接进自动化流程

最后还得看工程接入成本。虽然我平时的使用习惯是打开编辑器里的AI插件，或者在Web端对话试，但真要把它做成流水线里的一环（比如PR提交流水线自动生成/补充单测），就要考虑API的可用性、响应速度、并发限制、成本模型。有些模型对话体验很好，但API的限流策略极其严格，根本扛不住团队的并发；有些模型虽然能力稍弱，但API稳定且支持流式输出，接入成本低很多。

下面这张表是我用同一个后端项目（Spring Boot + MyBatis Plus，包含一个订单查询接口的Controller/Service/Mapper三层代码）做的一组对比实测，这里给出的是不同模型的横向能力印象，具体版本以你手上实际可用为准。

注意：以上数据来自我自己的项目实测，不是官方benchmark。不同基础模型版本更新很快，你手上拿到的版本可能表现差异很大，但这张表的核心结论值得参考——视觉理解能力和测试代码生成能力没有绝对绑定关系，必须分开测。

3. 从一句提示词到一条能跑的用例：完整实操链路

选型说再多，不如跑通一条真实链路。我以“根据设计稿生成前端组件测试用例”和“根据接口代码生成后端单测”两个最常见的场景为例，把整个流程从Prompt设计到用例落地的每一步拆开讲。

3.1 场景一：UI组件测试——让模型同时读懂设计稿和实现代码

前端组件测试里最常见的一个需求是：设计稿改版了，组件样式要跟着变，怎么保证所有引用到该组件的地方都符合新设计稿？传统做法是手动检查，或者等测试人员肉眼对比，效率低且容易漏。

我用大模型的方式是：

第一步，组织输入序列。把设计稿截图、组件当前实现的截图、组件源码、以及一条现有测试用例（作为风格参考）依次放给模型。顺序很重要，我实测下来最有效的顺序是：设计稿截图 → 实现截图 → 组件源码 → 现网用例风格示例。这样模型先建立视觉预期，再读代码理解实现，最后根据已有风格输出新用例。

第二步，在Prompt里明确约束断言维度。我会这样写：

你是资深前端测试工程师。请对比设计稿截图（第一张图）和当前实现截图（第二张图）， 并结合组件源码，生成一组Vitest测试用例。 要求： 1. 测试文件使用@vue/test-utils，断言风格与示例文件保持一致 2. 针对明显视觉差异（按设计稿为准）生成失败断言，例如断言按钮背景色为#2F54EB、圆角为8px 3. 对交互行为（点击、输入、hover）生成行为断言，确保组件逻辑符合预期 4. 不要mock组件内部未涉及外部依赖的方法，优先使用真实渲染 5. 每个用例包含Arrange、Act、Assert三段式注释

这一步的关键是“针对明显视觉差异生成失败断言”。如果只有代码没有设计稿，模型会顺着实现写断言，结果是“实现说是什么就是什么”，测试形同虚设。而有了设计稿作为金标准，模型才会写出“现有实现是错的、应该往哪个方向修”的断言——这才是回归测试真正的价值。

第三步，拿到生成代码后先做一轮“自校验”。我一般会做两件事：一是把新生成的测试代码反过来再丢给模型，问“这段测试代码里，有哪些断言与设计稿可能不一致？”，让模型自我审视；二是直接跑一遍测试，看有没有编译错误或失败用例。失败用例如果是“实现与设计稿不一致”导致，这才是真正有价值的失败。

3.2 场景二：后端单测生成——从Controller层到Service层全覆盖

后端单测比前端交互测试更直接，因为输入输出相对明确，但难点在于依赖链路的mock。一个典型的Controller方法背后可能牵扯Service、Mapper、Redis、MQ，不做好隔离，用例根本没法稳定运行。

我的Prompt设计分成两层。

第一层，生成主流程用例：

你是资深后端测试工程师。基于以下接口实现代码生成JUnit 5 + Mockito测试用例。 要求： 1. 覆盖正常流程、参数异常、业务异常三个分支 2. 使用@Mock和@InjectMocks隔离外部依赖，禁止启动完整Spring上下文 3. 使用BDDMockito的given/willReturn风格，断言使用AssertJ 4. 测试数据遵循等价类划分原则 5. 生成的用例必须能直接运行，不依赖外部环境

第二层，当用例跑出问题时，我把报错信息原样贴回去，让模型修复：

测试运行失败，报错如下： [贴报错堆栈] 请分析失败原因，修正测试用例中的mock逻辑或断言，输出完整可运行的测试类。

实测下来这个“生成→运行→回填报错→修复”循环非常有效，通常两三轮之后用例就能稳定通过。为什么能修复？因为大模型的代码修复能力普遍强于代码生成能力——给它明确的报错堆栈，相当于把问题缩小到了具体一行，它定位并修正的能力是够用的。

3.3 让用例真正跑起来：我在CI流水线里加的三个检查

生成只是起点，让用例在流水线里稳定运行才是终点。我在自己的接入方案里加了三个强制检查，“能跑”不再是模糊标准。

检查一：编译门禁。先跑mvn test-compile或tsc --noEmit，编译不过直接返回生成侧修改，不进入正式测试阶段。这一步能快速过滤掉大批低级错误。

检查二：diff覆盖门禁。用Jacoco或V8 Coverage统计增量代码覆盖率。我不要求新代码覆盖率一定到80%以上，只是设了一个底线：新增代码行覆盖率不低于项目同期平均水平，否则标记为“用例生成不足”，需要触发补充生成。经常出现的情况是：模型对Controller层覆盖得很全，但Service层的分支逻辑覆盖不足，需要用这个门禁来倒逼补充。

检查三：稳定性检查。对生成的测试类重复跑3次，任何一次失败都会被标记。这个检查主要针对“测试用例本身不稳定”的问题，常见原因包括：用例中依赖系统当前时间、依赖随机数、运行顺序影响。生成用例往往会写出类似LocalDate.now()的调用，这在CI的多天执行中会引发偶发失败，稳定性检查能让你及时发现。

另外，我强烈建议把“生成用例最终是否通过”这个结果作为Prompt的一部分反馈给模型。比如在PR描述里给模型看：“你上次生成的订单查询测试用例，3次运行有1次失败，失败原因是Mock的当前时间与断言日期不匹配，请修正。”模型能基于这个反馈产出更稳健的版本。

4. 大模型生成测试用例的典型失败模式与排查链路

这部分是全文最有价值的地方。我把过去两个月里模型生成用例最常翻车的情况逐一列出，并附上我完整的排查思路。

4.1 失败模式一：Mock层级错乱，导致用例互相污染

这是最常见的问题。模型生成的用例里，多个@Test方法共用同一个@Mock对象，但不同用例对同一个mock方法设置了不同的when行为。当测试框架复用同一个mock实例时，后设置的stub可能覆盖前面的，导致前一个用例执行到一半时行为突变。

排查方式：当出现“单跑一个用例通过、但整个测试类一起跑失败”的情况时，优先怀疑共享mock的stub污染。我一般会把失败用例单独执行一遍来复现，如果单独跑通过，直接把测试类的@BeforeEach里对mock的初始化逻辑贴给模型，要求模型为每个用例显式声明自己的stub行为，或者将用例拆分成多个测试类。

4.2 失败模式二：生成用例试图启动Spring上下文，导致运行时间爆炸

模型默认“写完整”的倾向很强，拿到一个Controller类，它可能为构造MVC环境把整个@SpringBootTest拉起来。这在单测环节完全是灾难：启动一次上下文要几十秒，几十个用例叠加起来，CI时间直接膨胀到没法看。

排查方式：看测试类上的注解。如果是@SpringBootTest且没有@ActiveProfiles("test")，基本可以断定这个用例会拖慢流水线。我处理这类问题的方式是：在Prompt里显式加上“禁止使用@SpringBootTest，仅使用Mockito单元测试”，如果模型仍然生成集成测试风格的代码，我会在后续对话里将“该用例运行耗时46秒”作为负数反馈给模型，让它重写。

4.3 失败模式三：断言写成“实现复读机”，测试形同虚设

判断测试用例质量有一个简单的经验法则——如果你把被测试代码里的实现细节原封不动地抄进断言，那这条测试没有任何价值。比如方法里写死return 100，测试断言assertEquals(100, result)，那这个测试保护不了任何回归。大模型很容易犯这个毛病，它会基于代码本身推断“这下应该返回什么”，然后顺着实现写断言。

排查方式：做变异测试或注入bug测试。我在评估时会手动改掉被测试代码中的一个关键逻辑（比如把if (a > 0)改成if (a >= 0)），然后跑一遍生成的测试套件，看能否捕获这个变化。如果测试用例“全绿”，说明断言敏感度不够。对这个问题，我会在Prompt里做一次“反事实引导”：

请检查已生成的测试用例中，是否存在“断言值直接从实现代码推断”的情况。 如果存在，请修改为基于业务规则和接口文档的断言。 例如：接口文档规定金额字段最多两位小数，即使实现里写了四舍五入， 断言也应直接校验两位小数格式，而不是校验“是否能被100整除”这类实现细节。

4.4 失败模式四：设计稿视觉信息被模型“脑补”，导致断言方向错误

多模态模型在“看图”时存在一定程度的幻觉问题。给它一张设计稿，它可能把按钮颜色看错、把间距看错，然后写出一条“断言按钮颜色为#FFFFFF”的用例，而真实设计稿是#F5F5F5。这种情况下用例跑得通，但验证的是错误预期，比没有用例更危险。

排查方式：人工抽检生成结果，并把“设计稿关键属性清单”作为Prompt的一部分喂给模型，而不是只给一张图。实操中我会先让模型基于设计稿输出一份结构化清单：

请基于设计稿截图，以表格形式输出以下属性： 按钮背景色、圆角、字号、间距、hover状态色值， 以及各元素之间的布局关系。

然后用这份文字化清单替代纯图片输入，再和实现对比。这样即使模型视觉编码有偏差，文字结构化的中间产物也方便我做二次确认。实测这个做法能显著降低“脑补”类错误。

4.5 一句咒语式的经验：把“失败”本身当成反馈，而不是当成问题

我一直把测试用例生成当成一个多轮对话任务，而不是一次性生成任务。第一轮生成的用例大概率有各种问题，别急着否定这个方向，把CI的报错、覆盖率的缺口、测试运行时间数据都结构化地反馈给模型，往往第二轮、第三轮就能得到一个相当可用的版本。模型基于反馈修复的能力，普遍比一次生成的能力更值得信赖。

5. 我的选型结论与落地建议

测了这么多模型之后，我的选型结论可以浓缩成三句话：视觉理解能力是硬门槛，代码可运行性是生命线，反馈闭环是护城河。

5.1 按场景对号入座的选择建议

如果你团队的痛点主要在前端UI回归，设计稿变更频繁，那选型优先级应该是：多模态理解能力强的模型优先，然后单独拿同一套视觉任务横向对比各家的准确度。这类模型对颜色、间距、布局关系的解析能力，直接决定生成用例的有效度。如果你的痛点在后端单测补齐，比如老项目接手的代码没有测试保护，那么“代码生成可运行性”比多模态更重要，甚至可以容忍不支持图片输入，但生成代码的编译通过率必须高。

从工程成本角度，我建议你先小范围试点一个模块、一条流水线，用两周时间统计三个数据：生成用例的编译通过率、真实缺陷拦截率（结合变异测试）、CI耗时变化。用数据说话，再决定是否全团队推广。不要一上来就买最高档的API套餐。

5.2 团队落地时的配套动作

光选对了模型还不够，我在自己团队里做了三件配套的事，效果非常好：

第一，沉淀“测试用例生成提示词库”。把不同场景（UI组件、Controller单测、Service单测、异常分支测试）的Prompt模板固化下来，放到Wiki里。后续无论是谁接入模型，都先从这个模板库开始，避免每次从零摸索。

第二，建立“模型输出抽查机制”。生成用例的PR默认要有测试负责人抽查代码质量，重点看断言是否有效、是否mock了不该mock的对象、是否覆盖了核心分支。抽查不是每单都查，而是按比例，比如30%的PR抽查。

第三，把测试用例生成接入缺陷管理闭环。线上出现bug时，再把该bug对应的测试用例作为一个case丢给模型，要求它“生成回归用例以保护该缺陷”，这样积累下来的用例库会越来越厚，回归保护网也会越来越密。

5.3 给不同基础读者的上手路径

如果你是第一次尝试这个方向，我的建议是别一上来就接通所有流水线。给自己定一个三步走：

第一步，先用编辑器里的大模型插件（比如GitHub Copilot或国内厂家的CodeBuddy、豆包等）在单个文件上试水，把“生成→跑通→反馈修复”这个循环跑顺。重点体验的是生成质量，不需要考虑工程架构。

第二步，把工作流固定到命令行或CI脚本里。选一家API能力稳定、成本可控的模型，把Prompt模板化，搭建一个自动生成+自动运行的脚本框架。

第三步，再考虑引入多模态设计稿理解。这时你需要把设计稿管理工具、前端组件代码、测试运行环境打通，让模型可以一键获取设计稿和代码的对应关系。

我自己就是从第三步开始做的，因为团队前端业务重、设计稿形态标准。但如果你团队是后端为主，直接从第二步起步反而更高效。

6. 最后聊几句关于“会不会取代测试工程师”的题外话

这段时间用下来，我的感受是：大模型更像是一个“能24小时加班且不抱怨的测试实习生”——它能在十分钟内生成几百条基础用例，能快速覆盖常见分支和边界值，能不知疲倦地补齐无聊的重复劳动。但它的产出需要review、需要判断、需要结合业务预期修正断言方向，这些恰恰是资深测试工程师的经验所在。

举一个很具体的例子：有一次模型给一个“删除用户”的接口生成了非常完整的用例，覆盖了正常删除、重复删除报错、用户不存在报错，断言看着都对。但团队里一位业务熟手看了一遍，提了一个问题——“删除不该有物理删除，应该有软删除标记”。模型生成的用例验证的是“记录从库里消失”，正确的用例应该验证“记录exists字段变成false”。这个判断来自对产品规则的深度理解，是模型从代码里读不出来的。

所以我的结论是：工具会放大人的能力，而不是替代人。能把设计稿、需求文档、代码链路喂给大模型，并用工程手段验证它产出质量的团队，在这一轮效率竞赛里会明显占优。而那些把“生成一段用例”当作终点的人，大概率还会在改不完的回归bug里继续挣扎。

最后再分享一个小技巧：如果你也在对比各家模型，别只开一个对话窗口分别问，用同一个测试文件、同一份设计稿，在完全相同的Prompt下做A/B测试，把输出的用例丢进同一个项目里跑。相信我，跑过一轮之后，你的选型判断会比看任何榜单都有底气。