这两年做测试开发，最常被问的一个问题就是：大语言模型到底能不能把测试用例真正写出来、写好？早先大家用模板、用规则引擎，写了大量看似自动化的东西，到头来还是靠人肉补用例。直到大模型进入项目，我发现它确实能把测试用例生成这件事往前推一大步，但它不是简单“把需求粘贴进对话框”就能搞定。这篇文章就是来聊一聊，我在实际项目里怎么把大语言模型用起来，从需求拆解、上下文构造、提示词设计，到最终生成可执行的 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, model="qwen2.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_path="test_generated.py"): with open(output_path, "w", encoding="utf-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 元素定位成本极高。视觉模型给出的步骤可以作为自动化脚本的初稿，人工只需要按它的描述去补充具体的选择器即可。
当然，视觉模型的输出稳定性目前比纯文本模型还是差一些，它对截图中元素位置的判断偶尔有偏差。我的建议是把它定位为“辅助分析”而不是“全自动生成”，让它在设计用例阶段提供思路，最终的可执行脚本还是交给有经验的测试工程师确认。
最后说点实在的
这套方案我已经在至少三个不同类型的项目里完整跑过，有纯后端接口项目，也有带复杂审批流的中台系统。最直观的感受是，大语言模型做测试用例生成，真正改变的不是“替代人的思考”，而是“逼你把需求想清楚”。你会发现，为了让模型生成出好用例，你必须先把业务规则罗列清楚，把接口约束整理规范，把历史用例归纳成体系。这个过程本身就是一种很好的测试资产沉淀。
如果你第一次尝试，我的建议是从一个中小型模块入手，不要一上来就铺全量。先跑通“需求输入-提示词-模型生成-人工审核-执行”这个最小闭环，拿到真实效果和团队反馈，再逐步扩展到更多业务。我自己也是一步一步从“玩一玩”走到“正式链路”的，这条路值得走。
