聊《测试转大模型，真正值钱的为什么不是会调 API？》之前，先说一句实在的：别急着背概念，先看它在真实项目里到底解决什么问题。

摘要

摘要：很多人以为测试转大模型就是学会调 API、写 Prompt，但真正让我在项目里栽跟头的，是联调时才发现的权限越权和日志盲区。本文复盘一次 Agent 联调失败的真实排查过程，讲清楚测试工程师转大模型质量工程时，真正需要补的不是算法，而是权限、日志和可观测性。

---

目录

1. 测试岗位的新变化，不是换个工具那么简单
2. AI 辅助测试：Demo 跑通只是起点
3. 自动化用例生成，别只盯着覆盖率
4. Agent 测试框架：联调失败的那次复盘
5. 质量评估：从功能正确到行为可观测
6. 总结：测试转大模型，真正值钱的不是会调 API

---

1. 测试岗位的新变化

去年开始，团队里陆续有测试同学转去做大模型相关的质量保障。表面看，技能迁移很顺畅——单元测试、接口测试、回归测试的思路都能复用。但真正进项目一个月后，问题就暴露了。

以前的测试对象是确定性的：输入 A 必然输出 B，边界值清楚，异常路径可枚举。大模型应用不一样，同一个 Prompt，不同模型版本、不同参数、不同上下文，输出可能天差地别。更关键的是，很多失败不是模型本身的问题，而是工程化层面的缺失。

我见过最典型的情况：Demo 阶段一切正常，联调时直接崩盘。排查两天，最后发现是权限配置不对——Agent 调用了不该访问的接口，但日志里根本没记录这次调用，监控上也看不到异常。测试同学翻遍了用例，都没找到问题根因。

这不是能力问题，是责任边界变了。以前测试关注的是"功能对不对"，现在还要关注"系统行为可不可观测"。

---

2. AI 辅助测试

AI 辅助测试这两年很火，各种工具宣称能自动生成用例、自动修复 Bug。但我的经验是：工具能提效，但不能替代判断。

举个实际场景。我们有一个 RAG 问答系统，用 AI 自动生成测试用例。工具确实跑出来了几十条，覆盖了好几种查询方式。但联调时才发现，这些用例都是"正常路径"，没有覆盖权限边界。

比如，普通用户查询"我的订单"，系统会带上用户 ID 去检索。但 Demo 阶段用的是管理员账号，所有数据都能查到。联调时换成普通用户，返回结果是空的——不是模型错了，是权限过滤没生效。

这时候 AI 生成的用例帮不上忙，因为它不知道权限规则的存在。测试工程师的价值，恰恰在于理解业务规则，发现这些"隐性约束"。

我现在的做法是：让 AI 生成基础用例，然后人工补充边界场景。特别是权限相关的场景，必须逐个验证。

---

3. 自动化用例生成

自动化用例生成是测试转大模型的常见切入点。很多人以为学会了用工具生成用例就算转型成功，但实际项目里，生成容易，验证难。

我们有一个 Agent 应用，测试同学用工具生成了 200 多条自动化用例，覆盖率看起来不错。但上线后，用户反馈频繁出现"权限不足"的报错。排查后发现，这些用例都是内部测试账号运行的，没有模拟真实用户的权限差异。

这个问题在 Demo 阶段根本发现不了。因为 Demo 通常用管理员权限跑，所有功能都能用。真正的问题在于：测试环境和生产环境的权限配置不一致。

我的建议是：

• 自动化用例生成只是第一步，关键是建立权限测试矩阵
• 每个用户角色都要有对应的测试账号
• 用例要覆盖"有权访问"和"无权访问"两种情况

下面是一个简单的权限测试用例结构，供参考：

# 权限测试用例模板
class AgentPermissionTest:
    def __init__(self, user_role: str, resource: str, expected: str):
        self.user_role = user_role
        self.resource = resource
        self.expected = expected

    def test_access(self, agent_client, user_token):
        """验证用户是否有权限访问指定资源"""
        response = agent_client.query(
            user_token=user_token,
            query=f"查询{self.resource}",
            role=self.user_role
        )

        # 关键：不仅要检查返回内容，还要检查日志记录
        log_entry = self._check_log(user_token, self.resource)

        if self.expected == "allowed":
            assert response.status == 200
            assert log_entry.has_record  # 有权访问必须有日志
        else:
            assert response.status == 403
            assert log_entry.action_logged  # 无权访问也要有日志

这个例子的核心是：权限测试不仅要验证接口返回，还要验证日志记录是否完整。很多团队只做了前半部分，导致联调时才发现日志缺失。

---

4. Agent 测试框架

这是本文想重点讲的部分。去年我们有一个 Agent 项目，联调时直接翻车。测试同学按之前的经验，用自动化框架跑了一遍用例，全部通过。但上线后，用户反馈系统经常"卡住"。

排查过程花了两天。问题最终定位在：Agent 在调用下游服务时，没有正确的权限校验，导致某些请求被拒绝，但日志里没有记录失败原因。

让我把排查路径还原一下：

第一步：复现问题
用户反馈"卡住"，我们先用管理员账号复现，发现调用链正常。换成普通用户，问题复现了。

第二步：检查日志
日志里只有成功调用的记录，没有失败记录。这说明 Agent 调用下游服务时，失败了但没有正确记录。

第三步：定位代码
检查 Agent 的代码，发现调用下游服务时没有 try-catch，异常被吞掉了。

第四步：补充日志
加上异常捕获和日志记录，问题解决了。

但这个过程暴露了一个更深层的问题：测试框架没有覆盖"日志完整性"这个维度。

我们用的测试框架主要关注功能正确性，没有验证日志是否记录了关键操作。这次联调失败后，我们重新设计了测试框架，增加了日志验证环节：

# 日志验证测试用例
class LogObservabilityTest:
    def test_call_logged(self, user_token, resource, expected_action):
        """验证每次调用都有日志记录"""
        # 执行操作
        response = agent_client.query(user_token=user_token, query=f"查询{resource}")

        # 验证日志
        logs = log_client.query(
            user_token=user_token,
            resource=resource,
            time_range=get_recent_time_range()
        )

        assert len(logs) > 0, f"日志未记录：{resource}"
        assert logs[0].action == expected_action
        assert logs[0].has_error_field  # 必须有错误字段，即使没有错误

这个测试用例的核心是：不仅要验证功能，还要验证可观测性。日志不完整，联调时就会找不到问题根因。

---

5. 质量评估

测试转大模型，质量评估的标准也变了。以前看的是功能覆盖率、Bug 数、回归通过率。现在还要看：

• 权限覆盖率：每个用户角色是否都有对应的测试用例
• 日志完整性：关键操作是否都有日志记录
• 可观测性：出现问题时，能否快速定位根因

我们团队现在的质量评估标准是：

1. 功能测试：用例通过率 100%
2. 权限测试：每个角色至少覆盖 3 个核心场景
3. 日志测试：关键操作日志覆盖率 100%，异常日志必须有错误码和堆栈
4. 可观测性测试：模拟故障时，日志和监控能正确反映问题

这个标准比之前严格了很多，但确实能提前发现问题。上次联调，因为有日志测试，提前发现了 3 个日志缺失的问题，避免了上线后的故障。

---

6. 总结

测试转大模型，真正值钱的不是会调 API，而是理解系统行为、建立可观测性、发现隐性约束。

我的建议是：

1. 不要只盯着模型本身，大模型应用的质量问题往往在工程化层面
2. 补上权限和日志的课，这是联调时最容易翻车的地方
3. 建立新的测试标准，功能正确只是底线，可观测性才是竞争力

上次联调失败后，我在团队里推了一个变更：所有 Agent 项目必须通过日志测试才能上线。这个规定让后续项目少走了很多弯路。

测试转大模型不是换个工具那么简单，是责任边界的扩展。以前你只对功能负责，现在你还要对系统的可观测性负责。这个转变不容易，但确实能提升你的竞争力。

如果你正在考虑转型，建议先从权限测试和日志测试入手，这两块是 Demo 和联调之间最大的鸿沟。

总结

本文完成了关键概念、工程实践和落地建议的梳理。

资料展示

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

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