大語言模型到底能為測試做什麼？從一個真實問題説起

简介： - 系列方向：从 LLM 基础开始，逐步拆解 Prompt、RAG、工具调用和效果评估，最终做出一个可运行的 AI 测试辅助 Demo。- 本篇重点：不是在搭建 AI 测试平台，而是在弄清楚 LLM 的工作方式、适用场景，以及它与传统测试程序的区别

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 运行之后，不要只看它生成了多少条

模型返回结果后，我建议先检查几个具体问题：

1. 需求里明确规定的四项内容，是否都得到了覆盖？
2. 模型有没有遗漏购买数量为 0、负数等明显边界条件？
3. 它有没有擅自补充需求中没有说明的错误码、订单状态或其他业务规则？
4. 不同测试点之间是否存在重复？

这些问题比单纯统计生成了多少条测试点更有价值。

如果模型生成了 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 值得尝试。两者结合，通常比让模型独自承担整个测试流程更容易建立可靠的工程边界。

接下来需要继续验证的，是模型生成质量到底如何衡量、提示词如何影响输出，以及怎样识别那些看起来合理却没有需求依据的内容。