大模型生成测试用例：看懂设计稿、自动跑单测才是王道

1. 测试用例生成这件事，难的不是“生成”

在测试技术圈子里泡久了你会发现一个很有意思的规律：凡是聊“大模型生成测试用例”，大家第一反应都是“甩一份PRD进去，让它吐出几十条用例”。真这么干过的人，大概率都经历过同一种尴尬——模型确实能写，写出来的东西也确实像模像样，可细看全是“正确的废话”。

比如你给它一个登录页的设计稿，它给你来一句“验证用户能否输入正确的用户名和密码”。这句话对吗？对。有用吗？等于没说。问题的根源在于，它压根没“看懂”你的设计稿，只是在按照对“登录页”的刻板印象在答模板题。

所以标题里那句“看懂设计稿、自动跑单测才是王道”，说到底是在讲两件真正能拉开差距的事：一是多模态大模型的视觉理解能力能不能准确解析UI设计稿；二是生成的用例能不能脱离人在环里、真正落地成自动化脚本跑起来、并且拿覆盖率说话。这两点，才是测试用例生成从“玩具阶段”进入“生产阶段”的分水岭。

这篇文章我想从选型思路开始聊，再说清楚“看懂设计稿”这个环节到底怎么落地、自动跑单测的闭环怎么搭，最后把我踩过的坑一并摊开。如果你正在评估大模型测试辅助工具，或者在团队里推AI生成测试用例，这篇文章应该能帮你省下不少试错成本。

1.1 大多数人把大模型用错了方向：先从“看懂”说起

测试用例生成的本质是什么？是把“需求信息”翻译成“验证行为”。但这里有个致命的前提：需求信息必须能被模型准确读取。

传统做法是喂PRD文本，这条路走到今天已经比较成熟——文本抽取本来就是大模型的基本功。但绝大多数团队的真实痛点恰恰在于：PRD写得不够细，真正信息量最大的地方全在设计稿里。那个按钮的交互逻辑、那个表单的校验规则、那个弹窗的触发条件，你指望开发者事无巨细地写进文档里，还不如指望模型自己会看图。

于是多模态大模型就成了必选项。需要特别提醒的是，这里说的“看图”并不是很多人理解的“OCR识别文字”。一个合格的设计稿理解，包含四个层面：

第一层是元素识别。这个区域里有输入框、按钮、下拉框、勾选框，各在什么位置。 第二层是布局结构。哪些元素属于同一个表单，哪些是卡片内部的子模块，栅格怎么划分，弹窗与底层面板的关系是什么。 第三层是交互语义。这是一个登录按钮还是一个提交按钮，点击之后是跳转还是校验，错误提示出现的位置和文案条件。 第四层是业务意图。整个页面解决什么问题，主流程是什么，边界场景有哪些——这一层单看图是推不出来的，需要结合PRD或者上下文提示词补充。

绝大多数人试模型的时候，前两层可能看得不错，但第三层和第四层稀碎。为什么？因为第三层需要模型具备一定的前端常识和交互设计经验，第四层需要上下文理解，而很多团队在使用时压根没给模型足够的上下文，只甩一张图就指望它输出高质量用例，这就有点强人所难了。

1.2 为什么自动执行单测会成为分水岭

讲讲“生成用例”之后的环节。用例文本写得再漂亮，不落地执行，价值就砍掉一大半。你花半小时调提示词生成了一百条用例，然后呢？一条条复制到禅道里？还是誊到Excel里排期？如果是这样，大模型只是换了个方式的打字机，并没有真正提效。

真正能在团队里站住脚的方案，必须具备这样一条链路：用例生成之后，同步产出可执行的单元测试代码，触发一次测试运行，自动收集覆盖率数据和失败堆栈，再把失败信息回灌给模型做修复。整个过程中，人只需要做两件事：定义标准，审核结果。

这个链路对模型的能力要求完全不一样了。前面只需要“理解”，到这里需要“生成代码”，而且生成的代码必须能编译、能跑、断言有意义，还得能适配你项目的技术栈和测试框架。经常测试的人都知道，写一条“能跑且真正验证了逻辑”的测试用例，比写十行业务代码要费劲得多——你既要理解被测函数的输入输出语义，又要设计边界条件，还得考虑mock哪些依赖。

大模型能不能在这个环节真正替代人的判断力，是我判断一个测试用例生成方案是否成熟的最硬指标。很多模型的代码能力在LeetCode上刷分刷得飞起，一遇到项目里那种依赖一堆Service、牵一发动全身的老代码，生成出来的测试跑都跑不起来，这就是典型的“会做题、不会干活”。

2. 选哪家模型？先建立一套自己的评估标准

直接给结论容易挨骂，因为不同团队的处境差太远了。有的团队项目代码全是内部业务系统，压根不允许用外部API；有的团队技术栈统一、CI基础设施完善，就缺一个能稳定产出的用例生成器；还有的团队连PRD都没有，只有一张原型图。需求不同，选择必然不同。

但选型思路是可以标准化的。我做AI测试辅助选型的时候，说到底是围绕四个维度打分的，谁在这四个维度上综合表现稳定，谁就值得进POC名单。

2.1 核心评估维度：多模态、上下文、Function Call与代码能力

第一个维度是多模态视觉理解能力。这一条决定了“看懂设计稿”的上限。具体怎么测？不要用那种干净的、像素级的UIKit设计稿去测，那是广告。拿你自己项目里有真实业务的海报、原型图、带各类状态的界面截图去测，看它能不能认出不同类型的控件、能不能理清控件间的从属关系、能不能指出那些被遮挡或半透明的元素。

第二个维度是长上下文处理。一份正经的PRD动辄一万字起步，再加上设计稿标注、交互说明，拼在一起之后上下文很容易超过十万里程碑。模型对长文本的首尾注意力衰减问题，会直接导致它漏掉中间的关键需求。这个维度我一般用“找茬”的方式测：故意在文档中段埋几个反常识的需求点，看模型生成的用例里会不会体现出来。

第三个维度是Function Call或工具调用的稳定性。自动跑单测这个环节，本质上是一个Agent循环：生成代码、执行、读取结果、修复、再执行。每一步都要模型按约定好的JSON格式输出结构化指令，调用对应工具。有些模型对话能力很强，但一遇到严格参数约束的任务就频繁格式错乱，这类模型做聊天助手没问题，做自动化分支就不够格。简单说，模型能不能在系统提示词明确要求“每次输出严格遵守JSON Schema”时做到零失误，这是一个一票否决的指标。

第四个维度是代码生成与修复能力。这里我要额外强调“修复”这两个字。生成一次代码不难，难的是给它一个编译错误堆栈、几个失败的断言信息，它能不能准确定位到问题并做最小幅度修改。我把这一项看得特别重，因为真实场景里，第一轮生成就能通过的测试代码占比通常不高，大部分情况都需要两三轮迭代。

2.2 当前值得关注的模型梯队与适配场景

按照当前的实际体验，我把市面上的模型大致分成三档，每档对应不同的团队场景：

第一档，综合实力最均衡的多模态大模型。这类模型在处理复杂设计稿理解、长上下文语义关联、结构化输出方面表现都比较稳，基本可以一条龙支撑“设计稿→用例→代码→执行”的完整链路。适合对效果要求高、团队内没有专职提示词工程师、希望开箱即用的场景。需要留意的是这类模型一般以API服务的形式使用，计费相对较高，调用量大了之后成本需要提前测算。

第二档，代码专项能力突出的闭源大模型。这类模型的强项集中在代码生成、代码理解、项目级上下文分析上，在“自动跑单测”这个环节往往表现突出。如果你团队的PRD体系已经比较完善，设计稿这边的压力不大，核心痛点集中在老项目补测试、提高单测覆盖率，那这类模型就非常对口。它的短板是多模态能力相对弱一些，看设计稿还是能看，但精细度不如第一梯队。

第三档，开源可私有化部署的大模型。数据敏感型团队一般只能选这一档。目前开源模型在文本理解、结构化输出、代码生成这些方面的能力已经能用，短板主要集中在复杂图像的细粒度识别上——原型图里密密麻麻的控件，开源多模态模型偶尔会漏识别或错识别。但这部分可以靠工程手段补：把设计稿标注信息结构化提取出来喂给模型，减少对纯视觉理解的依赖。

我的建议是不要一开始就锁死在某一家，而是挑选两三家进入POC，用自己团队的真实项目数据跑一遍，拿结果说话。供应商宣传得再好，不如你把自己那几张魔鬼设计稿丢进去验一验来得实在。

2.3 我最看重的三个实测指标

除了上边四个维度，我自己的选型清单里还有三个隐藏指标，这三个指标在官方Demo里根本看不出来，必须自己实测：

第一个是“对同一张图的多次生成稳定性”。同一个设计稿，同一个Prompt，连续生成三次，如果三次输出的测试点差异巨大，这个模型在我这里得分直接腰斩。说明它的注意力分布不稳定，到了真实生产环境里，你很难跟团队解释为什么同一个需求今天生成的用例和明天生成的用例不一样。

第二个是“对模糊信息的追问意愿”。好模型在遇到设计稿里看不清的元素、PRD里没写的字段类型时，应该主动提问，或者至少在输出里标记“此处需要确认”。差模型会硬着头皮编一个看起来合理的假设，然后一本正经地生成一系列基于错误假设的用例。这个差异，几乎就是专业工程师和实习生的分水岭。

第三个是“对负面反馈的接受度”。你在回复里告诉它“这条用例的断言反了”，它下次生成时能不能记住这个修正，还是说换个花样又把同样的错犯一遍。这个指标本质上衡量的是模型在与Agent框架配合时的上下文遵循能力，我见过太多模型在单轮对话里表现聪明，放进多轮Agent循环里就变得“屡教不改”。

3. 让模型真正看懂设计稿的落地细节

模型选好了，接着就得解决“看懂”这个具体工程问题。这一步没有太多神秘感，核心就是：怎么把一张PNG图片变成模型可以稳定理解的“结构化需求信息”。

3.1 设计稿输入不是“甩一张图”那么简单

我见过太多人走这个极端：把一张包含几十个控件、状态复杂、还有多种弹窗叠加态的设计稿直接丢给模型，然后期待它给出完美的用例。真实情况往往是模型看了半天，只识别出表面的几个主要控件，弹窗、空态、异常态统统忽略，输出结果惨不忍睹。

这里面的核心原因是：人类看设计稿，会自动忽略掉装饰性元素、知道哪些是静态文案哪些是可交互控件，但大模型没有这个先验，它只能依赖训练数据里学到的“界面常识”来猜。所以一个负责任的设计稿输入流程，至少要经过三道预处理：

第一道，把设计稿按功能模块切片。不要一张长图整页发过去，先人工或者用视觉模型把页面拆成若干区块：顶部导航区、内容检索区、列表展示区、弹窗组件区，每个区块单独让模型分析，再汇总结果。切片之后，模型的视觉注意力会集中得多，控件识别率肉眼可见地提升。

第二道，给关键元素做语义标注。如果你用的是Figma或者即时设计这类工具，建议直接把标注信息导出成JSON，把按钮的文案、大小、颜色、层级关系结构化地描述出来，作为辅助信息提供给模型。相当于给模型发了一张图，同时附上“这张图的重点都替你圈好了”的说明。不考虑架构复杂度的话，这一步能减少绝大部分的视觉误判。

第三道，把PRD和设计稿配对输入。同一块功能，文字描述里会写“账号未注册时提示错误”，设计稿里会画出具体的错误提示样式，两者互为补充。只给模型看设计稿，它不知道业务规则；只给PRD，它脑补不出界面细节。两边拼在一起，才是一个完整的输入。

3.2 一套可复用的Prompt组织模板

预处理做完，接下来这一步就是写Prompt了。我试过很多种写法，最后沉淀下来一套相对稳定的模板结构，分享出来供参考。这套模板不依赖特定的模型，各家大模型基本通用。

为节省篇幅，我用一段伪Prompt来说明核心结构，实际使用时会按需调整：

你现在是一名资深测试工程师，负责为以下产品功能设计测试用例。 你的工作包含两个阶段：先理解需求，再输出用例。 【阶段一：需求理解】 请先分析我提供的设计稿和PRD，完成以下输出： 1. 页面核心功能清单，按用户视角描述 2. 页面中的可交互元素清单（按钮、输入框、下拉框、勾选项、弹窗等） 3. 每个交互元素的触发条件、行为反馈、异常场景 4. 设计稿中未明确但根据业务常识应该存在的边界场景 【阶段二：用例输出】 基于阶段一的理解，按以下规则设计测试用例： 1. 用例覆盖：功能主流程、分支流程、异常流程、边界值、数据唯一性约束 2. 用例格式：编号、前置条件、操作步骤、预期结果、优先级 3. 不得输出：与页面功能无关的通用性用例、没有具体前置条件的空泛用例 4. 对于信息不确定的部分，用【需确认】标注，不要擅自假设

这套Prompt的核心在于“先理解再输出”。实践下来，它会逼模型先完成一轮信息整理，再基于整理结果生成用例，质量明显高于一上来就甩格式要求的方式。

3.3 结构化的用例输出格式：从“一句话”变成“可执行需求”

Prompt写得再好，如果输出格式烂，后面的自动化链路照样跑不通。接口测试和单元测试领域的同学可能比较熟悉“用例即代码”的理念，但面向产品侧的测试用例生成，最终往往要落在两个去向：一是给人工评审用，二是喂给自动化生成器。所以输出格式必须兼顾可读性和可执行性。

我目前使用的用例输出格式是一个带嵌套结构的JSON。外层是每条用例的基础信息，内层是前置条件和预期结果的机器可读描述。给个简化例子：

{ "case_id": "TC-LOGIN-001", "title": "验证未注册手机号登录时提示账号不存在", "preconditions": { "data_setup": "数据库中存在已注册用户13800000001，密码正确；测试手机号13800000002未注册", "system_state": "用户已退出登录，处于登录页" }, "steps": [ {"action": "input", "target": "phone_input", "value": "13800000002"}, {"action": "input", "target": "password_input", "value": "abc12345"}, {"action": "tap", "target": "login_button"} ], "expected": { "visible": {"toast": "该账号尚未注册"} }, "priority": "P1" }

模型输出这种东西，比输出一大段自然语言要慢一些，但换来的是下游自动化工具可以无缝对接，不需要再写一堆解析逻辑去猜“步骤里的第几步做了什么操作”。实战下来，这点“慢”是完全值得的。

4. “自动跑单测”闭环：从生成用例到回归验证

设计稿看懂、用例生成完，这只是走了一半路。下面这部分，是真正把大模型从“辅助工具”变成“生产线”的关键环节。

4.1 生成单测代码的取与舍

很多团队的测试代码质量参差不齐，老项目几乎是测试荒漠，覆盖率常年徘徊在个位数。这时候想让大模型直接生成一套完整的单测，不现实。我的做法是分阶段走：

第一阶段，只做“新代码测试覆盖”。从Git提交记录里捞出最新的变更文件，只要求模型为这部分新代码生成单测。因为这个范围内代码量小、上下文干净、依赖关系相对简单，模型生成成功率最高。

第二阶段，处理“核心业务逻辑的存量代码”。这类代码通常复杂度高、外部依赖多，直接生成测试容易翻车。需要在项目级上下文里做细化——把被测类涉及的接口定义、依赖注入方式、数据库访问层这些都提取出来，作为额外信息喂给模型，并要求它先输出测试方案，经人工确认后再写代码。

第三阶段，才轮到“全量覆盖率提升”。等到前两阶段跑顺了，团队积累了足够多的、经过人工验证的测试样例，这时候可以让模型对照已有样例的风格去补剩余模块的测试，保持风格统一。

这里有一个特别容易踩的坑：大模型生成单测时，默认会走“happy path”。十个开发者有九个见过这种测试——步骤全部按正常流程走，输入都是合法值，断言永远不倒。这种测试拿覆盖率糊弄人还行，但真正出问题的时候，它大概率什么都拦不住。所以我在每次生成Single Test的时候都会在Prompt后面加一句强制要求：“必须为每个函数至少设计一个异常分支测试和一个边界值测试”。

4.2 自动执行与结果回灌的实现思路

用例生成完了，代码也有了，下面进入自动执行环节。这个环节我建议直接和团队的CI/CD流水线集成，每有一个新的代码提交，或者每次测试用例生成完成后，自动触发一次测试任务。

整个执行闭环可以抽象成四步循环：

第一步，执行单测并统计覆盖率。这一步用现成的覆盖率工具就行，后端Java用JaCoCo，前端TypeScript用Vitest或者Jest的覆盖率模式，Python项目用pytest-cov。关键是把覆盖率数据和失败详情按统一格式导出成JSON文件，方便后续喂回模型。

第二步，解析失败信息。测试跑完，把编译错误、断言失败信息、堆栈日志、覆盖率报告全部打包成结构化文本。注意，堆栈日志不是越长越好，截取前几十行关键信息就够了，否则上下文被无关日志塞满，模型反而抓不住重点。

第三步，把失败信息回灌给模型。这是Agent闭环的核心：给模型提供“生成失败的测试代码→执行结果→失败原因分析→修复建议”的上下文，请求它输出修改后的完整测试代码。这里对模型的格式遵循能力要求很高，它必须严格按照约定的格式输出可替换的代码文件，不能夹杂多余的解释文本。

第四步，自动替换并重跑。拿到修复后的代码，覆盖掉旧文件，重新执行测试任务。重复上述循环，直到全部通过或者达到预设的最大迭代次数（我一般设为3次，超过3次还修不好，基本就不是模型能解决的问题了，需要人工介入了）。

这个闭环跑通之后，整个测试用例生成流程才真正做到了“生成即验证”。模型产出的每一份用例，都经过了实际运行的检验，而不是停留在纸面上的漂亮文字。

5. 实测中避不开的坑与排查思路

这个方案我在多个项目里落地过，过程中遇到不少奇奇怪怪的问题。挑几个典型的整理成速查表，基本能覆盖大多数人会遇到的坑。

5.1 常见问题速查表

5.2 我把踩坑经验固化成了一条内部SOP

多轮实践之后，我现在把整个流程沉淀成了团队内部的SOP，核心就五条：

第一，所有设计稿必须先经过预处理，没有经过切图、标注和PRD配对的设计稿，禁止直接送入模型。这条乍看有点死板，但省的麻烦远大于增加的步骤。

第二，Prompt模板和用例输出Schema必须版本化管理。不要每个人自己改Prompt，改动了要记录版本和效果差异。AI生成用例这件事，某种程度上已经从“调Prompt”变成了“配置测试生成策略”，既然上升到了工程范畴，那就要有配置管理的意识。

第三，自动执行环节的CI任务必须设置超时和资源限制。生成单测并执行这个动作，比普通的编译任务要重得多，如果不在流水线里做资源隔离，很容易拖垮整个CI。

第四，定期人工复核模型生成的测试质量。我目前的做法是每两周随机抽取一批模型生成的测试代码，按分钟级投入做一次Code Review，发现问题及时调整Prompt和流程配置。这个环节不能省，省了模型会在你不知不觉间飘走。

第五，所有失败案例必须回流。每一次模型修不动、只能人工介入的案例，都是排查提示词缺陷、理解Deep Bug的好素材。把这些案例存档，定期分析，最后你团队的那套提示词和流程，会越来越像一个真正的“测试专家系统”。

关于选型，我的最终建议

写了这么多，回到标题那个问题：测试用例生成到底推荐哪家大模型？我的回答是，如果你只打算用一个模型覆盖完整链路，优先挑多模态理解和结构化输出能力均衡的头部闭源大模型，尤其是那些在“看图+解析控件关系+输出结构化JSON”上表现稳定的。如果你们的场景是补充存量代码单测，则可以重点评估代码专项能力和多轮修复能力更强的那几家。如果数据不能出内网，就选开源模型，但必须在预处理阶段多下功夫，把设计稿信息尽量结构化，减少对纯视觉能力的依赖。

说到底，哪家模型都不是银弹。真正决定落地效果的，是你有没有把输入做干净，有没有把输出接进自动化闭环，有没有一套持续修正和评估的工程机制。模型的智商决定了上限，工程化能力决定了你能不能摸到那个上限。先把后者想清楚，再回头根据自己的预算和场景去选模型，就不会在铺天盖地的宣传里迷路了。