测试转大模型：从一次踩坑讲到改进-育师

《测试转大模型，真正值钱的为什么不是会调 API？》看起来是个大话题，但真落到项目里，常常就是几个具体选择。下面我尽量按实际开发时会遇到的问题来讲。

摘要

> 摘要：从一个 Demo 到生产环境，权限与日志才是决定 AI 测试工程师能否真正落地的关键。本文通过一次需求评审的实战经历，探讨测试工程师如何在大模型时代实现能力跃迁，重点聚焦于权限控制、日志可观测性与验收标准的制定。

---

一、测试岗位的新变化：从“用例覆盖”到“边界控制”
二、AI 辅助测试：不是替代，而是增强
三、自动化用例生成：别信“全自动”
四、Agent 测试框架：权限与日志是“硬约束”
五、质量评估：从“准确率”到“可解释性”
六、总结：真正值钱的，是“边界控制力”

一、测试岗位的新变化：从“用例覆盖”到“边界控制”

过去，测试工程师的 KPI 是“用例覆盖率”、“Bug 率”、“自动化脚本数量”。但现在，随着大模型和 Agent 进入生产环境，测试的重点已经从“功能对不对”转向“系统稳不稳、可不可控”。

上周，我参与了一个内部 Agent 项目的需求评审。团队想实现一个“自动审批助手”，能根据合同条款自动判断是否符合公司政策。Demo 阶段跑得很顺，模型输出准确率 92%。但到了验收阶段，问题暴露了：

模型误判了敏感字段，把“机密合同”当成“普通文档”处理；
没有权限隔离，测试账号能访问生产数据；
日志里只记录了“调用成功”，没有记录输入/输出内容，无法追溯。

最终项目被叫停，不是因为模型不准，而是因为“不可控”。

这说明：大模型测试的核心，不再是测试模型的能力，而是测试系统的边界控制能力。

---

二、AI 辅助测试：不是替代，而是增强

很多人觉得“AI 测试”就是用 AI 写用例、生成脚本。其实，AI 辅助测试更关键的角色是“边界探测者”。

比如，一个 Agent 能自动调用多个 API，但每个 API 的权限、频率、输入格式都不同。这时候，测试工程师需要设计“攻击性用例”来探测系统边界：

输入超长的文本，看模型是否会泄露上下文；
模拟低权限用户调用高权限接口，看是否被拦截；
在日志中插入特殊字符，测试日志是否被正确记录或过滤。

这些用例不是靠 AI 生成的，而是靠测试工程师对系统边界的理解。

---

三、自动化用例生成：别信“全自动”

最近有个热门话题：“用 LLM 生成测试用例”。听起来很美好，但实际落地时你会发现：

LLM 生成的用例往往“太标准”，缺乏边界测试；
它不知道系统权限模型，也不会考虑日志完整性；
生成的用例无法覆盖“异常路径”和“安全漏洞”。

我的建议是：用 LLM 生成“基础用例”，人工补充“边界用例”和“安全用例”。

比如，下面是一个用 LLM 生成的测试用例（简化版）：

def test_model_accuracy(): input_text = "请批准金额为 5000 元的报销申请。" expected_output = "批准" assert model.predict(input_text) == expected_output

这个用例只能验证模型“能不能正确识别普通场景”，但无法验证：

模型是否会泄露敏感信息？
是否会被恶意输入绕过权限校验？
日志中是否记录了输入和输出？

这些需要测试工程师手动设计。

---

四、Agent 测试框架：权限与日志是“硬约束”

一个成熟的 Agent 测试框架，必须把“权限控制”和“日志可观测性”作为核心模块，而不是事后补救。

举个实际例子：我们在测试一个“自动客服 Agent”时，发现它会在没有权限的情况下调用用户数据库接口。于是我们加了一个前置校验模块：

def check_permission(user_role, action): if user_role == "guest" and action in ["delete", "modify"]: raise PermissionError("Guest user cannot perform sensitive actions") return True

同时，我们要求所有 Agent 调用必须记录以下信息到日志中：

{ "timestamp": "2026-07-29T10:23:45Z", "agent_id": "auto_cassie_v2", "input_text": "请删除用户 A 的订单。", "output_text": "已删除订单 #12345", "user_role": "admin", "permission_checked": true, "log_level": "info" }

没有这些信息，Agent 就“不可观测”，也就“不可控”。

---

五、质量评估：从“准确率”到“可解释性”

以前我们评估测试质量，看的是“通过率”、“Bug 数”。现在，对于大模型系统，质量评估还要看：

模型输出是否可解释？（比如，为什么它判定这个合同违规？）
权限控制是否有效？（低权限用户是否真的无法访问敏感数据？）
日志是否完整？（能否通过日志回溯整个决策链？）

我们引入了一套“可观测性评分”：

| 维度 | 评分标准 | 权重 |
|------|----------|------|
| 权限控制 | 是否对所有接口进行权限校验 | 30% |
| 日志完整性 | 是否记录输入、输出、用户角色、时间戳 | 30% |
| 可解释性 | 是否能输出判定理由 | 20% |
| 异常处理 | 是否能优雅处理模型错误 | 20% |

只有总分达到 80 分，Agent 才能进入灰度发布。

---