这两年做测试开发最常被问的一个问题就是大语言模型到底能不能把测试用例真正写出来、写好早先大家用模板、用规则引擎写了大量看似自动化的东西到头来还是靠人肉补用例。直到大模型进入项目我发现它确实能把测试用例生成这件事往前推一大步但它不是简单“把需求粘贴进对话框”就能搞定。这篇文章就是来聊一聊我在实际项目里怎么把大语言模型用起来从需求拆解、上下文构造、提示词设计到最终生成可执行的 pytest 用例整条链路怎么做通以及这中间踩过的坑。如果你正在负责接口自动化、业务测试设计或者团队刚想引入 AI 生成测试用例却不知道怎么落地这篇文章应该能给你一个可以直接照着搭建的方案。我会把技术选型的思考、具体的提示词模板、参数怎么调、常见问题怎么排查全部摊开来讲。1. 内容整体设计与思路拆解1.1 为什么传统“自动化生成用例”走到了头先说一个背景。早几年我们做测试用例自动生成的方案基本逃不过三类模板填充、规则匹配、录制回放。模板填充适合结构非常固定的场景比如用户注册、登录、下单这种字段可枚举的接口写一套模板往里填参数就行。但一旦业务规则复杂一点比如“满减叠加优惠券且会员等级不同折扣不同”模板就塌了。规则匹配稍微聪明一些能根据字段名推测类型、边界值但本质还是靠人把规则梳理成配置文件这个前置成本极高而且规则之间容易冲突。录制回放的好处是几乎不用写代码坏处是录到的只是历史行为你永远不知道还有哪些场景没被人触发过。对测试来说未知场景才是出 bug 最多的地方录制回放天然解决不了这个问题。这三类方案的一个共同缺陷是它们都“不懂业务”。它们不知道“支付成功后不应该再允许重复退款”是什么意思。大语言模型完全不一样它通过预训练掌握了海量知识能理解自然语言描述的业务规则能从一个需求描述里联想到边界条件、异常路径、权限校验这些维度。这是测试用例生成第一次从“工具化”走向了“智能化”。1.2 大模型生成测试用例的完整链路设计我在项目里落地时没有采用“一个提示词一把梭”的粗暴方式而是把整个流程拆成五段需求输入标准化。把原始需求文档、接口定义、UI 说明整理成模型容易理解的格式。上下文构造。把相关代码、历史用例、业务规则通过检索的方式注入到提示词里。模型推理生成。通过本地部署或 API 调用大语言模型产出结构化测试用例。结果解析与校验。把模型输出的文本解析成用例对象做字段校验和格式清洗。用例转换与回灌。转换成 pytest、JMeter 等工具能直接执行的文件并回填到用例管理平台。这五段缺一不可。很多团队做了第一步和第三步就以为大功告成了结果模型输出的用例要么格式乱七八糟要么字段缺失根本跑不起来。问题就出在缺了解析校验和执行转换这两环。1.3 方案选型背后的核心取舍大模型生成测试用例有个绕不开的问题生成结果的正确率达不到 100%。我实测下来稳定在 85% 到 95% 之间剩余部分需要人工修正。这就带来一个决策——到底追求“全自动”还是“半自动”我的建议是一步到位追求全自动是伪需求。你想象一下几千条用例里混着 5% 的错误比如断言写反了、参数类型写错了、前置条件漏了直接扔给执行环境跑报错率会非常高排查成本反而比人工写更大。所以我在设计链路时刻意保留了“人工审核节点”模型的定位是“以秒级速度生成 80 分的初稿”测试工程师负责把初稿提升到 95 分。这不是退步这是务实。真正用过模型生成用例的人应该都有体感从零到 80 分模型可能只要 10 秒钟从 80 到 95 分人工可能只要 5 分钟。而如果你纯手写从零到 95 分至少要 40 分钟。这个投入产出比是完全值得的。2. 工具选型解析商业 API 与本地部署怎么选2.1 先别急明确你的数据能不能出得去做选型之前第一件事不是比模型效果而是弄清楚你的用例数据和被测系统信息能不能传给第三方。不少公司的接口报文、业务规则涉及敏感信息这类项目直接调用商业 API 就会遇到合规问题。我能给的建议很明确如果测试数据能脱敏并且业务对响应速度不敏感商业 API 是最省事的选择如果数据敏感或者你在离线环境做测试那就老老实实走本地部署。从成本角度算一笔账商业 API 按 token 计费如果团队日常生成用例的量不大比如每天几千条一个月的费用可能只是几百块性价比很高。但量大之后成本会线性上涨到这个时候本地部署的优势就出来了。2.2 本地部署怎么选开源模型本地部署的核心问题是选什么模型。目前中文场景下我试过几类方案给出我的主观判断供你参考模型参数量档位测试用例生成效果部署成本备注ChatGLM 系列6B-32B中规中矩中文理解不错低到中老牌国产开源生态成熟Qwen 系列1.8B-72B整体能力强工具调用优秀低到中我目前主力用 Qwen性价比高DeepSeek 系列7B-67B代码类任务表现突出中适合需要较多代码级生成的场景Yi 系列6B-34B中文对话自然低到中通用能力强代码稍弱如果是第一次尝试建议从 Qwen2.5 7B 或 14B 这个规格起步。7B 模型量化之后显存占用可能不到 8G普通办公显卡甚至纯 CPU 慢一点也能跑。14B 效果明显好于 7B但显存需求上了一个台阶。我的经验是如果机器有条件优先上 14B如果只是做验证性项目7B 足够用。2.3 模型下载下来之后是什么怎么跑起来很多刚开始接触本地部署的测试同学会问模型下载下来是个什么东西怎么像软件一样打开解释一下大语言模型的下载产物通常是权重文件常见格式有 GGUF、safetensors 等。它不是 exe 程序不能双击运行必须由推理引擎加载。推理引擎可以理解为模型的运行环境最常用的是 llama.cpp 封装出来的 Ollama还有 vLLM、SGLang 等。以 Ollama 为例核心流程非常短在命令行执行两步就能完成部署# 拉取模型到本地 ollama pull qwen2.5:14b # 启动模型服务默认监听 11434 端口 ollama serve模型跑起来之后你会得到一个标准 HTTP 接口直接在代码里请求它就行这也是后续做测试用例生成的关键接入点。想看得见摸得着的图形操作界面可以再搭配一个叫 Open WebUI 的开源项目它能给你一个类似聊天网页的界面方便你先手动体验一下模型效果。这个组合拳里的“模型服务地址”在代码里就是http://127.0.0.1:11434后面跟不同的 API 路径来调用生成能力。了解这些底层细节之后后面写脚本就不会一头雾水。3. 提示词设计与上下文构造从“能生成”到“生成对”3.1 一个提示词打天下的时代已经过了有人觉得大模型生成测试用例不就是把需求文档扔进去说一句“给我生成测试用例”吗我一开始也这么干过结果生成出来的用例非常“正确”但十分没用。比如我说“测试用户登录功能”它给我返回 20 条用例全是“输入正确用户名密码登录成功”“输入错误密码登录失败”这种最基础的组合。问题出在大模型根本不知道你的登录有哪些特殊规则、验证码怎么处理、有没有二次校验、账号锁定策略是什么、不同类型的用户权限有什么区别。解决方案其实也不复杂不要只给一句话而是给模型一个结构化的“任务包”。任务包应该包含业务背景、接口定义、业务规则、角色权限、约束条件、输出格式要求。模型拿到这些细节后生成的用例质量会有一个质的飞跃。3.2 三段式提示词模板我长期使用的模板可以概括为三段式身份与背景任务要求输出约束。第一段明确角色定位。比如“你是一名具有 8 年经验的测试架构师擅长接口测试和业务场景分析”。这一步不要觉得虚实测表明角色设定能显著影响模型的输出风格和严谨程度。第二段是任务要求。要把需求原文塞进去并且明确要求模型从哪些维度思考。我会明确要求覆盖正常流程、边界值、异常场景、权限校验、数据状态流转等几个角度这样模型的思路会更系统。第三段是输出约束。我会强制要求模型按 JSON 格式输出并且给出字段定义。JSON 的好处是方便程序解析能直接进入后续的校验、转换环节。一个简化版模板长这样你是一名资深测试架构师。请根据以下需求生成测试用例。 需求描述 {这里放需求文档} 接口信息 {这里放接口定义} 业务规则 - 用户状态为禁用时不允许登录 - 连续输错 5 次密码账号锁定 30 分钟 - 登录成功后返回 token有效期为 2 小时 输出要求 以 JSON 数组输出每个元素包含以下字段 - name: 用例名称 - module: 所属模块 - priority: P0/P1/P2 - preconditions: 前置条件 - steps: 操作步骤列表 - expected: 预期结果 请从正常路径、异常路径、边界值、权限校验四个方面设计用例。这个模板看起来简单但实战效果比“给我生成测试用例”好十倍。你在实际使用时需要根据项目的接口文档、业务说明把括号里的内容填满。3.3 上下文不够用让模型“现查”历史用例还有一个常见问题是团队已经积累了上万条历史测试用例这些用例里藏着很多业务规则的隐含前提。模型并不知道这些所以生成的用例可能和已有用例重复。要解决这个问题最直接的方式是让模型参考历史用例。但历史用例可能非常多全部塞进提示词会导致上下文超限。这时候就要做两层处理。第一层做相似度检索。把每一条历史用例做向量化存到向量数据库里。当新需求来的时候根据需求描述的向量去检索最相近的 20 条历史用例把它们的精简摘要加入到提示词中让模型参考。第二层做去重后置。模型生成完用例以后再用文本相似度算法和数据库里的既有用例做比对相似度超过阈值的自动标记为重复由人工决定是否合并。这样一套组合下来生成的用例有效性和复用率都明显提升。这也是整个方案里投入产出比最高的一个优化点。3.4 为什么一定要强调“结构化输出”很多只用对话界面玩过模型的朋友可能没有体会当你把模型接入工程链路会发现自己面对的最大问题不是“模型不懂”而是“模型输出不听话”。比如你让它输出 JSON它可能在 JSON 前后加了 json 标签你让它输出中文字段名它时不时给我冒出一个英文注释你让它只输出 5 条用例它兴致上来写了 20 条。这些情况不是模型“笨”是因为对话模型天然倾向于自由表达而工程链路需要严格契约。解决办法是两条腿走路。一方面在提示词里把输出格式写到非常细的程度我给你看的模板只是简化版实际我会把 JSON Schema 直接贴进去明确每个字段的类型、是否必填、允许值。另一方面在代码里写强校验解析失败就自动重试一次重试时把失败原因告诉模型让它修正输出。这种“校验-反馈-重试”机制能把最终解析成功率从 70% 拉到 98% 以上。4. 实操过程与核心环节实现4.1 实战案例用户登录接口的用例生成为了让你看得更具体我拿一个用户登录接口来串一遍完整实操过程。假设接口文档是这么写的请求路径POST /api/login请求参数username字符串必填、password字符串必填、captcha字符串必填业务规则用户名或密码错误时返回错误码 1001验证码错误时返回错误码 1002账号被锁定返回错误码 1003连续五次密码错误锁定账号 30 分钟。需求文档里额外有一段描述“用户在输入框失去焦点时前端会先校验验证码是否正确不正确则不会发起登录请求。但后端接口仍然要做兜底校验。”这个场景看起来很常规但如果只凭直觉设计用例你大概率会漏掉几个关键场景。比如“后端是否真的做了验证码兜底校验”“账号锁定后 29 分钟再尝试登录是否仍被拒绝”“第五次密码错误时锁定是否立即生效”和“用户名不存在与密码错误返回是否一致”。模型能不能想到这些完全看你给它什么信息。如果把上面这些规则全部喂给它它就能生成覆盖得很好的用例集。4.2 核心代码调用模型、解析结果、转换 pytest下面这段代码是我项目里的精简版实现了调用本地 Ollama 服务、解析模型输出为用例对象、再转换为 pytest 文件三个功能。import json import requests import pytest def call_llm_generate_cases(requirement_text, rules, modelqwen2.5:14b): prompt f 你是一名资深测试架构师请根据以下需求设计接口测试用例。 需求描述 {requirement_text} 接口与规则 {rules} 输出要求仅输出 JSON 数组不要输出其他解释文字。每个元素包含 name, module, priority, preconditions, steps, expected 六个字段。 response requests.post( http://127.0.0.1:11434/api/chat, json{ model: model, messages: [{role: user, content: prompt}], stream: False, options: {temperature: 0.3, top_p: 0.8}, }, ) content response.json()[message][content] return json.loads(content) def generate_pytest_file(cases, output_pathtest_generated.py): with open(output_path, w, encodingutf-8) as f: f.write(import pytest\nimport requests\n\n) for case in cases: f.write(f\ndef test_{case[name]}():\n) f.write(f \\\{case[module]} - {case[expected]}\\\\n) f.write( response requests.post(/api/login)\n) f.write(f assert response.status_code 200\n) print(f生成完成{output_path}) if __name__ __main__: requirement 登录接口 POST /api/login 参数username 必填password 必填captcha 必填 rules - 用户名或密码错误返回错误码 1001 - 验证码错误返回错误码 1002 - 账号被锁定返回错误码 1003 - 连续输错 5 次密码锁定账号 30 分钟 testcases call_llm_generate_cases(requirement, rules) for case in testcases: print(case) generate_pytest_file(testcases)这段代码只是个骨架核心价值在于给你一个可以跑通的模板。真正接项目时你还需要把接口定义、认证方式、测试数据准备这些东西全部注入进去。4.3 参数选择背后的依据temperature、top_p、max_tokens大模型生成不是完全随机的它有几个核心参数直接决定输出质量我把最常用的三个参数说明白。第一个是 temperature中文叫温度控制生成结果的随机性。数值越低输出越稳定、越保守。测试用例生成场景不需要创造性发散我一般设置在 0.2 到 0.4 之间。如果设成 0.9模型可能给你生成很多从未出现的花样场景但这对于测试用例来说不一定是好事容易出现不合理的用例。第二个是 top_p和 temperature 功能类似也是控制随机性的。我习惯固定设 0.8。这两个参数可以一起理解成“设置了多少创意的上限”。你在生成用例时要的是稳定可靠不是脑洞大开所以参数要往低里调。第三个是 max_tokens控制模型最多生成多少个 token。这里有一个容易踩的坑如果你请求的是测试用例生成期望输出很长但 max_tokens 设短了输出会被截断最后的 JSON 很可能不完整。我建议根据你填的需求文本长度来估算输出长度。通常一个包含 10 条用例的 JSON需要 2000 到 3000 个 token。保守起见设置成 4096 会比较稳。4.4 用“模型自己提问题”来补全需求细节我在实操中还发现一个很好用的小技巧在生成用例之前先让模型阅读需求列出“为了设计完整测试用例你需要补充了解哪些信息”。这相当于让模型先做一轮需求澄清。模型通常会问出一些你没想到的问题例如“验证码的有效期是多久”“连续五次失败指的是同一个用户还是同一个 IP”“账号锁定后通过修改密码能否立即解锁”这些问题由测试工程师去和产品经理确认再把答案反馈给模型模型生成的用例就会更精准。这个技巧的额外价值是它其实是在帮团队做需求评审。很多时候开发文档写得不完整测试人员看不出来但模型基于训练数据里的常识能敏锐地发现缺失项。5. 常见问题与排查技巧实录5.1 高频问题速查表我整理了一份很多人都会碰到的问题清单连同排查思路一起放在这里现象常见原因解决方案模型输出不是合法 JSON提示词格式约束不够、模型被截断在提示词中贴 JSON Schema调大 max_tokens增加解析失败自动重试生成的用例全是常见场景缺少边界值需求信息不足、业务规则没给全补充业务规则让模型先列“需要补充的问题”再生成用例重复度过高缺乏历史用例检索去重机制接入向量检索生成后用相似度算法去重模型本地部署生成速度太慢模型过大、未使用 GPU 加速、并发不足换更小量化模型开启 Ollama 并发参数考虑 vLLM 做高并发推理断言类型单一全是 status_code提示词没有强调断言维度在提示词中增加“断言要覆盖状态码、业务码、关键字段值、数据库状态”上下文窗口超限需求文档太长先做文本摘要只注入相关片段用 RAG 方式检索关键段落5.2 一个“翻车”案例的完整复盘我想讲一个实际遇到的案例。之前有一个订单状态流转的模块需求文档非常长有四十多页。我第一次直接全文塞给模型很快就触发了上下文超限报错了。于是我把文档丢给模型做摘要再把摘要配合接口定义一起输入生成的用例质量还行但缺少状态流转的非法路径。排查之后发现问题出在摘要环节模型在做摘要时“订单已取消后不允许再次支付”“已收货订单不允许申请退款”这类关键约束没有被摘进去。因为这些句子在原文里是分散的、不起眼的模型默认它们不是重点。这个问题的解法是做摘要时增加一个指令提取文档中所有涉及“不允许”“无法”“必须”“只有...才...”这类强约束的句子单独列成一节再和摘要一起传给生成用例的模型。修正之后非法路径用例的覆盖率有了很明显的提升。这个经历让我意识到上下文构造不是简单“喂得越多越好”而是要有针对性地提取关键信息。尤其是拒绝性、条件性、时序性的规则是测试用例生成的重中之重。5.3 没有接口文档的时候怎么办依赖接口文档是很多人卡住的点。现实是很多项目的接口文档更新不及时甚至根本没有。我常用的替代方案是抓包获取真实请求。把接口的请求参数、响应体、状态码收集起来整理成结构化描述再配合线上日志里记录的业务关键字段变化形成一份“临时接口文档”。还有一步容易被忽略去看前后端联调时产生的 mock 数据和异常日志。这些里往往包含了接口对边界条件的真实处理逻辑比一份过期的文档更有价值。把这些信息整理成文本注入给模型后模型就能基于真实请求结构生成用例。这个路径虽然前置准备时间增加了一些但比干等文档要强得多。5.4 视觉大语言模型在 UI 测试用例生成上的尝试接口测试跑通之后我又尝试把大语言模型用到 UI 测试领域这次用的是视觉大语言模型。你给它一张页面截图它能识别出页面上的按钮、输入框、表单、提示信息的位置和内容。我的用法是截取被测页面截图配合一段需求文字描述让视觉大语言模型分析页面元素并生成基于 UI 操作路径的测试步骤。它不只是识别元素名称还能推断操作顺序先填写哪个字段、再点击哪个按钮、最后在哪个位置检查什么结果。这个能力对老旧系统的回归测试帮助很大因为很多老系统没有完整的自动化脚本人工维护 UI 元素定位成本极高。视觉模型给出的步骤可以作为自动化脚本的初稿人工只需要按它的描述去补充具体的选择器即可。当然视觉模型的输出稳定性目前比纯文本模型还是差一些它对截图中元素位置的判断偶尔有偏差。我的建议是把它定位为“辅助分析”而不是“全自动生成”让它在设计用例阶段提供思路最终的可执行脚本还是交给有经验的测试工程师确认。最后说点实在的这套方案我已经在至少三个不同类型的项目里完整跑过有纯后端接口项目也有带复杂审批流的中台系统。最直观的感受是大语言模型做测试用例生成真正改变的不是“替代人的思考”而是“逼你把需求想清楚”。你会发现为了让模型生成出好用例你必须先把业务规则罗列清楚把接口约束整理规范把历史用例归纳成体系。这个过程本身就是一种很好的测试资产沉淀。如果你第一次尝试我的建议是从一个中小型模块入手不要一上来就铺全量。先跑通“需求输入-提示词-模型生成-人工审核-执行”这个最小闭环拿到真实效果和团队反馈再逐步扩展到更多业务。我自己也是一步一步从“玩一玩”走到“正式链路”的这条路值得走。