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 常见问题速查表问题现象根本原因排查思路解决办法模型把设计稿里的装饰性图案识别成功能元素视觉理解只停留在像素层缺少交互语义用切片后的设计稿替换整图增加语义标注预处理阶段去噪给模型提供控件标注JSON生成的测试用例全是主流程边界值基本没有Prompt里没有约束边界设计模型默认走正常路径检查生成结果中P2/P3优先级用例占比在Prompt中显式追加“必须包含异常分支和边界值”约束单测跑完覆盖率很高但全是无效断言模型用assertNotNull(obj)这类兜底断言应付了事抽查生成的测试断言密度看是否有针对业务结果的具体断言给模型提供1-2个团队内高标准的测试样例作为few-shot参考多轮修复时模型“越改越离谱”最后代码直接编译不过超过模型修复能力的复杂度上限或上下文被历史错误污染检查迭代轮次前后的代码差异判断是否在局部修改设置最大迭代次数超限后自动降级为“跳过并输出报告”长PRD环境下模型漏掉文档中段的需求点长文本注意力衰减中段信息被忽略将文档分段输入或把核心需求点先结构化提取出来先用模型做文档摘要和需求点抽取再基于抽取结果生成用例不同模型对同一设计稿的识别结果差异很大各家的视觉编码器训练数据和推理策略不同在POC阶段用同一组测试集横向对比固定一两个主用模型通过工程手段补足短板不要频繁切换5.2 我把踩坑经验固化成了一条内部SOP多轮实践之后我现在把整个流程沉淀成了团队内部的SOP核心就五条第一所有设计稿必须先经过预处理没有经过切图、标注和PRD配对的设计稿禁止直接送入模型。这条乍看有点死板但省的麻烦远大于增加的步骤。第二Prompt模板和用例输出Schema必须版本化管理。不要每个人自己改Prompt改动了要记录版本和效果差异。AI生成用例这件事某种程度上已经从“调Prompt”变成了“配置测试生成策略”既然上升到了工程范畴那就要有配置管理的意识。第三自动执行环节的CI任务必须设置超时和资源限制。生成单测并执行这个动作比普通的编译任务要重得多如果不在流水线里做资源隔离很容易拖垮整个CI。第四定期人工复核模型生成的测试质量。我目前的做法是每两周随机抽取一批模型生成的测试代码按分钟级投入做一次Code Review发现问题及时调整Prompt和流程配置。这个环节不能省省了模型会在你不知不觉间飘走。第五所有失败案例必须回流。每一次模型修不动、只能人工介入的案例都是排查提示词缺陷、理解Deep Bug的好素材。把这些案例存档定期分析最后你团队的那套提示词和流程会越来越像一个真正的“测试专家系统”。关于选型我的最终建议写了这么多回到标题那个问题测试用例生成到底推荐哪家大模型我的回答是如果你只打算用一个模型覆盖完整链路优先挑多模态理解和结构化输出能力均衡的头部闭源大模型尤其是那些在“看图解析控件关系输出结构化JSON”上表现稳定的。如果你们的场景是补充存量代码单测则可以重点评估代码专项能力和多轮修复能力更强的那几家。如果数据不能出内网就选开源模型但必须在预处理阶段多下功夫把设计稿信息尽量结构化减少对纯视觉能力的依赖。说到底哪家模型都不是银弹。真正决定落地效果的是你有没有把输入做干净有没有把输出接进自动化闭环有没有一套持续修正和评估的工程机制。模型的智商决定了上限工程化能力决定了你能不能摸到那个上限。先把后者想清楚再回头根据自己的预算和场景去选模型就不会在铺天盖地的宣传里迷路了。