LLM智能化测试用例生成实践：从Prompt到RAG的完整指南-平芜编程栈

从一个过气考渣的角度看LLM智能化测试用例生成

说实话，我从来都不是一个考试型选手。当年读书的时候，最怕的就是老师划重点——不是怕划得太多背不完，而是怕划完之后我发现，自己根本不知道出题人会怎么从这些重点里“变出花样”来。工作之后做软件测试，我才发现这事儿换了个马甲又来了：给你一份PRD，让你设计测试用例，本质就是让你“替用户出考卷”，你得预判用户会怎么操作、系统会在哪里翻车、边界条件藏在哪个犄角旮旯。你说，这不是逼一个考渣去当出题老师吗？

所以当LLM智能生成测试用例这个概念火起来的时候，我第一反应其实是：这玩意儿是不是就是那个“传说中的出题AI”？后来自己折腾了一阵子，发现它确实能干活，而且干得比我预期的好不少，但也没少让我踩坑。这篇文章我不打算写那种“AI赋能质量保障”的空话，就从一个参加过无数次“考试”但总考砸的人的角度，聊聊LLM到底是怎么生成测试用例的、我在实操里是怎么让它出活的、以及那些文档里不会告诉你的坑。

1. 内容整体设计与思路拆解

1.1 传统测试用例设计为什么这么难

在聊LLM之前，得先弄明白传统测试用例设计难在哪儿。我见过太多测试新人拿到需求之后，憋了半天写出来的用例全是“正常输入+正常输出”，边界值、异常流、场景组合基本靠猜。这不是态度问题，是认知带宽问题。

人类设计测试用例，实际上是在做两件事：第一，理解业务逻辑，搞清楚这个功能到底要干什么；第二，基于这份理解去枚举可能出问题的场景。问题在于，业务逻辑通常藏在PRD的文字描述里，有歧义、有隐含假设，而场景枚举又依赖个人的经验积累。一个刚工作一年的测试，和干了五年的老测试，写出来的覆盖度可能差两三倍，这就是经验差。

等价类划分、边界值分析、判定表这些经典方法，说白了就是把“枚举场景”这件事尽量结构化。但方法归方法，真正执行起来还是要靠人去读需求、去理解业务。PRD写得烂一点，用例质量直接崩。

1.2 LLM凭什么能“当出题老师”

LLM能生成测试用例，底层逻辑其实和我们做题时“揣摩出题人意图”是差不多的。你在学校考试的时候，看到一道题，会去想：老师这道题考的是哪个知识点？是不是想挖个陷阱让我跳？会不会有个边界条件我没注意到？LLM干的事情本质上也是这个——它读了大量的软件工程文档、测试用例样本、技术问答之后，学会了测试用例的“常见套路”和“出题风格”。

比如你给它一段“用户登录”的需求描述，它不需要你教它什么叫“空密码”“密码错误”“账号锁定”，这些高频场景在它的训练语料里已经出现了成千上万次。它做的事情其实是把这些高频场景按照一定的概率分布“重新组合”起来，针对你输入的需求文本做适配。

这就是为什么LLM生成测试用例这件事能成立——它的“应试题库”实在太大了，大到很多老测试员脑子里的经验库在它面前都不够看。这不是说LLM能替代测试工程师，而是说它能帮你把“枚举场景”这个苦力活干完，你只需要做筛选和补充。

1.3 方案选型：怎么用它才不翻车

我对LLM生成测试用例的定位一直是“辅助工具”，不是“自动驾驶”。你想要的效果是：给它一份PRD，它吐出来一份覆盖度还不错的用例草稿，然后你在草稿基础上修修补补，而不是它直接生成一套可以直接提交给开发的完整用例。

为什么这么定位？因为LLM有一个非常突出的问题——幻觉，也就是一本正经地胡说八道。它可能生成一个看起来完全合理、但业务上根本不存在的操作步骤。你说这个用例能不能直接用？大部分能，但总有那么几条是需要你人工甄别的。用“辅助生成+人工审核”的模式，可以最大化发挥它的效率优势，同时把风险控制在可接受范围内。

从实操层面讲，我测试过几种不同的用法：直接把PRD丢给它让它自由生成、给它的Prompt里加上系统化的测试设计方法指令、让它先根据需求生成测试点再展开用例、以及用RAG把历史缺陷数据喂给它。不同方式出来的效果差别很大，这个后面细说。

2. 核心细节解析与实操要点

2.1 一次完整的LLM生成测试用例长什么样

我拿一个具体的例子来说。假设有这么一段PRD片段：

用户可以在订单列表页选择待支付订单，点击“取消订单”按钮，系统弹出确认框，用户确认后订单状态变为“已取消”，库存数量恢复，优惠券退还到用户账户。

如果你直接把这段文本丢给LLM让它生成测试用例，它通常会给你类似这样的东西：

用例编号	前置条件	操作步骤	预期结果
TC01	存在待支付订单	点击“取消订单”按钮，点击确认	订单状态变为“已取消”
TC02	存在待支付订单	点击“取消订单”按钮，点击取消	订单状态不变，仍为“待支付”
TC03	存在待支付订单，库存有限	点击“取消订单”按钮，点击确认	库存数量恢复
TC04	存在待支付订单，且使用了优惠券	点击“取消订单”按钮，点击确认	优惠券退还到用户账户
TC05	存在待支付订单	点击“取消订单”按钮，不进行任何操作	确认框消失，订单状态不变

这就是LLM的“基操”：基于文本语义直接推导用例。看起来还不错，对吧？但如果你就这么交上去，大概率会被开发或者测试负责人打回来，因为漏了太多关键场景——比如订单状态不是“待支付”而是“支付中”怎么办？订单已经超时自动取消还能不能手动取消？取消请求在网络异常时重复提交会不会出问题？并发场景下库存恢复会不会超卖？

这个问题本质上不是LLM不行，而是输入信息不够。PRD只写了主流程，LLM也没法凭空知道业务上还有哪些分支规则需要处理。所以真正好用的做法，是在喂给LLM的需求文档之外，再把一些隐含的规则明确告诉它。

2.2 提示词怎么写，效果天差地别

我试过很多种Prompt写法，踩过不少坑，最后沉淀下来一个相对稳定的套路。核心思路是让LLM按照“先分析、再列场景、最后转用例”的三步走流程来干活，而不是上来就直接给用例。

我常用的Prompt模板大致是这样的：

你是一名资深的软件测试工程师，擅长功能测试和异常场景测试。请根据以下需求描述，先进行测试分析，再输出测试用例。 【需求描述】 （这里粘贴PRD内容） 【补充业务规则】 （这里粘贴从PRD之外获取的补充规则，比如状态机变化、并发限制、权限规则等） 【输出要求】 1. 先输出测试分析，包括：功能点拆解、涉及的业务规则、潜在风险点。 2. 再输出测试用例，每条用例包含：用例编号、前置条件、测试步骤、预期结果、优先级。 3. 覆盖正常的业务流、异常的输入、边界条件、权限控制、数据一致性等场景。 4. 用例步骤要具体可操作，禁止出现“验证系统功能正常”这类模糊描述。

这个Prompt和“直接让它生成”最大的区别在于：它强制LLM先做“思考”再“输出”。实测下来，同样的需求，加了这一步之后生成的用例覆盖度能提升不少，尤其是异常场景，效果明显好很多。

注意，我不建议在这个Prompt里塞太多“方法论名词”——比如“请用等价类划分法、边界值分析法、判定表法设计用例”。LLM虽然在训练数据里见过这些词，但它并不真的懂怎么系统地运用它们，你硬塞反而可能让它把简单事情搞复杂。更好的方式是直接描述你要的用例属性，而不是方法名。

2.3 用“测试点”过渡是我最推荐的方式

在多次实验之后，我发现一个很好用的小技巧：让LLM先输出“测试点清单”，再人工筛选补充，最后再让它基于筛选后的测试点展开完整用例。

原因是这样：如果一步到位让它生成用例，LLM很容易在细节上过度发挥，生成大量重复度很高的用例（比如每个字段都来一遍同样的验证逻辑）。但先列测试点的话，LLM的输出更加精简，人工检查的成本很低，而且一旦发现漏了某个功能点，你只需要在那个测试点后面补一句就行。

举个例子，还是上面那个取消订单的需求。LLM生成的测试点可能包括：

正常取消订单流程
取消确认框的二次确认逻辑
取消后库存恢复
取消后优惠券退还
取消后订单列表状态刷新
已支付订单不可取消
网络异常时取消请求的处理

如果你发现漏了“订单已超过取消时限”这个场景，直接在测试点清单里加一条，然后让LLM基于“原始需求+补充后的测试点”生成完整用例，出来的结果就会精准很多，基本不会再有那种“看起来对但实际没用”的废用例。

这就是为什么我一直强调：LLM测试用例生成不是“一键出活”，而是一个“人机协作”的流程。人负责判断与补充，LLM负责展开与细化，各干各擅长的部分。

3. 实操过程与核心环节实现

3.1 我搭建的一套完整流程

前面讲了很多方法论，这块把我实际跑通的流程完整写出来，你照着搭就行。

整个流程分五步：需求预处理 → 规则补充 → 测试点生成与筛选 → 用例展开 → 质量复查。

第一步，需求预处理。把PRD里跟“当前要测的功能”相关的部分单独摘出来，不要一大篇全丢给LLM。我之前犯过这个错，一整份几十页的PRD直接丢进去，结果生成的用例大量集中在前面几个功能点，后面的基本被忽略——LLM也有“注意力上限”，太长的输入它会“糊弄”过去。所以先做裁剪，把要测的功能描述控制在几百字以内最好。

第二步，规则补充。这一步是最容易被忽略，但恰恰是决定用例质量的关键。PRD里不会写“订单取消时限是支付后30分钟内”“取消时如果库存已经被其他订单占用怎么处理”这类隐含规则，你需要把这些整理成一条条明确描述，接在需求文本后面。

第三步，测试点生成与筛选。用前面给的Prompt模板，先让LLM生成测试点清单。然后人工过一遍，删除重复的、补充遗漏的。这一步通常只需要几分钟。

第四步，用例展开。把“原始需求 + 补充规则 + 筛选后的测试点”一起作为输入，让LLM展开完整用例。这时候生成的用例已经很有针对性了，不会再乱发挥。

第五步，质量复查。把LLM生成的用例导入到用例管理工具里，抽几条关键的跟着执行一遍，看看步骤描述是否清晰、预期结果是否可判断。

3.2 一个完整示例：订单取消功能

为了让你能直观看到效果，我把上面那个“取消订单”的例子完整跑一遍。

需求描述（已裁剪）：

用户在订单列表页选择待支付订单，点击“取消订单”按钮，系统弹出确认框，用户确认后订单状态变为“已取消”，库存数量恢复，优惠券退还到用户账户。

补充规则（人工整理）：

仅“待支付”状态订单可取消，“已支付”“已发货”“已完成”“已取消”状态订单不可取消。
订单取消后不可恢复。
订单超过支付时限（30分钟）后系统自动取消，用户不可手动取消。
同一订单取消请求需做幂等处理，重复请求不产生重复取消操作。
取消订单时，如库存已被其他订单占用，则只恢复仍可用的库存数量。

LLM生成的测试点：

正常取消待支付订单
确认框中点击取消按钮
已支付订单无取消入口
超时自动取消的订单不能再手动取消
取消后库存恢复
取消后优惠券退还
重复点击取消按钮只生效一次
取消请求失败时的提示信息

人工筛选后，补了一个测试点：

取消时库存已被其他订单占用

然后让LLM基于这些展开，最终生成的用例里就包含了很多直接给PRD看不出来的细节场景。比如它会给“重复点击取消按钮”的用例设计出前置条件和精确步骤：“在网络延迟环境下，快速双击取消按钮，验证系统只处理一次取消操作”，这个角度就已经接近一个有经验测试员能想到的边界场景了。

3.3 工具链选型：从豆包到开源方案

很多人问我用什么工具跑。坦率说，测试用例生成这件事对模型本身的“考分”要求没那么高，主流的大模型都能干，但体验有差别。

国内的话，我用过豆包，也用过通义千问，两者都还不错，尤其是豆包，响应快、免费额度够用、对中文需求的理解也到位，日常做用例生成完全够用。和DeepSeek、ChatGPT做过对比，在测试用例生成这个场景下，差距没有想象中那么大，主要区别在于复杂业务逻辑的推理能力——当需求文本里有大量业务分支时，ChatGPT和Claude这类模型的生成质量会更稳定一些，对补充规则的遵循也更严格。

如果你对数据安全有要求，不能把需求文档传到外部平台，那就得考虑私有化部署。在这个场景下，我建议关注的是模型对长文本的理解能力和指令遵循能力，而不是参数大小。实测下来，7B到14B量级的模型就能生成不错的测试用例，关键是你在Prompt上花的功夫。我试过用Qwen2.5 7B模型跑同样的流程，用前面那个三步走Prompt，生成的用例可参考度能达到外部大模型的七八成，这在数据敏感的环境里已经很能打了。

还有一个经常被问的问题：要不要为了生成测试用例去学Prompt engineering？我的建议是不用专门学，但得知道几个基本技巧：明确角色、明确任务、明确输出格式、给示例（few-shot）。这些够用了。再深入的去研究什么思维链、角色扮演方法论，在这件事上收益不大。

4. Agent、Embedding与垂域化，到底要不要上

4.1 什么时候值得上Agent

“LLM Agent”这几年特别火，很多做技术的人一上来就想搭一套Agent让模型自动读需求、自动生成用例、自动提交到用例管理平台。我的看法是：先别急着上，搞清楚你要解决的问题是什么。

单次调用LLM和Agent工作流的区别在于：Agent是一个“多轮决策”系统，它能根据当前结果决定下一步做什么。在测试用例生成这个场景里，Agent真正有价值的点是“多步推理”——比如先读PRD提取业务规则，再根据规则列出测试点，然后针对每个测试点生成用例，最后自己检查一遍覆盖度，把遗漏的地方补上。

这个流程用单次调用也能做（就是前面那个三步走Prompt），但Agent能做到“自动迭代”：发现自己漏了场景就自己补，不用你在中间手动介入。不过代价是复杂度和成本都上去了，而且Agent链路越长，出错的可能性也越大——某一步模型理解偏了，后面全跟着偏。

我的建议是：如果你们的需求文本格式比较统一、业务规则相对稳定，先用单次调用的方式跑通，敏捷又够用。如果需求文本五花八门、业务规则特别碎片化，需要系统性地从多个文档里抽取信息再组合成测试依据，这时候上Agent就值得了。

4.2 Embedding和RAG在这个场景怎么用

Embedding和RAG是另一组被提到很多的名词。其实简单理解，Embedding就是把文本变成一串数字向量，让计算机能算“两个文本像不像”；RAG则是把知识库里的内容检索出来，塞进Prompt里让模型参考。

在测试用例生成这个场景里，RAG最有用的地方是：把你的历史缺陷报告、历史测试用例、业务规则文档做成知识库，生成用例之前先检索相关的历史缺陷和已有用例，让LLM参考着生成。

我试过一个场景：把某个模块过去半年收集到的线上缺陷（描述+根因）做成向量库，生成测试用例时，Prompt里会附带和当前需求最相关的几条历史缺陷。结果生成的用例里，有不少直接对标了历史缺陷的复现路径。这个效果是单纯靠提示词很难达成的，因为那些缺陷的具体复现细节根本不在模型本身的训练数据里，只有你才有。

不过RAG的坑也很明显：知识库的质量决定一切。如果你的历史用例本身写得就很烂，缺陷记录也含糊，那检索出来的东西反而会误导模型。所以做RAG之前，先花时间清洗知识库数据，宁缺毋滥。

4.3 垂域化：数据准备才是大头

垂域LLM是另一个所有AI热词里被误解最多的概念。很多人一听“垂域大模型”就觉得要训练一个自己的模型，其实在测试用例生成这个场景下，你真正需要的是“垂域数据”，模型本身用通用模型就行。

所谓垂域数据，就是你们公司特定业务场景下的需求文档格式、常见业务流程、专用术语定义、历史缺陷模式。这些怎么准备？我建议分几类来做：

第一类，术语表。把你们业务里特有的词汇整理出来，比如“待支付”“核销”“分账”这些词在你们业务流程里的准确含义。第二类，业务规则库。把分散在各处（PRD、产品白皮书、开会纪要）的业务规则统一收拢，按功能模块归类。第三类，历史用例和缺陷样本。按功能模块分好，标注清楚对应的业务场景。

这些数据准备的活不需要你做AI相关的事情，纯粹是业务梳理。但恰恰是这部分工作，决定了你的LLM测试用例生成方案能不能落地。我见过太多团队上来就买GPU调模型，折腾半天效果不好，最后发现是连自己的业务规则都没梳理清楚，模型再强也白搭。

5. 常见问题与排查技巧实录

5.1 模型“一本正经胡说八道”怎么治

这是用LLM生成测试用例时最让人头疼的问题。表现形式各不相同：编造需求里根本不存在的功能、虚构一个业务规则、或者在预期结果里写出不可能发生的状态变化。

我总结过这个问题的几种常见原因和对应解法：

第一，输入需求太模糊。LLM没法理解的地方就会“脑补”。解决方法是把输入文本写清楚，尤其是业务规则部分，能列多细列多细。

第二，Prompt里没限制它“只能基于输入内容生成”。这一点很关键。如果你不明确写“禁止添加需求中不存在的功能和规则”，模型会倾向于发挥。加一句“所有用例必须基于给定需求描述和业务规则，不得自行假设业务逻辑”能大幅减少幻觉。

第三，业务规则本身存在冲突。有时候PRD里写“用户可取消订单”，但另一段又写“取消功能仅对会员开放”，这种矛盾LLM是能发现的，但它不会主动告诉你，而是会选一个它认为合理的来生成。所以人工在“测试点筛选”那一步就要把关——如果LLM生成的测试点和你对业务的理解有冲突，大概率是需求本身有问题，这时候要先澄清需求，而不是硬生成用例。

5.2 用例重复、格式不稳定、优先级乱标

这三个问题属于“生成质量”问题，虽然不致命，但会让你用起来很抓狂。

用例重复的根源通常是需求文本里对同一功能有多处描述，或者LLM在生成时把自己的思考过程重复使用了。解法是限制输出篇幅，Prompt里明确“每个测试点生成1-2条用例”，如果不限制，LLM有时候会给一个场景生成五六条几乎一模一样的用例，看得人血压升高。

格式不稳定体现在：有时它给你Markdown表格，有时是列表，有时又给你JSON。这其实是你Prompt里输出格式描述不够具体导致的。我的做法是在Prompt里给一个用例模板示例，每个字段的含义写清楚，比如“优先级：P0-阻塞/ P1-核心/ P2-一般/ P3-建议”。给了示例之后，格式基本就稳定了。

优先级乱标的问题比较有意思。LLM给用例标优先级时，往往倾向于把正常流程标成P0，异常流程标成P1。这在很多场景下其实是反的——线上影响最大的往往是异常场景（比如支付重复扣款、库存超卖），而正常流程反而大概率不会出问题。解法是在Prompt里说明“优先级认定标准：用户影响范围大、发生概率高、涉及资金或数据安全的功能点优先标P0”，让LLM按这个规则重新评估。

5.3 效率和成本怎么平衡

这是老板们最关心的问题。用LLM生成测试用例到底能省多少时间？成本划不划算？我说一下自己的实测数据：

在一个中等复杂度的功能（大概30-50个功能点的Web模块）上，纯人工设计用例的时间大约是1到2个工作日（看测试员经验）。用我前面那个流程，把PRD处理好、补充规则、生成测试点、筛选、展开用例，我大概需要1到2个小时，最后生成出来的用例在此基础上再花半小时人工“精修”。整体算下来，效率提升至少是50%。

成本方面，用豆包这类国内API，单次生成几千字的响应也就几分钱，可以忽略不计。就算用ChatGPT或者Claude，一次生成50条用例的成本大概在几毛到几块钱之间，相比节省的人力成本，非常划算。

不过也要提醒一句：这里有个隐性成本是“人工审核”。LLM生成的用例不能无脑用，该覆盖的场景虽然覆盖了，但用例里可能藏着逻辑漏洞。我的经验是，审核一份50条用例的生成结果，大概需要20到30分钟，比从零开始设计花的时间少得多，但绝不是零成本。把这个时间算进去，才是真实的投入产出比。

6. 一些更深入的思考

写到这里，我想再聊聊一些技术之外的东西。

很多人担心LLM会取代测试工程师，我在实际使用之后的感受是：短期内不可能，长期看也不会。原因很简单——未来业务系统的复杂度不会降低，业务规则的管理比写用例本身更值得投入。当你需要把一份充满歧义的PRD转化成可执行的测试用例时，最难的其实不是“枚举场景”，而是“理解业务”。LLM能做的是帮你把“枚举场景”这个环节自动化，但“理解业务”这件事，依然需要人来主导。

不过另一方面，我也确实觉得测试这个岗位的画像会变。以前测试工程师的核心竞争力是“经验多多益善”——见过的bug越多，设计测试用例时越能想到别人想不到的场景。但LLM出现之后，“经验”被拉平了，一个用不好LLM的十年老兵，在用例覆盖度上未必比一个会用LLM的新人强多少。

真正拉开差距的变成了：你有没有能力把业务知识结构化、能不能设计出好的Prompt让模型发挥出水平、能不能判断模型输出中哪些可信哪些需要验证。这些能力，其实比“多写几年用例”更值钱。

这让我一个过气考渣挺感慨的：以前考试考的是你脑子里装了多少东西，现在这波技术变革，考的是你能不能在外部工具的辅助下把事情做好。对测试这个行业来说，这句话同样成立。