同样的需求,为什么你写的 Prompt 生成的用例不能用?——大模型基础与提示词工程(为测试而学)

开篇钩子:两个测试工程师,一道需求,两种命运

真实场景：同一个"用户登录"需求:

小王打的指令是:“帮我写几个用户登录的测试用例。” 三秒钟,AI 吐回来 5 条:正确账号密码登录成功、错误密码登录失败、账号为空、密码为空、账号不存在。看着挺像那么回事,但拿去评审直接被打回——没有验证码逻辑、没有锁定策略、没有 Token 过期、边界全靠脑补,而且格式是一段大白话,导不进任何用例管理平台。

小李打的指令长达 30 行:设定了"资深测试专家"的角色,给了两条示范用例,明确要求按等价类 + 边界值覆盖,规定输出 JSON 且字段固定,还划了"只测登录、不测注册"的边界。AI 返回了 23 条结构化用例,字段齐整,直接脚本入库 TAPD。

同一个模型,同一个需求,差距全在 Prompt 上。这一篇就把"为测试而学"的大模型知识和提示词工程讲透——不堆术语,够用就行,最后给一套能直接复制的提示词模板库。

上图:左侧是模糊 Prompt 产出的"看着像、用不了"的散文用例,右侧是结构化 Prompt 产出的可入库 JSON 用例。差距不在模型,在人。

5 分钟讲清 LLM 原理

你不需要懂 Transformer 的注意力机制,也能把 AI 用好。但有四个概念,直接决定你写的 Prompt 是否稳定、是否省钱、是否能信。

Token:AI 眼里的"字"不是字

大模型不是按"字"读文本的,而是按 Token。一个 Token 大约是 0.5 个汉字或 0.75 个英文单词。"用户登录失败"这六个字,可能被切成 4 个 Token。

为什么要关心它?因为两件事跟它直接挂钩:

• 计费:几乎所有在线 API 都按 Token 收费,输入 + 输出一起算。 你把一份 5000 字的需求文档整篇塞进去,再让它生成 50 条用例,一次调用可能就是几千 Token。
• 上下文窗口上限:模型一次能"看见"的 Token 是有限的。需求太长,前面的内容会被挤出去。

Token 是 AI 的"字数单位",也是你的钱包刻度。

上下文窗口:AI 的"短期记忆"有上限

上下文窗口(Context Window)是模型单次对话能容纳的 Token 总量,包括你的输入和它的输出。可以把它想象成一张固定大小的白板:你写满了,再写新的,旧的就被擦掉。

主流模型从 8K(约 6000 字)到 128K、200K 不等。对测试场景的含义是:

• 一份超长需求 + 历史对话 + 大量示例,可能超出窗口,导致模型"忘了"开头的角色设定。
• 这也是为什么我们会强调:把最重要的约束放在 Prompt 靠前和靠后的位置,中间的内容模型最容易"看漏"(这就是业界说的"middle loss",中间迷失现象)。

温度 temperature:AI 的"脑洞旋钮"

temperature 控制输出的随机性,取值通常 0 到 1(部分模型到 2)。

• 低温(0~0.3):输出确定、保守、可复现。同样的 Prompt 跑十次,结果高度一致。
• 高温(0.7~1.0):输出发散、有创意,但也更容易跑偏。

类比:temperature 就像让 AI"放飞"的程度。写营销文案你想要惊喜,可以调高;而我们做测试用例,要的是稳定、可复现、可入库,几乎永远把温度调低(0.2~0.3)。

幻觉:为什么 AI 会一本正经地胡说

大模型的本质是"根据上文预测下一个最可能的 Token",它在做的是概率接龙,不是查数据库。当它对某个事实没有把握时,不会说"我不知道",而是顺着语感编一个看起来最合理的答案。这就是幻觉(Hallucination)。

在测试场景里,幻觉会以这些面目出现:

• 编造一个需求里根本不存在的接口字段,然后给它写一堆用例。
• 引用一个不存在的错误码 ERR_4096,言之凿凿。
• 把"建议"包装成"需求规定"。

记住一个底层认知:AI 给你的不是真相,是"最像真相的文本"。所以我们要反复强调"人工校验"这道关。提示词工程的一半价值,就是用结构和约束把幻觉的空间压到最小。

测试场景下的提示词工程核心技巧

怎么把 Prompt 写得让 AI 稳定产出能用的用例。下面有五个技巧,每个配一组好坏对比。

技巧一:角色设定(System Prompt)——给 AI 一个身份

模型的行为会被它"以为自己是谁"强烈影响。让它当"通用助手"和让它当"有十年金融行业经验的测试架构师",输出质量是两个量级。

坏例子(无角色,泛泛而谈):

帮我测一下登录功能。

好例子(精准角色 + 职责):

你是一名有 8 年经验的资深测试工程师,擅长用等价类划分和边界值分析设计用例,
对安全测试(越权、暴力破解、Token 失效)尤其敏感。你的用例要能直接交给初级
测试执行,步骤明确、预期可判定。

角色越具体,AI 越知道"该用哪一套专业知识来回答"。

技巧二:Few-shot 示例——给一个标准答案

这是性价比最高的技巧。与其用一堆形容词描述你要什么,不如直接给一两个范例。AI 极擅长模仿格式和粒度。

坏例子(零示例,粒度全靠猜):

给我登录功能的测试用例,要详细一点。

"详细"是多详细?AI 只能瞎猜。

好例子(给一条样例,锚定格式与粒度):

请按下面这条样例的格式和粒度,生成登录功能的测试用例:

样例:
- 用例标题:正确手机号 + 正确密码登录成功
- 前置条件:账号 13800000000 已注册且未锁定
- 操作步骤:1.输入手机号 13800000000 2.输入正确密码 3.点击登录
- 预期结果:登录成功,跳转首页,返回有效 Token
- 优先级:P0

给了样例,AI 后续每一条都会对齐这个粒度。这就是"用例子代替形容词"。

技巧三:结构化输出——强制返回 JSON

散文式用例没法入库。我们要的是机器可解析的结构。直接在 Prompt 里规定输出的 JSON Schema 是关键一步。

坏例子(口语化要求):

用例最好能整理成表格或者列表的形式。

好例子(定义好 Schema,字段不留模糊空间):

只返回 JSON 数组,不要任何额外说明文字。每个元素结构如下:
{
  "id": "用例编号,如 TC-LOGIN-001",
  "title": "用例标题",
  "precondition": "前置条件",
  "steps": ["步骤1", "步骤2"],
  "expected": "预期结果",
  "priority": "P0/P1/P2",
  "type": "正向/异常/边界/安全"
}

“只返回 JSON,不要额外说明"这句话非常重要,否则 AI 爱在前面加一句"好的,以下是为你生成的用例:”,直接把 JSON 解析搞崩。

技巧四:约束与边界——告诉 AI 不要做什么

AI 有个毛病:发散。你让它测登录,它能顺手把注册、找回密码、个人中心全测了。明确的边界能让产出聚焦。

坏例子(无边界):

测试登录相关的所有内容。

好例子(正向 + 负向边界都给清):

覆盖范围:仅手机号 + 密码登录这一条主路径,包含正向、异常、边界、安全四类。
不要覆盖:第三方登录(微信/支付宝)、注册、找回密码——这些有独立需求。
约束:验证码错误锁定阈值为 5 次,锁定时长 30 分钟,以此为准设计用例。

把业务规则(锁定阈值 5 次/30 分钟)直接喂进去,能有效压制幻觉——AI 不用自己编规则了。

技巧五:思维链(Chain-of-Thought)——让 AI 先想后写