TL;DR
- 系列方向：从 LLM 基础开始，逐步拆解 Prompt、RAG、工具调用和效果评估，最终做出一个可运行的 AI 测试辅助 Demo。
- 本篇重点：不是在搭建 AI 测试平台，而是在弄清楚 LLM 的工作方式、适用场景，以及它与传统测试程序的区别。
一、我想先解决一个问题：为什么要在测试工具里接入大模型？
假设我们正在维护一个接口自动化测试平台。
有一天，业务新增了一个创建订单的接口，需求大致如下：
- 用户可以选择商品并创建订单。
- 购买数量必须大于 0。
- 商品库存不足时，订单不能创建成功。
- 未登录用户不能创建订单。
现在需要根据这段需求补充测试用例。
如果按照以前的方式做，我们可以由测试工程师分析需求，再手动编写测试用例；也可以开发一些规则，根据需求模板或接口定义生成部分测试数据。
这两种方式都没有问题。
但如果需求越来越多，而且不同项目的需求文档写法不统一，想把所有测试场景都转换成固定规则，就可能变得越来越麻烦。
这时，我们可以尝试把需求交给大语言模型，让它生成一批候选测试点，再由程序检查格式和必要字段，最后由测试人员审核业务逻辑。
听起来很合理。
但在真正动手之前，我觉得有必要先问一句：
如果大模型只是把需求转换成测试点，它到底比我们自己写一套规则好在哪里？
如果回答不了这个问题，那么接入模型可能只是增加了一项外部依赖，并没有真正解决问题。
这也是我准备从 LLM 基础开始学习的原因。我希望先通过一些简单实验，弄清楚它擅长什么、不擅长什么，再决定哪些能力值得放进最终项目。
二、先不谈 AI，看看普通程序能做到什么程度
我们先用一个很简单的例子。
订单接口要求购买数量必须大于 0。假设测试数据已经准备好，我们可以直接写一条规则：
def check_quantity(quantity):
return quantity > 0
print(check_quantity(1)) # True
print(check_quantity(0)) # False
print(check_quantity(-1)) # False
对于这个问题，程序的行为非常明确：给定一个符合要求的数值，就返回 True；否则返回 False。只要输入类型和异常处理也考虑清楚，这段逻辑就很容易通过单元测试验证。
我们甚至不需要大模型参与。
再看一个稍微复杂一点的任务：
根据创建订单的需求，整理需要覆盖的测试场景。
这时，单靠上面那种规则就不够了。我们不仅要判断一个字段是否合法，还要理解需求中不同条件之间的关系。
例如：
- 库存不足时应该返回什么结果？
- 未登录用户是否允许调用接口？
- 购买数量超过库存时，系统应该拒绝请求还是允许拆分订单？
其中有些问题可以从需求中直接得出，有些问题则可能需要进一步确认。
如果完全依靠固定规则，我们就需要不断编写和维护各种匹配逻辑。大模型提供了另一种选择：先理解自然语言需求，再生成一份候选测试点列表。
但这里有个前提：模型只能依据已经提供的信息进行推断，它不能替我们决定需求中没有明确规定的业务行为。
例如，如果需求没有说明库存不足时的错误码，模型即使给出了一个具体错误码，也不能把它当成真实的接口约定。
因此，我更愿意把模型生成的内容看作一份待验证的测试设计草稿，而不是可以直接执行的最终测试用例。
这个定位很重要，它决定了我们后续应该怎样设计整个系统。
三、LLM 是什么？为什么它能够处理这类问题？
LLM 是 Large Language Model 的缩写，中文叫大语言模型。
从应用开发的角度，可以先把它理解为一个根据输入文本和上下文生成内容的模型。
例如，我们向模型提供创建订单的需求，它就可以生成一组测试场景；我们提供接口错误日志，它可以帮助归纳异常现象，并给出排查方向。
典型的自回归语言模型，会根据已有上下文预测下一个 Token，再按照相应的生成策略选择 Token，并继续生成后续内容，直到满足停止条件。
Token 是模型处理文本时使用的基本单位，它不一定等于一个汉字、一个英文单词或一个字符。
这可以解释 LLM 为什么能够生成内容，但还不能直接解释它为什么适合做测试分析。
对我来说，更值得关注的是：模型能够根据自然语言上下文，处理那些不容易完全写成固定规则的任务。
比如，同样是创建订单的需求，我们可以从不同角度提出问题：
- 正常情况下，订单应该如何创建？
- 哪些输入可能不合法？
- 哪些业务条件之间存在相互影响？
- 需求中还有哪些地方没有说清楚？
这些问题并不只是简单的字段校验，而是涉及文本理解、信息整理和场景归纳。
LLM 可以帮助我们生成候选答案，但答案是否符合真实业务，仍然需要验证。
这里还有一个容易混淆的地方：模型能生成合理的解释，不代表它已经验证了自己的结论。
例如，模型可能建议测试“用户购买数量超过库存时，接口应该返回库存不足错误”。这个场景听起来很合理，但我们仍然需要确认需求是否规定了这个行为，以及系统实际采用什么响应格式。
如果没有这些约束，模型生成得越具体，不一定就越可靠。
所以，在这个系列中，我不打算把“模型能生成内容”直接等同于“模型能解决问题”。我们还需要进一步研究生成质量、输出验证和评估方法。
四、第一次动手：让模型生成测试点
理解了基本区别之后，我们先做一个最小实验。
目标不是做出完整的测试工具，而是打通一条最简单的链路：
输入需求 → 调用模型 → 获取生成结果
4.1 准备环境
本例使用 Python 和 OpenAI Python SDK。调用需要可用的模型服务、有效的 API Key，以及服务支持的模型名称。
安装依赖：
python -m pip install openai
配置环境变量：
export OPENAI_API_KEY="你的_API_Key"
export OPENAI_MODEL="服务支持的模型名称"
如果使用其他兼容 OpenAI API 的服务，需要根据对应服务商的文档配置 API 地址、模型名称及认证方式。不要将真实 API Key 直接写入代码或提交到 Git 仓库。
4.2 编写调用代码
创建 first_llm_demo.py：
import os
from openai import OpenAI
client = OpenAI(
api_key=os.environ["OPENAI_API_KEY"]
)
model = os.environ["OPENAI_MODEL"]
requirement = """
创建订单接口需求：
1. 用户可以选择商品并创建订单。
2. 购买数量必须大于 0。
3. 商品库存不足时，订单不能创建成功。
4. 未登录用户不能创建订单。
请根据以上需求生成测试点。
对于需求中没有明确规定的行为，请标注为待确认，
不要自行补充具体的错误码或业务规则。
"""
response = client.chat.completions.create(
model=model,
messages=[
{
"role": "system",
"content": "你是一名软件测试工程师。"
},
{
"role": "user",
"content": requirement
}
],
)
print(response.choices[0].message.content)
运行：
python first_llm_demo.py
如果配置正确，程序会输出模型生成的内容。
这段代码没有引入 Agent 框架，也没有连接向量数据库，它只完成一次基本的模型调用。
这正是我们第一步想要的：先把最基本的东西弄清楚，再决定是否需要增加其他组件。
需要说明的是，这里给出的是可运行的示例代码，并非已经在实际环境中执行过的实验。我不会预先把可能出现的回答写成真实运行结果。后续如果要比较生成质量，需要实际运行、保存输出，再根据相同标准进行分析。
4.3 运行之后，不要只看它生成了多少条
模型返回结果后，我建议先检查几个具体问题：
- 需求里明确规定的四项内容，是否都得到了覆盖？
- 模型有没有遗漏购买数量为 0、负数等明显边界条件？
- 它有没有擅自补充需求中没有说明的错误码、订单状态或其他业务规则？
- 不同测试点之间是否存在重复？
这些问题比单纯统计生成了多少条测试点更有价值。
如果模型生成了 20 条测试点，却遗漏了“未登录用户不能创建订单”这一条明确规则，那么数量本身并不能说明生成质量好。
当然，仅凭一个需求样例，也无法得出模型整体效果好坏的结论，它只能帮助我们发现值得进一步测试的行为。
接下来，我们就可以围绕这些问题设计更系统的实验。
五、我更关心的不是模型能不能回答，而是它在什么情况下会出错
模型调用成功只是起点。
对于测试工具而言，更重要的问题是：如果需求变复杂、输入信息不足，或者提示词发生变化，生成质量会怎样？
下面三个实验可以先帮助我们建立基本认识。
5.1 实验一：同一份需求，多次生成
保持需求内容不变，连续调用模型几次，分别保存结果。
记录以下信息：
| 记录项 | 需要关注的内容 |
|---|---|
| 模型信息 | 模型名称、版本信息（如果服务提供） |
| 输入内容 | 完整需求和提示词 |
| 生成参数 | 服务支持的采样参数及其设置 |
| 测试点覆盖 | 明确规定的需求是否都被覆盖 |
| 未知规则 | 是否出现没有依据的业务假设 |
| 输出质量 | 重复、遗漏、格式错误等问题 |
这个实验想回答的问题是：同一个任务的输出，是否具有足够的稳定性？
这里不能预设结果一定不同，也不能认为同样的输入必然得到完全相同的输出。实际行为取决于模型、服务实现和生成参数。
另外，即使多次输出完全一致，也不能说明它们一定正确。一个稳定地遗漏关键条件的模型，仍然可能不适合当前任务。
5.2 实验二：只改变提示词
我们再准备三个版本的提示词。
版本 A：
请根据创建订单的需求生成测试点。
版本 B：
请根据创建订单的需求生成测试点。
至少覆盖正常场景、异常场景和边界条件。
版本 C：
请根据创建订单的需求生成测试点。
每个测试点包含：
- 测试场景
- 前置条件
- 输入数据
- 预期结果
请覆盖需求中明确规定的业务规则。
如果某个预期结果没有明确依据，请标注待确认，
不要自行假设具体的业务规则。
然后分别运行并比较结果。
这里要注意，三个版本不只是长度不同，版本 C 还增加了输出字段和未知规则的处理要求。因此，这个实验可以用来观察整套提示词约束的影响，但不能单独证明某一条指令一定是效果变化的原因。
如果想进一步定位原因，可以再设计一组对照实验，每次只增加一项约束。
这也是后面研究 Prompt Engineering 时值得保留的习惯：一次尽量只改变一个变量，否则很难知道效果变化究竟来自哪里。
5.3 实验三：故意删掉一条关键信息
我们把原始需求中的“商品库存不足时，订单不能创建成功”删掉，再让模型生成测试点。
观察它是否仍然生成库存不足场景，以及它如何描述对应的预期结果。
如果模型生成了这个场景，不能立即认定它出错了，它可能根据常见的订单业务经验提出了一个合理的候选场景。
真正需要关注的是：它有没有把这个场景明确标注为建议或待确认，还是直接把某种具体行为写成已确定的业务规则。
在实际项目里，这两种输出的意义完全不同：
- 前者可以帮助测试人员发现需求遗漏；
- 后者则可能把一个未经确认的假设带进测试用例，甚至在后续自动化执行时制造误报。
这也让我觉得，未来的 AI 测试工具不能只关注“生成得全不全”，还应该关注生成内容是否有依据，以及哪些结论需要人来确认。
这三个实验目前是实验设计，不是已经取得的实测结论。等实际运行后，可以把输入、输出、问题案例和修正过程补充进后续文章，让判断有真实依据。
六、如果最终要做一个 AI 测试辅助工具，我会怎么划分职责？
经过上面的分析，我暂时不会把 LLM 设计成一个可以随意操作整个测试环境的智能体。
第一版先解决一个边界清晰的问题：根据给定的需求，生成候选测试点，并检查输出格式。
初步流程可以是这样：
flowchart TD
A["输入需求"] --> B["构造模型输入"]
B --> C["调用 LLM 生成候选测试点"]
C --> D["检查输出格式和必要字段"]
D --> E["展示测试点，标记待确认内容"]
E --> F["由测试人员审核业务正确性"]
这个流程看起来不复杂，但它已经包含了几个重要的工程边界：
- 模型负责生成候选内容；
- 程序负责确定性的校验；
- 测试人员负责确认业务语义。
例如，程序可以检查返回内容是否为合法 JSON、每条测试点是否包含必需字段，却不能仅靠字段检查就证明测试点符合业务规则。
如果后续我们要让系统读取项目中的接口文档，再决定如何生成测试点，就可以研究 RAG；如果要让模型查询执行结果或调用受控的测试工具，就可以研究工具调用；如果想知道 Prompt 修改后究竟有没有改善效果，就需要建立评估数据集和评价标准。
但这些能力应该逐步加入，而不是在第一版里一次性堆上去。
如果后续实验发现，给模型直接提供一份简短的接口文档就足以完成任务，那我们也没有必要为了使用 RAG 而额外引入检索系统。
对于我想做的这个 Demo，技术选型的标准应该是：它是否解决了已经明确的问题，以及增加的复杂度是否值得。
七、这篇文章真正想留下的结论
大语言模型可以帮助我们理解自然语言需求、归纳信息和生成候选测试点，但它的输出不应直接被当成经过验证的业务事实。
对于规则明确的判断，传统程序往往更合适；对于难以完全写成固定规则的文本分析任务，LLM 值得尝试。两者结合，通常比让模型独自承担整个测试流程更容易建立可靠的工程边界。
接下来需要继续验证的，是模型生成质量到底如何衡量、提示词如何影响输出，以及怎样识别那些看起来合理却没有需求依据的内容。
