测试转大模型：从团队协作视角展开

Java技术那些事儿

墨衍会员 · 1平台 · 300+阅读码龄5年

关注

原创最新推荐文章于 2026-08-28 10:25:51 发布 355 阅读 AI 写同款· GEO 优化 ›

GEE开发之Landsat8计算MNDWI和数据分析上一篇博客介绍了landsat8计算NDWI以及数据的获取，这次介绍MNDWI（改进的归一化差异水体指数）。阅读详情

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

摘要

先把这篇文章的目标说清楚：看完之后，你应该能判断这件事值不值得做，以及从哪里动手。

最近大厂都在讨论大模型应用从 Demo 走向生产环境的门槛，焦点不再是“模型有多聪明”，而是“权限控制、日志追踪和可观测性”。对于做测试出身的同学来说，这其实是个好消息。我们比纯开发更懂边界，更在意异常分支，也更能接受“系统是不完美的”这一事实。

但这并不意味着我们可以直接跳过基础去搞 Agent 框架。很多测试同事转型时，容易陷入两个极端：要么死磕 Prompt Engineering 的玄学，要么盲目追逐最新的 LangChain/LangGraph 版本，最后发现连最基本的 LLM 调用稳定性都没搞定。

今天不谈虚的，结合我最近帮团队重构 AI 质检系统的经历，聊聊测试背景的同学如何一步步补齐能力栈，以及哪些东西现在可以先放一放。

测试岗位的新变化：从“找 Bug”到“定义质量”
AI 辅助测试：别只把它当 Copilot
自动化用例生成：从“记录回放”到“意图驱动”
Agent 测试框架：LangGraph 还是自研？
质量评估：RAGAS 和人工标注的结合
总结：先补什么，暂时放什么

测试岗位的新变化：从“找 Bug”到“定义质量”

文章插图 1

传统测试关注功能正确性、性能指标和安全漏洞。但在大模型应用中，质量定义变了。LLM 的输出具有概率性（Non-deterministic），同样的输入在不同时间、不同温度下可能产生不同结果。

这时候，传统的断言（Assert）失效了。你不能指望 assertEquals(expected, actual)。

我参与的一个项目初期，直接用 JUnit 测试 LLM 生成的 SQL。结果很惨烈，因为 LLM 偶尔会加注释或者改变字段顺序，导致精确匹配失败。后来我们引入了“基于规则的模糊匹配”和“执行验证”——即不仅检查生成的 SQL 语法，还要在沙箱里预执行，看是否报错。

启示：测试工程师的优势在于设计测试用例和评估维度。你需要学会从“功能测试”转向“效果测试”和“安全测试”。

AI 辅助测试：别只把它当 Copilot

文章插图 2

很多人以为用 GitHub Copilot 或 Cursor 写测试脚本就是 AI 测试。这只是效率提升，不是能力跃迁。

真正的 AI 辅助测试，是利用 LLM 去生成测试数据、分析错误日志，甚至自动构造对抗样本。

比如，在一个电商搜索项目中，我们遇到大量长尾查询导致的召回率下降问题。手动构造测试用例太慢，于是我们训练了一个小的分类模型，对历史搜索日志进行聚类，找出低质 query 分布。然后利用 LLM 针对每个簇生成变体（同义词、错别字、口语化表达），批量注入测试环境。

import openai
from datasets import load_dataset

# 假设我们有一个低质查询列表
low_quality_queries = ["手机壳支架坏了怎么办", "苹果15promax多少钱"]

def generate_test_variants(query):
    """利用 LLM 生成同义变体，覆盖更多边界情况"""
    prompt = f"""
    你是一个测试专家。请为以下查询生成 5 个语义相同但表达方式不同的变体。
    要求：包含口语化、简写、错别字等常见噪声。

    原始查询: {query}
    """
    response = openai.ChatCompletion.create(
        model="gpt-4o-mini",
        messages=[{"role": "user", "content": prompt}]
    )
    return response.choices[0].message.content

for q in low_quality_queries:
    variants = generate_test_variants(q)
    print(f"Query: {q} -> Variants:\n{variants}")

这段代码很简单，但它体现了测试思维：通过生成多样化的输入来探测系统的鲁棒性。

优快云资料领取方式

自动化用例生成：从“记录回放”到“意图驱动”

传统自动化测试（如 Selenium）依赖 DOM 结构和固定流程。一旦 UI 变动，脚本就挂。

在大模型时代，我们可以尝试用 LLM 理解用户意图，自动生成测试步骤。但这中间有个巨大的坑：幻觉。LLM 可能会编造不存在的按钮或 API。

我的建议是：人机协同验证。
1. LLM 根据 PRD 生成初步的测试步骤（伪代码或自然语言）。
2. 测试人员人工审核逻辑完整性。
3. 使用工具调用（Function Calling）将自然语言转化为可执行的 API 请求或 UI 操作指令。
4. 执行后，由另一个轻量级模型或规则引擎检查结果是否符合预期。

不要试图完全自动化端到端的大模型测试流程，目前成本太高且不稳定。保留人工介入的关键节点，才是工程化的务实做法。

Agent 测试框架：LangGraph 还是自研？

最近 LangGraph 很火，它解决了传统 LangChain 循环引用的问题，更适合构建有状态的 Agent。

但是，作为测试工程师，我不建议你一开始就深入研究 LangGraph 的内部实现。你应该关注的是：如何测试一个 Agent？

Agent 的核心能力是：感知、规划、行动、记忆。测试重点应放在：

规划合理性：Agent 分解任务的路径是否最优？是否有死循环风险？
工具调用准确性：是否正确调用了外部 API？参数是否越界？
上下文管理：在多轮对话中，是否遗忘了关键信息或引入了噪声？

我推荐先用简单的 Python 脚本模拟 Agent 的行为流，记录每一步的工具调用和状态变化，而不是直接搭建复杂的编排框架。等你理解了 Agent 的运行轨迹，再去考虑如何用 LangGraph 或 AutoGen 来构建测试骨架。

质量评估：RAGAS 和人工标注的结合

大模型应用的评估（Evaluation）是转型的最大难点。没有 Gold Standard，怎么测？

业界常用 RAGAS（Retrieval Augmented Generation Assessment）框架，它通过生成合成数据来评估检索质量和生成质量。

实战建议：
1. 建立小规模黄金数据集：哪怕只有 100 条，也要保证每条都有标准答案和评分依据。这是所有自动化评估的基础。
2. 多维度评估：
* Faithfulness：回答是否忠实于检索到的上下文？
* Answer Relevance：回答是否与问题相关？
* Context Precision：检索到的上下文是否精准？
3. 不要迷信分数：LLM-as-a-Judge 本身也有偏见。定期抽样人工复核，校准模型评分的标准。