聊《测试转大模型：项目里真正好用的做法》之前，先说一句实在的：别急着背概念，先看它在真实项目里到底解决什么问题。

摘要

本文概述文章目标、核心观点和实践价值。

很多做传统功能测试或自动化测试的朋友，最近都在焦虑：大模型来了，我的 Selenium 脚本是不是要废了？

说实话，我刚开始接触 LLM（大语言模型）时也有这种恐慌。但真正把手伸进代码里搞了几个项目后，我发现事情没那么简单。大模型不是要替代测试工程师，而是把测试的边界从“执行”推向了“定义”和“评估”。

今天不谈那些虚头巴脑的概念，就结合我最近带团队做 AI 应用测试的经历，聊聊在真实项目里，我们是怎么把 AI 能力嵌进测试流的。重点不在“能不能跑通”，而在“怎么维护”和“怎么协作”。

目录

• 测试岗位的新变化
• AI 辅助测试：效率提升的真相
• 自动化用例生成：要有取舍
• Agent 测试框架：协作与日志
• 质量评估：可维护性的关键
• 总结

测试岗位的新变化

先说个直观的感受：测试的输入变了。

以前我们测的是确定性逻辑，输入 A 必然得到输出 B。现在测的是概率性逻辑，输入 A 可能得到 B、C 甚至 D，而且每次概率还不一样。这意味着传统的断言（Assert）失效了。你不能写 assert response == "正确"，因为模型可能回答“答案是对的，不过...”或者干脆说“抱歉，我无法回答”。

在这种背景下，测试工程师的角色发生了两个关键转移：

1. 从用例设计者转向 Prompt 审查者：你需要理解模型的边界，知道在什么情况下模型会幻觉。
2. 从执行者转向评估体系构建者：既然输出不唯一，那用什么标准来衡量“好”与“坏”？这就是质量评估的核心。

我在项目中常跟开发说：“别光看功能跑通了，我要看的是，当输入稍微模糊一点时，模型是优雅地拒绝，还是胡言乱语？”前者是质量，后者是事故。

AI 辅助测试：效率提升的真相

很多团队一上来就想用 AI 自动生成测试用例。这确实能省时间，但我强烈建议不要直接把这个环节交给黑盒。

在我和开发协作的过程中，我们发现最有价值的 AI 辅助场景其实是日志分析和错误归类。

假设你的线上接口突然报错增多，传统做法是人工去 ELK 或者 Splunk 里搜关键字，然后手动分类。现在，我们可以让 LLM 扮演一个资深 QA 的角色。

import openai

def analyze_log_pattern(error_logs):
    """
    利用 LLM 对异常日志进行聚类分析
    """
    prompt = f"""
    以下是最近 1 小时内捕获的 5 条后端异常日志片段：
    {error_logs}

    请执行以下任务：
    1. 识别这些错误的根本原因类别（如：数据库超时、参数校验失败、第三方 API 返回格式变更等）。
    2. 如果属于同一类错误，请合并它们并给出简要描述。
    3. 针对每一类错误，给出一个建议的修复方向。

    请以 JSON 格式返回，包含 key: 'category', 'count', 'summary', 'suggestion'。
    """

    response = openai.ChatCompletion.create(
        model="gpt-4",
        messages=[{"role": "user", "content": prompt}]
    )

    return response.choices[0].message.content

这段代码在实际落地时，我发现最大的坑不是代码本身，而是Prompt 的稳定性。如果日志格式稍微变动，LLM 的解析就会出错。所以，我们在项目中加入了一层预处理逻辑，先清洗日志，再发给模型。同时，我们要求 LLM 的输出必须严格符合 JSON Schema，否则视为失败重试。

这种“AI 辅助分析”比“AI 生成用例”更容易落地，因为它直接解决了团队最头疼的排错效率问题，而且结果可追溯、可验证。

自动化用例生成：要有取舍

回到用例生成。我也试过让 AI 根据 PRD 文档自动生成 Pytest 脚本。效果好吗？好，但维护成本极高。

为什么？因为大模型生成的代码往往缺乏上下文感。它不知道你们项目的目录结构、不知道某个 Helper 函数的具体签名，更不知道业务逻辑里的隐性约束。

我现在的做法是：AI 负责生成“骨架”和“边缘场景”，人工负责填充“业务血肉”。

例如，对于一个登录功能，我会让 AI 生成常规流程，以及它想到的奇怪输入（空字符串、Emoji、超长字符）。但对于涉及金额计算、权限继承这种强业务逻辑的地方，我必须手动编写用例，并让 AI 帮忙优化断言语句。

此外，我特别强调测试数据的脱敏和安全。在生成用例时，千万不要把生产环境的敏感数据喂给公有云 LLM。我们会在本地部署一个轻量级的模型，或者使用经过脱敏处理的模拟数据。这一点在团队推广时经常被忽略，导致后续合规审计的大麻烦。

Agent 测试框架：协作与日志

最近 Agent（智能体）测试很火，很多测试工程师开始尝试 LangChain 或 AutoGen。但在团队协作中，Agent 测试最难的不是调用，而是调试。

Agent 是多步推理的结果，一步错了，后面全错。如果你只是扔出一个 Prompt 看结果，出问题时你根本不知道是哪一步幻觉了。

所以我建议，无论用哪个框架，都必须强制开启结构化日志记录。

{
  "trace_id": "uuid-1234",
  "step": 1,
  "action": "retrieve_context",
  "input_query": "用户去年的订单记录",
  "retrieved_docs": [...],
  "reasoning": "根据日期过滤，发现无记录",
  "next_action": "generate_response"
}

在代码实现上，我们可以利用 Decorator 或者中间件的方式，自动拦截 Agent 的每一轮思考过程。这样当下游反馈“回答错误”时，我们能立刻定位到是检索不到知识，还是推理逻辑偏差。

对于测试工程师来说，学会看懂这些 Trace Log，比学会写复杂的 Prompt 更重要。因为你可以基于日志做回归测试，而不仅仅是靠直觉。

质量评估：可维护性的关键

最后，也是我最想强调的一点：没有评估体系的 AI 测试都是耍流氓。

在传统测试中，Pass/Fail 很简单。但在 AI 测试中，我们需要构建多维度的评估集（Evaluation Set）。这个评估集不是静态的，它需要随着业务迭代不断更新。

我建议采用“黄金数据集 + 在线抽样”的模式：

1. 黄金数据集：由资深测试人员和业务专家共同标注的 100-500 条典型用例。涵盖正常、边界和对抗性场景。每次模型版本更新前，必须全量跑一遍这个集子，分数不能低于基准线。
2. 在线抽样：在生产环境中，随机抽取 1% 的交互请求，送给模型打分（可以使用另一个更强的模型作为 Judge，或者人工抽检）。

这里有个取舍：完全自动化评估很难做到 100% 准确。所以我们接受一定的误差率，但必须保证评估的一致性。也就是说，同样的输入，两次评估的结果应该是一样的。为此，我们会固定模型的 Temperature 为 0，并确保 Prompt 模板的版本控制。

总结

从测试转到大模型领域，并不是要抛弃你原有的技能树，而是要升级它。

• 不要迷信全自动：目前阶段，Human-in-the-loop 才是王道。
• 重视可观测性：没有日志和 Trace 的 Agent 测试就是盲人摸象。
• 建立评估壁垒：谁能快速构建并维护高质量的评估集，谁就在 AI 质量工程中拥有话语权。

这条路刚开始走的时候会很别扭，你会觉得模型不可控，会觉得 Prompt 像是在玄学调试。但当你建立起一套稳定的评估体系和协作流程后，你会发现，AI 测试不再是填坑，而是在造桥。

保持好奇，动手去试，哪怕是从一个简单的日志分析脚本开始。

资料展示

下面是我整理的AI大模型学习资料和工具包预览，适合收藏后按主题逐步学习。

如果你想看完整资料目录，可以在评论区留言「资料」；也欢迎告诉我你更关注AI大模型里的哪类内容。