如何用提示词让LLM生成真正可用的测试用例

让大语言模型"为登录页写测试用例"，你会得到一份看起来漂亮、实际上几乎没测到任何东西的输出。内容流畅、格式规范，但全是通用场景：有效登录、错误密码、空字段。任何初级测试人员两分钟就能列出来。

问题不在模型，而在提示词。LLM 只能基于你提供的信息工作，而"为登录写测试用例"这句话没有告诉它任何关于你的产品、你的规则、或者什么算失败的信息。

据 CloudQA 博客分享的实践指南，一套有效的测试用例生成提示词需要四个核心要素，以及五类可直接套用的提示词模板。

有效提示词的四个组成部分

无论使用哪个模型，能产出可用测试用例的提示词都包含相同的四样东西：

角色设定："扮演一位资深 QA 工程师"，这能设定回应的专业层级和术语。
真实上下文：粘贴实际的用户故事、验收标准、API 规范或代码片段。这一点比列表中其他任何要素都重要。模型读到真实需求才能发现真实的缺口，读到"一个登录表单"就只能靠猜。
具体任务：使用直接动词——"生成""列出""识别"，避免"思考一下"或"考虑"这类模糊表述。
输出格式：要求以表格（指定列名）、Gherkin 或 JSON 格式输出。如果你想把结果粘贴进测试管理工具，直接说明。

如果只能改一件事，那就改上下文。

提示词生成测试用例示意图

五类可直接套用的提示词模板

模板一：从用户故事生成功能测试用例

最常见的场景——你有用户故事和验收标准，需要第一轮覆盖。提示词中要求模型"包含正向、反向和边界用例"，并且"如果任何验收标准存在歧义，在单独的'假设'部分列出你的理解，而不是默默选择一种解释"。

"假设"指令是整段提示词中最有价值的一行。它让模型展示对需求缺口的推理，而不是掩盖它们——而这些缺口往往就是真正的 bug 所在。

比如对"添加购物车"功能，好的输出会包含验收标准中没写的场景：缺货商品点击按钮的预期行为、快速重复点击时数量是否一致、是否会产生重复行项目。这些正是模型发挥价值的地方，也是你审查时最该关注的。

模板二：边界用例与反向场景

模型擅长头脑风暴那些人们容易忘记的异常输入。要求模型"按类别分组"——输入验证、会话行为、速率限制、可访问性——并说明每个场景下系统的预期行为。

无结构的列表会滑向显而易见的用例，分类要求能迫使模型覆盖更广的维度。

模板三：安全导向的测试思路

对于测试自己的应用，模型可以快速生成常见漏洞检查清单，比如 SQL 注入和跨站脚本攻击。对每个用例给出输入、目标字段和期望的安全行为。

需要明确的是：这些输出只是起点清单，不能替代专业的安全评估或专用安全工具。而且只应对自己拥有或明确获得授权的系统运行这些测试。

SQL 注入是指攻击者在输入字段中插入恶意 SQL 片段，使应用把用户输入当作数据库命令执行，从而读取、篡改或删除数据。典型测试思路包括在用户名、搜索框、ID 参数中尝试 ' OR '1'='1、'; DROP TABLE-- 等载荷，观察系统是否返回异常数据或报错信息。跨站脚本攻击（XSS） 则是向页面注入恶意 JavaScript，当其他用户浏览该页面时脚本在其浏览器中执行，可窃取 Cookie 或会话令牌。测试时通常在评论、昵称、URL 参数等回显位置提交 <script>alert(1)</script> 之类的载荷，检查输出是否被正确转义。除此之外，完整的安全测试还应覆盖认证绕过、越权访问、CSRF、敏感信息泄露等维度，这些都超出单纯用例生成的范围，需要借助 SAST、DAST 等专用工具和人工渗透测试。

模板四：Gherkin 格式的 BDD 场景

如果你的团队使用行为驱动开发（BDD）规范，可以让模型生成 feature 文件初稿。要求"使用 Scenario Outline 搭配 Examples 覆盖输入变化"，并包含正向和反向路径。

BDD（行为驱动开发）与 Gherkin 是一种以自然语言描述软件行为的协作方法论，核心思想是让业务、开发和测试三方用同一种语言对齐需求。Gherkin 是 BDD 最常用的语法格式，通过 Feature、Scenario、Given、When、Then 等关键词把用例写成接近英语的结构化文本：Given 描述前置条件，When 描述触发动作，Then 描述可验证的预期结果。Scenario Outline 搭配 Examples 表格可以让同一条场景在多组输入下重复执行，非常适合覆盖边界值和输入组合。这类文件通常保存为 .feature 后缀，可被 Cucumber、SpecFlow、Behave 等框架直接解析并驱动自动化测试。让 LLM 生成 Gherkin 初稿的价值在于快速把用户故事转成结构化场景，但仍需人工确认 Then 中的预期结果是否与真实系统行为一致，否则容易固化模型编造的行为。

模板五：让模型自我审查

这个模板使用率偏低但价值很高。在生成测试套件后，用第二个提示词审查它：哪些需求没有测试覆盖？哪些用例重复或近似重复？哪些用例假设了需求中未声明的行为？最可能遗漏的五个高风险场景是什么？

第三个问题最关键——它能暴露模型"发明行为"的情况，这是 AI 生成测试中最常见的失败模式。

AI 生成测试用例的常见陷阱

LLM 是好的初稿引擎，但不是神谕。

它们不了解你的业务：模型不知道超过一定金额的退款需要经理审批，也不知道某个客户等级享受特殊定价。它只知道你提示词里写了什么。
它们会编造看似合理的行为：如果需求没有提及，模型可能会填入一个听起来对、但对你的产品来说是错误的答案。基于编造行为的测试会因错误原因失败，或者更糟——因错误原因通过。
它们产出数量而非优先级：三十个测试用例不比十个好，如果你分不清哪五个最重要。
生成的自动化代码只是草稿：如果你要求 Playwright 或 WebdriverIO 脚本，需要对照真实应用检查每一个选择器和等待策略。生成的选择器往往是猜测。
数据隐私是你的责任：不要把专有代码、客户数据或机密需求粘贴到公共模型界面。使用满足你组织数据保障要求的企业级方案。

审查清单与自动化衔接

在 AI 生成的测试用例进入测试套件之前，逐一检查：它是否能追溯到真实需求？预期结果是明确声明的还是仅隐含的？是否假设了未经确认的行为？是否与已有用例重复？如果它失败了，你能知道为什么吗？它值得自动化，还是更适合作为探索性检查？

无法通过这份清单的用例，要么重写，要么丢弃。

通过审查后，典型工作流是：生成用例 → 审查 → 挑选值得自动化的 → 转化为脚本。可以让模型生成特定框架的代码，但务必加上一句："在任何你不确定的选择器上方添加注释。"这条指令为你提供了一份需要手动验证的清单。

核心结论

更好的提示词来自更好的输入：真实需求、明确格式、以及要求模型声明其假设。模型负责快速起草，你的工作是判断什么值得保留。