测试转大模型：上线前最该检查的几件事-开发者社区

这篇我按“先跑起来、再讲取舍”的方式写《测试转大模型：上线前最该检查的几件事》。概念会讲，但重点放在代码怎么组织、哪里容易踩坑。

摘要

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

最近翻了几家大模型应用公司的 QA 岗位 JD，发现要求已经从“会写接口自动化、熟悉 CI/CD”变成了“懂 Prompt 工程、能做 Agent 链路观测、能设计多维质量评估”。很多同行第一反应是去死磕 Python 或 LangChain 源码，但实际踩坑后发现，大模型测试的核心不是造轮子，而是把黑盒变成灰盒。这篇文章不聊虚的概念，直接拆解岗位能力栈，按优先级排好练习顺序。结合近期团队做模型应用上线的经验，重点讲权限、日志和可观测性怎么补进测试体系。如果你正打算转型，按这个节奏走，简历和项目复盘能直接对标业务需求。

招聘 JD 变了，测试的护城河在哪？
别只盯着 Prompt，先搞定可观测性
自动化用例生成：从“能跑”到“敢上”
Agent 测试框架：把流程拆成可验证的步骤
质量评估：别拿准确率当唯一指标
总结与练习路线

招聘 JD 变了，测试的护城河在哪？

以前测 Web 或 App，边界很清晰：UI 元素定位、接口入参出参、数据库校验。现在大模型应用上线，边界模糊了。一个请求进去，经过路由、检索增强、提示词拼接、模型推理、后处理，最后返回结果。传统回归测试的快照比对在这里基本失效，因为模型每次输出的措辞可能微调，但业务逻辑完全正确。

我翻了近一个月的招聘要求，发现高频词集中在三块：向量检索验证、Agent 工具调用链追踪、幻觉抑制测试。很多候选人简历写着“熟悉框架调用”，但项目里只会跑个聊天 Demo。企业真正要的是能把非确定性输出收敛到可验证范围的人。

我的判断标准很简单：你能不能把“模型说了算”变成“数据流和规则流说了算”？转型的第一步不是背算法原理，而是把现有测试经验平移过去。比如你熟悉契约测试，就可以用 JSON Schema 约束模型输出结构；你熟悉性能压测，就可以测 Token 消耗和首字延迟。护城河不在模型本身，而在工程化验证的肌肉记忆。

别只盯着 Prompt，先搞定可观测性

很多人一提到大模型测试，第一反应是调 Prompt、做 Few-shot。这没错，但 Demo 阶段玩够了，一上生产环境就会卡壳。最近几个项目上线前复盘，暴露的最多问题不是 Prompt 写得烂，而是出了故障根本查不到是哪一环断了。

权限控制和日志埋点必须前置。大模型应用经常对接外部 API（比如数据库查询、邮件发送、代码执行），如果测试环境没做好权限隔离，一个越权请求就能让内部数据泄露。我们现在的做法是，在测试用例里强制加入权限边界检查：哪些角色能触发 Agent 的工具调用？哪些输入会绕过安全过滤器？

可观测性也不只是打 Log。你得知道每次推理的 Prompt 模板长什么样、Retrieval 环节召回了什么片段、模型思考路径被截断在了第几步。我推荐用结构化日志记录全链路 Trace ID，配合简单的 Dashboard 看请求分布。别等线上慢得像蜗牛才想起来加监控，测试阶段就把埋点接口串起来，用请求模拟器跑异常流量，观察日志是否完整落盘。这一步做扎实了，后面写自动化脚本才不慌。

自动化用例生成：从“能跑”到“敢上”

大模型能写代码，也能自己生成测试用例。这听起来很诱人，但实际用起来有两个坑：一是生成的用例覆盖盲区，二是难以维护。我的做法是“人定骨架，模型填肉”。

先用业务逻辑梳理出核心场景树，比如“用户提问->意图识别->知识检索->答案生成->合规过滤”。每个节点定义好输入输出契约。然后让模型针对单个节点生成边界用例：空输入、超长上下文、敏感词、多轮对话状态重置。生成后，人工过一遍，剔除逻辑重复的，保留有破坏性的。

落地时，我会把这些用例转成结构化数据（YAML 或 JSON），配合测试框架批量执行。不要指望模型一次生成 100% 可用的用例，它更擅长做压力测试的数据生成器。比如让你测一个内部知识库问答机器人，你让它生成 500 种问法相同的提问（换句式、加语气词、故意混淆专业术语），再跑回归。这种“数据增强”思路，比硬背测试理论管用得多。

Agent 测试框架：把流程拆成可验证的步骤

Agent 测试和传统接口测试差别最大的是状态保持和工具链交互。我通常用pytest搭底座，结合简单的结构化日志做链路追踪，封装一个轻量级的测试基类。下面是一个实际项目中用的框架骨架，可以直接复用：

import pytest from typing import Dict, List import json class AgentTestCase: def __init__(self, trace_id: str): self.trace_id = trace_id self.steps: List[Dict] = [] self.tool_calls: List[str] = [] def add_step(self, step_name: str, expected_output_schema: dict): """记录预期输出结构，用于后续断言""" self.steps.append({"name": step_name, "schema": expected_output_schema}) def validate_tool_call(self, call_log: str): """检查工具调用是否符合安全白名单""" if "execute_system_command" in call_log: pytest.fail(f"[{self.trace_id}] 违规调用系统命令") self.tool_calls.append(call_log) @pytest.mark.agent_test def test_rag_agent_chain(): # 1. 构造带 Trace ID 的测试上下文 tc = AgentTestCase(trace_id="RAG-TEST-001") # 2. 定义节点契约 tc.add_step("intent_recognition", {"type": "object", "properties": {"query": {"type": "string"}, "confidence": {"type": "number"}}}) tc.add_step("knowledge_retrieval", {"type": "array", "items": {"type": "object", "properties": {"source": {"type": "string"}, "content": {"type": "string"}}}}) # 3. 模拟 Agent 执行过程（实际项目中替换为真实 SDK 调用） mock_response = { "intent": {"query": "如何重置密码", "confidence": 0.92}, "retrieved_docs": [{"source": "kb_001", "content": "请登录控制台点击..."}], "final_answer": "请点击控制台安全设置进行重置。" } # 4. 执行校验 tc.validate_tool_call(json.dumps(mock_response)) assert isinstance(mock_response["intent"]["confidence"], float), "置信度类型错误" print(f"[{tc.trace_id}] 链路校验通过，工具调用安全。")

这段代码看着简单，但把 Agent 测试的关键动作剥离出来了：轨迹记录、工具调用拦截、Schema 强校验。很多同行直接拿 LLM API 返回的文本做正则匹配，一旦模型换个说法就全挂。用 JSON Schema 约束中间态和最终态，测试的稳定性能提升一个量级。框架跑通后，再往里灌业务数据，调试起来就很顺手。

质量评估：别拿准确率当唯一指标

跑通了自动化，最后一步是定评估标准。早期做 Demo 时，大家喜欢盯着准确率或相似度分数看。但生产环境里，这些指标经常失真。模型答对了但引用了过期文档，或者答错了但态度诚恳且引导到了人工客服，业务方根本不买账。

我现在的评估维度拆成四层：事实准确性、安全性、可用性、成本效率。事实层靠人工抽检加规则引擎校验引用来源；安全层跑对抗样本库，看会不会输出违规内容或泄露 prompt；可用层看响应时间和 Token 消耗是否在 SLA 内；成本层算单次交互的边际成本。

具体落地时，建议建一个 Golden Dataset，包含 200-500 条覆盖各核心场景的高质量问答对。每次模型迭代或 Prompt 调整后，先跑一遍 Golden Set，对比指标波动。如果准确率降了 2%，但幻觉率降了 10%，这个改动可能就是值得上的。测试工程师的价值，这时候就体现在敢于用多维数据替业务决策背书，而不是只报一个干巴巴的通过率。

总结与练习路线

从传统测试转到 AI 质量工程，本质是从“验证确定性流程”转向“管理概率性输出”。别一上来就啃底层论文，先把工程底座补齐。按这个顺序练，效果最快：

1. 第一周：把现有项目的接口测试脚本改造成支持 JSON Schema 断言，熟悉pydantic或jsonschema库，习惯把“字符串匹配”升级为“结构校验”。
2. 第二周：搭一套基础的可观测链路。用自定义 Logger 或 OpenTelemetry，把一次 LLM 请求的 Prompt、Embedding、Retrieval、Generation 全记录下来，存入日志系统。
3. 第三周：整理 Golden Dataset。找业务要历史工单或优秀回答，清洗成结构化测试集，写脚本跑回归，建立基线。
4. 第四周：尝试 Agent 测试框架。参考上面的骨架，把工具调用拦截和权限校验写进去，覆盖 3 个核心业务流，跑通 CI 集成。

简历上别写“精通大模型测试”，改成“基于 JSON Schema 构建 Agent 输出校验流水线，集成链路追踪实现全日志可观测，黄金数据集回归通过率稳定在 98% 以上”。项目复盘时，重点讲你怎么把不可控的模型输出收敛到可衡量的工程指标，以及权限、日志、监控这些平时容易被忽略但