上周有个朋友来问我测试用例生成到底推荐哪家大模型我反问他你打算拿什么喂给模型他说把代码贴过去让它写测试啊。这是大多数团队默认的用法但也是我这两年被问得最多、最想纠正的一个用法。把源码直接丢给大模型生成测试用例本质上是让模型照着答案出题分支覆盖率看着挺高真正能发现问题的用例却没几个。我自己把市面上能排上号的大模型都陆续接进测试链路跑了一轮之后结论很直接判断一家大模型适不适合做测试用例生成就盯住两件事——能不能看懂设计稿以及能不能自动跑通单测。这两件事才是从玩具级demo到生产可用的分水岭。1. 先对齐评价标准只会抄代码的测试用例生成价值要打个对折1.1 为什么直接丢代码这条路看着通、实际堵先说一个我踩过的坑。去年我把一个订单模块的service层代码完整贴给模型让它生成单元测试。模型吐了三十多个用例我本地跑完覆盖率报告一出来——行覆盖率87%分支覆盖76%数字很漂亮。但等我把一个注册接口的异常路径故意改错再跑这批用例居然没有一个用例红了。原因不复杂模型是看着代码生成的用例它只会复述代码已经写好的路径。代码里某个if分支压根没写错误处理模型也不会主动补上这个断言。这就是以代码测代码的死穴你的用例质量上限被当前代码质量锁死了。真正的测试设计应该是从需求出发的——PRD里写了密码输错三次要锁定设计稿里画了输入非法格式时红色提示这些信息在最终代码里可能已经被实现得七零八落也可能压根就没实现。让模型直接看代码它永远发现不了代码漏掉了需求。1.2 看懂设计稿、自动跑单测这两件事的本质所以我现在选型就只看两个能力。第一个看懂设计稿。这里的“设计稿”我用的是一个泛指包括UI设计图、PRD里画的原型、视觉稿甚至Figma导出的标注。模型需要从这些图形和结构化描述里提取出测试对象——页面有哪些元素、元素有哪些状态、用户有哪些操作路径、系统有哪些预期反馈。能完成这一步意味着模型真正理解了需求语义而不是在做代码模式匹配。第二个自动跑单测。单测全称单元测试是对代码最小可测单元的行为验证。模型生成的不只是一段看起来像测试的代码而是要能被编译、被运行、被断言校验的测试代码并且能在失败后自己读取报错信息、调整mock、修复断言最终让测试套件全绿。这一步决定了它是帮你写代码还是帮你测代码——只有跑起来才知道生成的东西对不对。1.3 我的选型打分表不看名气看三个可量化指标我把选型标准收敛成三个可量化的指标下面是基于我自己搭建的一套基准工程实测得到的数据测试对象是一个订单管理模块人为埋入10个缺陷。指标含义实测参考值编译通过率生成代码能一次性通过编译的比例差的模型不足60%好的能到90%以上首轮单测通过率生成完直接执行、不做任何修复的用例通过比例差的在30%-50%好的能到80%缺陷检出率埋入的缺陷能被用例抓住的数量只抄代码的模型普遍低于3/10能读懂需求语义的模型能到7/10以上这三个指标基本能过滤掉九成看起来很会的大模型。名气再大编译都过不了的模型接进CI持续集成就是灾难。2. 看懂设计稿这件事比想象中难多模态理解的四个实际关卡2.1 关卡一布局信息不等于视觉语义模型要读懂设计稿不光是识别出这里有个按钮。我拿一张订单列表页的设计稿测试页面顶部是搜索框下面是三个筛选tab右侧是排序按钮列表带分页。多数模型能报出这些元素但问它筛选tab切换之后排序按钮是否还生效有些模型就开始编了。布局识别是OCR级别的能力理解交互状态和页面层级才是真正的语义理解。你在选型时可以自己做个实验丢一张带空态的设计稿给模型如果它只会罗列图上画出来的元素不会追问、不会推断未画出的loading态和错误态那它基本不具备测试设计需要的需求推理能力。测试用例生成不是看图说话是看图猜行为、补状态、挖边界。2.2 关卡二状态与异常场景的挖掘设计稿里通常只画了正常态。空态、加载态、断网、超时、非法输入这些测试用例的富矿图纸上未必有。好的模型会基于类似产品的先验知识推断这些状态然后生成对应的测试用例。这其实是判断模型有没有测试思维的关键。如果模型只会照着图面元素翻译用例它顶多算个OCR工具。我在实际使用中会让模型在生成用例前先输出一份测试场景清单把正常流、分支流、异常流、边界流全部列出来再针对清单逐条生成用例。这个步骤看起来很笨但能明显拉开不同模型之间的差距。有测试思维的模型列出的场景清单基本接近一个中级测试工程师的水平而只会看图翻译的模型列出的场景基本就是正常提交、正常查询、空列表三件套。2.3 关卡三多图联动与PRD对齐实际项目里我一般不单独丢一张设计稿而是把PRD多张设计稿一起给模型。PRD给出业务规则设计稿给出交互形态。模型需要自己把PRD里的规则和设计稿里的元素对应起来。比如PRD说下单金额超过500元要进入人工审核那测试用例就得覆盖499、500、501三个金额边界并且断言界面出现审核提示。这里很考长上下文能力和跨模态对齐能力。上下文窗口不够大的模型你塞给它五张设计稿加一份PRD后面几张图的信息基本等于没看见它会一本正经地只基于最早看到的图去编用例。我的经验是输入材料超过十页之后不同的模型在信息召回率上会有肉眼可见的差距有的能把PRD第12页的规则落到用例里有的早就忘光了。2.4 关卡四图像输入格式与成本控制实操层面设计稿一般要导出成PNG或PDF单张平均1到3MB。多模态模型的图像token消耗比纯文本大得多一次喂十张设计稿成本会明显上涨。我现在的做法是先用工具把设计稿压缩成长边不超过1536像素的版本再把关键区域裁剪成小图配合文字标注一起送进去。既保住关键信息又控制成本。还有一个小技巧如果是Figma等工具协作的团队可以直接把设计稿的标注信息和CSS属性导出来转成结构化的JSON文本喂给模型。纯文本描述比图片token便宜得多而且对布局、间距、颜色的理解更精准。这种方式下模型等于看了一份带坐标和样式信息的页面结构说明书比纯图像输入稳定得多。3. 自动跑单测才是“王道”的准确含义一次生成与修复合一的工程闭环3.1 静态生成的测试代码十有八九是看起来能跑我第一次接大模型生成用例的时候觉得生成能跑的测试代码应该是最基本的要求。结果被现实教育了JUnit测试里import错了包pytest的fixture命名不对mock对象和被测函数签名对不上这些错误五花八门但有一个共同点——不执行根本发现不了。模型写代码的流畅和代码能通过编译中间隔着一条性能鸿沟。这也是为什么我特别强调“自动跑单测”而不是“生成单测代码”。现在很多模型Demo里展示的测试用例生成就是把测试代码打印出来给你看看着像模像样一跑就废。真正生产可用必须形成闭环模型生成代码工具自动执行失败信息再喂回给模型去改。这一步不做生成用例就只能停留在演示阶段。3.2 闭环工作流生成、编译、执行、反馈、修复我现在标准流程长这样把设计稿、PRD、被测代码的接口签名一起给模型让它生成测试用例。自动执行编译收集编译错误。编译通过后自动跑测试收集失败的断言和日志。把编译错误和测试日志回灌给模型让它自己修。重复执行直到通过率稳定最后人工review一遍关键用例。整个过程跑下来一个模块的用例大概要迭代3到5轮。首轮通过率通常只有50%左右但经过两三轮修复之后能稳定提到95%以上。这里最关键的变量是模型能否理解日志信息。有些模型看到报错只会机械地删掉报错的那一行结果下一个错误又冒出来这种模型的自我修复能力基本等于零接进闭环也白搭。3.3 单测框架和Mock策略的选择单测框架层面我常用的组合是Java项目用JUnit5加MockitoPython项目用pytest加pytest-mock前端组件用Vitest加Testing Library。这些组合的好处是社区成熟、报错信息友好模型见过的语料也多生成出来的代码风格更符合常规。Mock策略上有一个关键原则必须写进prompt只mock外部依赖不mock被测对象自身的方法。模型如果不加约束容易把整块被测代码都mock掉生成一堆自娱自乐的用例断言全过但没有验证任何真实逻辑。我见过最离谱的用例是把被测类的私有方法都mock了一遍然后断言mock返回值等于预期值——这种用例对质量保障一点价值没有。3.4 一条前端业务的实测效果拿我最近做的一个创建订单表单来举例。人工写一套覆盖正常提交、必填校验、金额边界、接口超时的用例大概需要大半天用大模型闭环跑把PRD和设计稿喂进去40分钟出第一版再迭代两轮整体能在两小时内达到可用状态。数量上模型第一版生成了24个用例人工review后删掉3个无效的保留21个最终跑通覆盖率在核心逻辑上比人工版本还高8个百分点。真正让我觉得值得的不是省时间而是它把测试用例的维护方式改变了需求一改设计稿一更新重新喂一轮用例骨架能自动跟着变而不是像人工那样从零开始改。这一点对迭代快的团队价值很大。4. 我给不同模型做的开箱实测同一批设计稿、同一个项目、同一套指标4.1 测试方法说明我选了一个内部订单管理的前端加后端小项目前端有列表页、详情页、创建表单三个页面后端有下单、查询、取消三个接口。设计稿准备了6张PRD一份。每个模型跑三轮记录设计稿理解准确度、编译通过率、首轮通过率、缺陷检出率四个维度。以下数据是我个人在特定版本和特定输入下的实测结果模型版本更新很快数据会随时间变化只展现当时的能力基线。4.2 主流模型的表现与点评模型设计稿理解编译通过率首轮通过率缺陷检出率综合点评GPT-4o系列很强能理解交互状态90%以上80%左右7/10综合能力均衡图片理解细腻但中文PRD偶尔过度解读Claude系列强跨模态对齐好90%以上75%左右7/10代码质量高长文档能力强适合PRD加多图场景DeepSeek系列中上图片细节略弱85%以上70%左右6/10代码推理强、性价比高适合纯文本PRD驱动的生成豆包中上中文语义好80%左右65%左右5/10中文场景理解好生成速度快复杂图表理解稍弱通义千问VL中上中文视觉理解好85%以上70%左右6/10开源可私有化中文设计稿识别在同级里靠前CodeBuddy中等偏上85%以上70%左右6/10IDE集成体验好适合直接基于工程上下文生成这份结果里最出乎我意料的是单纯比较代码生成能力国内几款模型已经追得很近了差距主要出现在设计稿理解和长文档对齐上。如果你们的场景是接口级测试用例生成输入主要是接口文档和代码那几款头部模型的差距已经很小按价格选就行。但如果是UI级、有设计稿输入多模态能力的差距就会明显拉开。4.3 成本和速度不是小事直接影响落地意愿生成测试用例这件事对成本其实比很多人想象的敏感。一个模块一轮生成几十个用例API调用按token计费如果还要迭代四五轮一个中等项目的成本就在几十块到几百块之间。这个钱单看不贵但如果你打算把整条CI链路每个MR合并请求都跑一遍日积月累就是一笔不小的支出。速度上也要关注响应时间。模型生成速度快你迭代闭环就快反之整个流程等得人发慌。实测下来输出速度快和设计稿理解能力强的模型往往不是同一个所以实际选型常常要做平衡设计的环节用理解力强的模型纯代码生成的环节用速度快、便宜的模型。4.4 开源模型本地化部署的边界如果企业对代码安全很敏感核心代码不能出内网那就要考虑本地部署开源模型。千问、DeepSeek蒸馏版等都有适合单卡运行的7B、14B版本。但你要有心理准备本地小参数量模型在代码生成上能接近API模型的水平但在设计稿理解上会明显下降。我现在的做法是分层策略设计稿理解和PRD语义分析放在API端的强多模态模型上生成代码和mock数据放在本地开源模型上。设计稿的相关描述和元素清单由API端输出成结构化的中间文件本地模型基于中间文件生成具体测试代码。这样既保住设计稿理解能力核心代码又不出内网。当然如果你的项目对数据安全没有那么苛刻直接用API端的统一模型体验最顺滑。5. 踩过的坑和补救办法从“看起来能跑”到“真正能回归”5.1 坑一模型假装看懂设计稿我遇到过的最典型问题是模型一本正经地描述页面上有一个“导出Excel按钮”但设计稿里根本不存在。原因是模型没有真正把图像特征和文本描述对应上而是凭经验补全了按钮。这种情况在复杂图表、视觉层级密集的设计稿上出现概率很高。对策有两个。第一在prompt里强制要求模型只依据图片信息作答不确定的元素标注为未知不允许脑补。第二加一道自动校验环节让模型输出页面元素清单转成JSON格式再和设计稿的实际标注做对照不一致的地方直接标记出来让人工确认。这个校验环节会拦截掉一大部分幻觉。5.2 坑二mock数据不匹配导致用例假绿大模型生成的mock数据经常和真实接口返回结构不一致但断言只判断HTTP状态码等于200所以测试全绿实际业务逻辑等于没测到。这种假绿比测试跑挂更危险因为它们会给你虚假的安全感。对策是让模型先基于接口契约生成mock模板。如果你有OpenAPI或者Swagger文档优先把接口契约喂给模型让mock数据结构严格跟着契约走再人为设计边界值和异常值填进去。断言上也要做字段级校验不只断言状态码还要断言返回体里的关键字段值。这样mock不匹配的问题能在生成阶段就被拦住。5.3 坑三用例重复和测试套件膨胀大模型每次迭代都会生成一批新用例多轮之后测试套件里会出现大量雷同用例拖慢CI速度也稀释了测试结果的可读性。我最夸张的时候同一个接口被生成过七八个几乎一样的用例只是断言的字符串字面量不一样。对策让模型在生成前先扫描已有测试文件自动沿用已有的命名规范和描述风格并对相似度高的用例做去重。同时上线前用覆盖率报告做一次清理把长期没有被变异测试命中过的低价值用例删掉。这不是一次性工作需要定期做不然测试套件会像囤积癖房间一样越来越臃肿。5.4 坑四覆盖率上去了缺陷检出率没跟上这是头号隐性坑。模型生成的用例偏向happy path和常见异常路径对极端边界、并发场景、时序问题覆盖得很少。所以你的覆盖率报告可能很好看但真实缺陷检出率并没有明显提升。我埋入一个并发扣库存的缺陷十个模型里只有一个生成的用例抓住了它。对策用变异测试的思路去引导模型。具体做法是手动在源码里注入几个典型缺陷跑一遍生成的用例找出哪些缺陷没有被任何用例抓住然后把对应的代码片段和缺陷描述回喂给模型让它补充用例。这个思路是我用了这么多方法里最有效的因为它把大模型的生成目标和真实的测试目标拉齐了。6. 落到自己团队里的接入顺序与底线建议6.1 从试点模块开始不要一上来全量铺开我见过不少团队引入大模型测试用例生成一开始就让所有开发都用结果三天不到就怨声载道。原因是不同模块、不同开发者的代码风格差异很大模型的生成质量极不稳定。我的建议是选一个业务逻辑相对清晰、测试基础较好的模块先试点跑通流程之后把经验沉淀成团队内部的生成规范和提示词模板再逐步推广。试点期间要重过程记录每轮生成的用例数、通过率、修复轮次、缺陷检出数都记下来。这些数据是后续说服团队和领导的关键依据。6.2 给模型配置一份团队测试规范模型生成的用例风格默认是通用风格不一定符合你们团队的规范。比如团队要求用例命名必须包含被测方法的类名要求每个用例必须有边界值要求断言不允许直接返回布尔值等等。这些规范应该写进系统提示词里而不是写完用例再靠人肉review去修正。我整理过一个团队测试规范模板一般包含命名规范、断言规范、Mock边界、覆盖率要求、禁止事项五段。实测下来加规范后生成的用例人工review修改比例从七成降到了不到三成效果非常明显。6.3 数据安全底线敏感代码和产品数据不入外部模型这是我最想强调的一条底线。测试用例生成需要喂代码、喂需求、喂设计稿这些材料里可能包含核心业务逻辑和用户数据。接入任何外部大模型之前必须先过一遍脱敏流程把代码里的业务关键词、字段名、IP地址、服务名替换掉设计稿上有用户信息的区域打码。这个流程要固化成自动化步骤不能依赖人工自觉。如果脱敏成本太高就直接上本地部署方案宁可牺牲一点生成质量也要守住数据安全。测试数据泄露这种事一次就够让整个部门陪葬这个风险不值得冒。6.4 最终验收就一条线上缺陷率有没有下降工具再好最终还是要看结果。大模型测试用例生成这项能力不应该以生成了多少用例为衡量标准也不应该以覆盖率数字为目标。真正的验收指标只有一个上线后的线上缺陷率有没有下降尤其是需求理解类缺陷有没有减少。我自己的判断标准是如果模型生成的用例能在评审阶段就发现开发同学对PRD理解偏差的问题那这个模型是真的看懂了设计稿。如果生成的用例只能抓住代码本身的低级错误那它跟静态分析工具没有本质区别只是因为用例数量大而显得勤奋罢了。测试用例生成选型说到底就是在为质量保障体系选一个会读需求、会自证结果的新同事。选之前先拿你们自己的一张设计稿和一个小模块去考一考它答案会自己浮出来。