大语言模型刚火起来那段时间我所在的测试团队就在琢磨一件事能不能让AI真正帮忙写测试用例而不是停留在“给个样例、填个参数”的玩具阶段。试了大半年从最初拿公开API跑简单接口用例到后来把模型接进内部平台让它在每次迭代里自动产出可执行的用例集踩了不少坑也梳理出一套还算能复用的方法。这篇文章就把我们走过的路、选型时考虑的问题、落地时遇到的坎以及最终的实践方案完整写出来。这个话题适合所有正在尝试用AI改造测试流程的人不管是测试开发、测试经理还是对AI落地感兴趣的后端工程师。我会尽量少讲空泛的概念多给能直接在团队里试起来的东西。如果你正准备立项做“AI生成测试用例”或者已经试过但效果不理想这篇文章应该能帮你少走几个月的弯路。1. 内容整体设计与思路拆解1.1 为什么测试用例生成偏偏要靠大语言模型先聊一个更底层的问题测试用例生成的难点到底在哪。以前我们常用的自动生成手段无非三类。第一类是模板填充定义一个用例模板把参数、预期结果占位符替换进去适合重复度极高的接口测试但一旦业务逻辑复杂模板就撑不住了。第二类是基于代码分析的路径覆盖用静态分析或者符号执行去枚举分支条件这在单元测试层面有一定效果但到了接口级、业务级的用例设计代码结构根本不足以表达业务语义。第三类是录制回放把线上请求录制下来变成回归用例实话说这个很实用但它只能覆盖已经发生过的场景没法生成还没发生但应该被覆盖的场景。这三类方法的共同问题是它们都不理解“业务”。一次下单、一次退款、一次优惠券叠加这些行为中哪些边界值得测、哪些组合容易出问题靠代码结构和历史数据是推导不出来的。而大语言模型在大量代码、技术文档、业务文案上预训练过它对“一个电商下单流程大概要考虑什么”是有先验认知的。这恰恰补上了传统方法的短板——它能从语义层面理解被测对象然后把这种理解转化成用例。所以大语言模型不是来替代传统用例设计的它是来补足“业务语义理解”这一层的。1.2 从“让AI写用例”到“AI真正改变用例生产方式”我们团队立项之初目标很朴素让模型读接口文档吐出一份可执行的接口测试用例。后来发现这只是最浅的一层。真正产生价值的是后面这几件事第一模型可以把自然语言的需求描述直接映射成测试场景。比如产品文档里写“用户可以在购物车中批量删除已失效的商品”模型能自动拆解出正常删除、部分失效、全部失效、空购物车、未登录等场景再为每个场景补充边界值。这个能力在传统方法里几乎没有对应的实现路径。第二模型可以作为用例评审的“另一双眼睛”。我们经常让模型对比开发代码变更和已有用例集找出被遗漏的影响面。这个用法严格来说不是“生成”但它的价值甚至比“生成”更大因为它的输出是基于对代码变更的理解而不是凭空想象。第三模型可以自动生成测试数据构造逻辑。接口用例跑起来需要前置数据以前都是手工准备现在可以让模型根据字段约束生成数据构造脚本。这一块在我们项目里落地效果最稳定产出直接能被自动化框架消费。这也是为什么我觉得“基于大语言模型的测试用例生成”这个方向的本质不是单点替换“人写用例”这个动作而是把“理解需求—拆解场景—构造数据—生成断言—维护更新”这一整条链路全部重新做了一遍。1.3 什么样的团队适合引入这套方案AI生成测试用例不是银弹它有自己的适用边界。根据我这段时间的观察和实际经验下面这几类团队接入后收益最大接口数量多、迭代节奏快的团队。每轮迭代手工补充接口用例耗时最长AI生成可以把“从0到1”的时间压缩到原来的三分之一甚至更短。业务规则复杂、历史用例覆盖不足的团队。模型能从文档和代码中提取出人容易被忽略的边界场景对存量接口做一轮“查漏补缺”效果很显著。有自动化执行链路、但用例设计能力集中在个别资深同事身上的团队。把资深同事的用例设计思路沉淀成提示词模板相当于把个人经验变成团队资产。反过来如果你的团队连基础自动化都没有接口文档也不维护那我建议先把地基打好再上AI。模型输出质量上限取决于你输入给它的信息质量这个在后面会展开讲。2. 方案选型API调用还是本地部署模型怎么挑2.1 先想清楚边界条件再选模型聊选型之前先把一个最常见的误区说破不是越大的模型就越好也不是所有人都需要本地部署。选型之前先回答下面这些问题测试数据是否涉敏如果被测系统是金融、医疗、内部管理系统数据一旦出网就可能违规那基本只能选本地部署。用例生成频率有多高如果是每天持续集成触发每次生成上千条用例按Token计费的API成本可能会让你肉疼。团队有没有GPU资源本地部署不是下载个模型就行推理服务需要显存、CPU、内存的持续投入这个成本要算进项目的TCO里。需要生成的用例类型是什么纯接口用例、单元测试用例、端到端流程用例不同类型对模型代码能力的要求差别很大。我们把这几个问题写在立项文档第一页每次纠结“要不要换模型”时都先回顾一下。踩过一次坑才明白不先定边界后面大概率会反复折腾。2.2 模型选型参数规模、能力侧重和硬性限制说几个我们实际对比过的方案。如果数据允许出网直接调商用API是最省事的路径。商用模型的泛化能力、指令遵循能力普遍强于同参数量的开源模型尤其在处理长文档、复杂指令时差距明显。我们最开始用商用API跑接口文档生成用例效果就已经能用了。如果必须本地部署那模型选型就要看硬件条件了。我们团队实测过几款主流开源模型简单整理如下模型参数规模推荐显存代码能力中文理解部署难度Qwen2.5-Coder7B~32B16GB~64GB强强低DeepSeek-Coder6.7B~33B16GB~64GB很强中上中ChatGLM36B12GB~16GB中强低CodeLlama7B~34B16GB~64GB强弱中我们实际的测试结论是如果只能选一个7B级别的模型跑接口用例生成Qwen2.5-Coder-7B的性价比最好中文接口文档理解得比较准输出JSON格式的稳定性也够用。如果是复杂业务规则拆解最好上14B以上的模型效果差距还是比较明显的。有一个坑要特别提醒很多模型自称“代码能力强”但“写代码”和“设计测试用例”是两回事。用例生成需要模型理解被测系统的业务上下文、识别边界条件、组织测试步骤这跟“根据注释写一个排序函数”难度不在一个量级。所以选型时不要只看代码榜要拿自己的接口文档和业务需求去实测让模型真正生成一批用例再判断。2.3 本地部署一条可复现的落地路径考虑到不少团队有数据隔离要求我把我们本地部署的路径整理一下。我们用到的工具是Ollama和vLLM两个方案。Ollama胜在简单一条命令就能把模型拉起来适合小规模试跑vLLM的吞吐量更高适合持续集成场景下频繁调用。以vLLM部署Qwen2.5-Coder-14B为例我们的启动配置大概是这样的python -m vllm.entrypoints.openai.api_server \ --model Qwen/Qwen2.5-Coder-14B-Instruct \ --host 0.0.0.0 \ --port 8000 \ --tensor-parallel-size 2 \ --gpu-memory-utilization 0.9 \ --max-model-len 32768几个参数说下理由。tensor-parallel-size设成2是因为我们用了两张卡把模型切分到两张卡上推理gpu-memory-utilization设0.9是尽量把显存用满但留出10%给推理过程中的临时张量max-model-len设32768是因为我们要把接口文档和设备信息一起塞进上下文太短会截断。注意max-model-len不是越大越好。它直接决定推理时的显存占用设得过高会导致并发量上不去。先统计你实际要传入的最大文本长度再加20%~30%的余量是相对合理的做法。本地部署还有一个容易忽略的点模型加载后的第一次推理往往很慢业界叫“冷启动”。要保证持续集成任务不被它拖垮最好做一个常驻推理服务并在服务启动后发一次预热请求。2.4 商用API的接入技巧与成本控制如果不涉及数据合规问题商用API依然是效率最高的选择。我们早期就在API方式下快速验证了“提示词模板→用例生成→人工评审”的可行性。接入时有一个参数特別值得关注temperature。生成测试用例这个任务需要的是稳定性和准确性不是创造性。所以temperature要调低我们一般设置在0.2以下。你肯定不想让模型每次都生成风格迥异的用例那样后期维护成本很高。另外max_tokens要根据用例类型设一个合理上限接口用例通常不会太长设1024或2048就够太长不仅浪费钱还可能让模型胡编乱造。成本控制上我们的经验是不要每次生成都带上整份接口文档和全部业务背景可以把常用上下文做成固定前缀缓存起来。在API层面就是合理的system prompt设计将稳定的背景信息放在前面将每次变化的请求参数放在后面。这样既省Token又能保证输出的稳定性。3. 核心细节解析与实操要点3.1 一次完整的“接口文档→测试用例”要经历什么我拿一个典型的订单查询接口举例说明整个生成过程。接口文档大概是这样的{ name: 查询订单列表, method: GET, path: /api/order/list, params: { user_id: string, 必填, 用户ID, status: string, 可选, 枚举值pending/paid/shipped/completed/cancelled, page: integer, 可选, 默认1, 最小1, page_size: integer, 可选, 默认20, 最小1, 最大100 }, response: { code: integer, data: { list: array, total: integer } } }我们把这段文档和相关业务备注一起发给模型提示词里明确要求先按正常、边界、异常三类场景设计用例每个用例包含用例名称、前置条件、请求参数、预期结果覆盖每个参数的枚举值和边界值考虑参数之间的组合关系。模型输出我们稍作整理后得到了下面这份用例集用例名称前置条件请求参数预期结果正常查询全部订单用户已登录且有订单数据user_id1001, page1, page_size20code0, 返回订单列表按状态筛选已支付订单用户存在已支付订单user_id1001, statuspaid, page1, page_size20列表只包含paid订单status传非法值-user_id1001, statusabc返回参数校验错误page为0-user_id1001, page0, page_size20返回参数校验错误或自动修正为1page_size超出上限-user_id1001, page1, page_size101返回参数校验错误用户不存在user_id不存在user_id999999, page1, page_size20返回业务错误码或空列表这份结果看起来并不惊艳很多资深测试自己也能写出来。但关键在于生成时间从请求发出到拿到完整用例集大约只用了十几秒。同样的工作量手工大概要十五分钟到半小时。前者适合作为初稿再让测试工程师在上面补充业务特有的场景效率提升明显。3.2 提示词模板设计这事没有想象中那么简单提示词是整个方案里最值得花时间打磨的部分。我们迭代了七个版本才形成一套相对稳定的模板。核心设计思路是“角色设定 任务分解 输出约束 参考范式”。先说角色设定。我们会在提示词里告诉模型“你是一名有10年经验的测试架构师”一开始我觉得这句话像玄学但多轮对比后发现角色设定确实能影响输出文本的风格和质量。加了角色设定后模型更倾向于输出结构完整、考虑周全的用例而不是简单罗列。任务分解是最关键的部分。不要一上来就让模型“写测试用例”而是分三步走第一步让模型梳理被测需求中的功能点。列出“系统应该支持什么、不允许发生什么”。第二步针对每个功能点列出测试场景。区分正常流、备选流、异常流。第三步为每个场景补充具体用例数据和预期结果。输出约束方面明确要求用JSON格式返回字段固定为name、precondition、request、expected。这样后期解析入库非常方便。从第四版开始我们在提示词里加入了参考范式就是给模型看一个手工写好的优秀用例告诉它“请参考这个质量水平”。这个动作对输出质量的提升出乎意料地大。下面是一个简化后的提示词模板基本包含了我们沉淀下来的核心要素你是一位资深的测试架构师擅长接口测试用例设计。 请根据以下接口文档生成完整的接口测试用例。 接口文档 {document} 要求 1. 先分析接口的功能点、参数约束、业务规则 2. 分别设计正常场景、边界场景、异常场景的测试用例 3. 每个用例包含字段name, precondition, request, expected 4. 覆盖每个参数的类型、边界、枚举值以及参数之间的组合 5. 用JSON数组格式返回不要输出额外解释。 优秀用例参考 {example_case}3.3 生成结果如何校验别让模型“一本正经地胡说八道”大语言模型最让人头疼的问题就是幻觉。在我们这个场景里幻觉主要表现为三类编造接口字段。文档里没有的字段模型因为见过类似接口的写法自动给你补上了。编造业务规则。比如文档里没说过“未支付订单只能保留30分钟”模型也会按照行业习惯加进去。编造测试数据。生成一个不存在的用户ID、一个不符合规则的商品编码。针对这些问题我们的解决方案是“双层校验”。第一层是格式校验用JSON Schema校验模型输出是否符合约定的结构。第二层是语义校验把模型抽取到的接口字段、请求参数和原接口文档做比对字段不在文档里的直接标红提醒。注意模型输出里的预期结果不要直接当真。我们在实践中发现模型经常会把“应该返回200”写成“应该返回500”之类的低级错误。这一块最好交给测试人员做快速确认或者配合接口定义里的响应码规范做自动修正。3.4 让模型输出结构化数据JSON是首选我们要求模型输出JSON而不是自然语言描述原因很简单后续要做用例入库、去重、自动执行结构化数据是刚需。但模型输出JSON有一个经典问题——JSON格式不稳定偶尔会在末尾多出解释性文字或者字段名大小写不一致。解决方案有两个。一是效验后重试用JSON解析库解析失败时把错误信息拼进提示词让模型重新生成。实测下来这个办法能解决大约一半的格式问题。二是约束解码在vLLM这类推理框架里启用guided_json功能从生成阶段就限制输出必须符合指定的JSON Schema这个方案基本能彻底解决格式问题。from openai import OpenAI client OpenAI(base_urlhttp://localhost:8000/v1, api_keyEMPTY) resp client.chat.completions.create( modelQwen/Qwen2.5-Coder-14B-Instruct, response_format{type: json_object}, messages[ {role: system, content: system_prompt}, {role: user, content: user_content} ] )这串代码是我们在Python里调用本地推理服务的方式兼容OpenAI接口格式。只要后端启用了guided_jon或者response_format约束前端代码不需要做额外处理模型输出就能稳定是JSON。3.5 从单条生成到批量执行Pipeline才是真正的落地形态单次调用模型出用例其实很简单难的是把它做成一个在每次迭代中自动运行的服务。我们最终的形态是一个流水线分五个阶段准备阶段自动从Git仓库拉取接口定义文件和需求文档。这一步是自动化的基础如果文档不维护后面全完蛋。预处理阶段把接口文档切分成适合模型上下文长度的片段。不是把所有接口一股脑塞给模型而是按模块、按依赖关系分组避免模型上下文过载。生成阶段按批次调用模型每批处理一组相关接口附带统一的系统提示词和团队沉淀的参考用例。校验阶段格式校验、字段比对、用例去重、人工抽检。这一阶段会拦截大量模型幻觉产物。入库阶段把校验通过的用例转为测试平台的标准格式自动关联到对应接口上。这套流水线跑通后我们每周迭代的成本从“测试工程师花两天设计接口用例”降到了“AI生成人工评审一小时左右”。数字背后更重要的变化是人工从重复劳动里解放出来能去关注真正需要经验判断的复杂场景。4. 常见问题与排查技巧实录4.1 模型生成的用例“太泛”没有业务特色这是接入手两周后我们最头疼的问题。模型生成的用例确实覆盖面广但每个用例都是“请求发出去然后看返回值”完全没有业务判断力。比如订单超时关单这种场景模型是想不到的。后来我们发现问题出在输入信息的缺失。我们只给了接口文档没给业务规则说明而接口文档是描述“接口长什么样”不是描述“业务怎么运转”。改进方式是在提示词中加入业务背景和典型异常场景描述。比如“该接口需要校验用户是否有权限查看他人订单”“当订单状态为已取消时不允许再发起支付”这些规则只要是团队里已有的业务沉淀都可以喂给模型。另一个有效手段是注入历史缺陷数据。我们在系统提示词里加入“以下是从缺陷库中抽取的历史问题类型请在用例设计中重点回归这些场景”模型的用例设计立刻就有了针对性。4.2 同样的提示词输出质量时好时坏这种情况多半是采样参数没固定。我们在生产环境把temperature固定为0.1top_p固定为0.9输出稳定性明显提升。另外如果你用的是本地部署的开源模型不同版本的模型文件也会影响输出升级版本后建议先跑一轮冒烟用例对比输出质量再决定是否全量切换。4.3 上下文太长模型越到后面越“迷糊”接口文档动辄几万Token业务规则再一加很容易超过模型的上下文窗口。这时候模型会表现出两种症状要么忽略前面的指令只根据后面的内容回答要么直接截断输出不完整。我们的处理办法是“分段 摘要”。把大文档按接口模块切段每个模块独立生成用例同时把公共业务规则做成摘要作为固定前缀注入每个段落的提示词里。这比一次性把所有内容都塞给模型要稳定得多。4.4 怎么评估这套方案真的有效最后说一个最容易被人忽略的问题你怎么证明AI生成的用例比人工写得好我们内部建立了一套评估指标用例对接口参数的覆盖率统计所有参数是否都有合法、边界、非法三类用例。用例去重率AI生成的大量重复用例占比多少。人工评审通过率随机抽20%的生成结果给资深测试评审标记可用的比例。缺陷发现率新生成的用例跑完一轮后发现了多少存量测试没发现的缺陷。其中“缺陷发现率”是最有说服力的指标。我们在一次电商订单模块的回归中AI生成的用例发现了一个在极端组合参数下才会触发的金额计算错误。这个场景在原有测试设计里完全不存在。那一次之后团队对AI生成用例的态度从怀疑转成了“真香”。4.5 几个日常最容易忽略的小细节最后分享几个实操层面的细节每一条都是我们真实踩过的坑换来的第一不要直接在生产环境用未经微调的通用模型做高度专业化领域的用例生成。通用模型对金融、医疗等特定领域的业务规则理解有限先用提示词工程试跑实在不行再考虑微调。微调的成本远比你想象得高需要准备高质量的训练样本并持续维护。第二模型生成用例后一定要做权限与风险自查。比如用例中包含的账号、手机号、身份证号不要用真实数据要做脱敏处理。这是测试环境的安全红线自动生成的代码和用例尤其容易忽略。第三定期更新模型版本。语言模型的能力迭代很快我们每季度会做一次新模型版本的对比评估。每次升级前用固定的评估集跑一遍对比新旧版本在用例生成质量上的差异再决定要不要切换。第四保留人工审核环节至少在关键业务上保留。AI生成用例的定位是“初稿生成器”和“覆盖面补充器”它不是替代测试工程师的思考而是帮测试工程师省掉重复劳动的时间。我们最终的模式是“AI负责量大面广人负责疑难杂症”这也是目前性价比最高的搭配。5. 从单点工具到平台能力的演进路径5.1 第一阶段独立脚本阶段刚开始我们就写了一个简单的Python脚本读取接口文档、调用模型、输出JSON文件。它解决了“有没有”的问题但离“好不好用”差很远。这个阶段的局限在于只有一名测试开发在本地跑脚本结果无法共享也没法跟测试平台打通。5.2 第二阶段服务化阶段当团队里其他测试同事也想用时我们把它封装成了一个内部服务。提供Web界面测试人员可以上传接口文档、选择模板类型、点击生成。生成结果自动存入测试用例管理库。这个阶段的核心收获是把“能力”变成了“服务”团队协作的效率提升了很多。5.3 第三阶段流水线集成阶段再往后我们把它接入了持续集成流水线。每次代码合并后自动检测接口定义是否有变更有变更就自动触发用例生成和补充测试。这个阶段才真正实现了“让用例跟上代码迭代”的目标。代码变更了一个字段测试用例马上就能补上对应的校验用例再也不用等测试工程师忙完手头的活儿再去补用例了。这条演进路径给我们最大的启示是AI能力不是一次性接入就完事了它需要跟现有工程体系深度耦合才能把价值发挥到最大。单纯“用AI写几条用例”没有壁垒真正的壁垒在于把AI嵌入到研发流程里让它成为流程的一部分。6. 写在最后一个过来人的几句心里话做了这大半年的实践我最大的感受是大语言模型生成测试用例这件事技术本身不是瓶颈真正的瓶颈在于组织的输入质量。如果你的接口文档常年不更新需求描述含糊不清那再强的模型也生成不出好用例。反过来当你的文档、规则、历史数据都被整理得井井有条时模型生成用例的质量会远远超出你的预期。个人建议可以考虑从一个小项目试点开始找一个接口数量适中的模块跑通“文档输入—模型生成—人工审核—入库执行”的最小闭环再逐步扩展。不要一上来就想做一套完美的平台那是一步一步长出来的。我们当初就是从一段几十行的脚本开始的走到今天它已经变成了团队日常开发流程里一个不起眼但离不开的齿轮。如果让我只说一句经验那就是AI生成测试用例最大的价值不是“替代人”而是“把人的时间还给真正需要思考的地方”。