测试转大模型：把学习路径落到证据

关注

原创最新推荐文章于 2026-11-07 11:36:14 发布 409 阅读 AI 写同款· GEO 优化 ›

聊《大模型岗位变了，测试工程师该补的还是算法吗？》之前，先说一句实在的：别急着背概念，先看它在真实项目里到底解决什么问题。

摘要

去年我带的一个大模型项目上线那天，测试的同学说"Demo 能跑通，应该没问题"。结果业务方提了一个需求变更：要限制某些用户只能访问特定知识库。代码改了之后，线上第一个月直接崩了三次。排查下来发现，问题不在模型，不在 Prompt，而是权限校验逻辑根本没进测试用例，日志也没打到关键节点。

这件事让我意识到，测试工程师转大模型，补的不是算法，是工程化思维。

---

测试岗位的新变化

文章插图 1

很多人以为转大模型方向，就是要学 PyTorch、背 Transformer 原理。我接触过十几个从传统测试转过来的同学，真正在项目里用得上的，反而是一些看似"边缘"的能力：日志分析、权限边界设计、可观测性验证。

业务方现在提需求，不再只问"这个功能能不能跑通"，而是问"权限够不够细、日志能不能追溯、出错了能不能定位"。这三个问题的答案，决定了你的测试方案能不能覆盖真实场景。

我见过一个典型反例：某同学用 LangChain 搭了一个 RAG 应用，测试时只验证了问答准确率，没考虑权限隔离。上线后不同租户之间数据串了，业务方直接投诉。这种问题，传统功能测试根本发现不了。

真实案例

文章插图 2

去年 Q3，我们接手了一个金融类内部知识库项目。技术栈是 LangChain + Milvus + 自研权限网关。项目背景是合规要求：不同部门的员工只能查询本部门的知识文档，且审计日志需要留存至少一年。

输入：系统需要支持三类用户——普通员工（只能看本部门文档）、部门主管（可以看本部门+关联部门）、合规审计员（可以查看全部，但有操作留痕）。

步骤：
1. 开发同学实现了基础的 RBAC 权限模型
2. 测试同学按照功能用例验证了问答准确率，达到 92%
3. 上线后发现，主管用户通过修改请求参数，能查到跨部门文档

可观察结果：我们在权限网关的日志里看到，有个用户角色是"主管"，但他查询请求里的 department_id 被篡改成了其他部门的 ID。模型侧根本没有做二次校验，完全信任了上游传来的参数。

这个 case 暴露了一个问题：测试时只验证了"正常路径"，没有构造权限越界的输入。如果当时用例里有一条是"主管用户传入其他部门 ID 查询"，这个问题在上线前就能发现。

后来我们在测试框架里加了权限矩阵验证，类似下面的工具函数——这也是为什么接下来要详细讲代码解释的部分，这段逻辑在实际项目中反复出现过。

AI 辅助测试

现在的测试工作流里，AI 辅助已经渗透到了用例生成、日志分析、失败复现多个环节。但工具只是工具，关键是你怎么用。

实战中我习惯用 AI 生成一批边界用例，然后人工判断哪些是真正有意义的。比如一个文档问答系统，AI 会生成"输入空字符串""输入超长文本""输入特殊字符"这类用例。这些没问题，但更有价值的是："未授权用户访问私有知识库""高权限用户降级为普通用户后能否继续访问"这类涉及权限变迁的场景。

这里有一个真实案例：我们曾测试一个基于 Agent 的内部系统，需求是让 Agent 自主调用多个微服务完成工单处理。AI 辅助生成的用例覆盖了功能正确性，但漏掉了权限降级后的行为。排查时发现，一个从管理员降为普通用户的账号，Agent 仍然保留了之前的服务调用能力。这个问题要不是上线前做了一次权限矩阵对比测试，根本发现不了。

自动化用例生成

自动化用例生成是 AI 辅助测试里最成熟的应用，但我见过太多团队踩坑。

常见的问题是：用 AI 生成的用例数量很大，但重复度高、边界覆盖不全。我的做法是先定义清楚测试维度，再让 AI 按维度生成，最后人工过滤。

下面这个代码片段是我在实际项目里用的 Prompt 模板，用来生成权限相关的测试用例：

import openai
from typing import List, Dict, Any

def generate_permission_cases(model_type: str, roles: List[str], data_sensitivity: List[str]) -> List[Dict[str, str]]:
    """
    输入: model_type - 模型类型(RAG/Agent/纯问答)
          roles - 角色列表(如['admin','user','guest'])
          data_sensitivity - 数据敏感度等级(如['public','private','confidential'])
    输出: 权限相关测试用例列表，每个用例包含场景描述、预期结果和风险等级
    """
    # 构建权限变迁场景列表，覆盖动态权限变化
    dynamic_scenarios = [
        "角色A访问角色B的数据",
        "角色权限变更后的持续访问",
        "未认证用户尝试访问",
        "高权限用户降级后的行为",
        "并发请求中的权限竞争"
    ]

    prompt = f"""
    针对一个{model_type}系统，生成以下角色的权限测试用例：
    角色：{roles}
    数据敏感度：{data_sensitivity}

    请生成覆盖以下场景的用例：
    {chr(10).join(f'{i+1}. {s}' for i, s in enumerate(dynamic_scenarios))}

    格式：用例编号 | 场景描述 | 预期结果 | 风险等级
    """
    try:
        response = openai.ChatCompletion.create(
            model="gpt-4",
            messages=[{"role": "user", "content": prompt}],
            timeout=30
        )
        cases = parse_cases(response.choices[0].message.content)
        return cases
    except openai.error.Timeout:
        raise RuntimeError("AI 生成超时，请检查网络连接或降低并发")
    except openai.error.APIError as e:
        raise RuntimeError(f"AI API 错误: {e}")
    except Exception as e:
        raise RuntimeError(f"未知错误: {e}")

def parse_cases(raw_output: str) -> List[Dict[str, str]]:
    """解析 AI 返回的原始文本为结构化用例"""
    cases = []
    for line in raw_output.strip().split('\n'):
        parts = [p.strip() for p in line.split('|')]
        if len(parts) >= 4:
            cases.append({
                "id": parts[0],
                "scenario": parts[1],
                "expected": parts[2],
                "risk": parts[3]
            })
    return cases

代码解释

这段关键代码实现了一个权限测试用例的自动生成管道，我来逐段拆解它的实现原理。

输入处理部分：函数接收三个参数——model_type 定义被测系统的类型，roles 是需要覆盖的角色集合，data_sensitivity 是数据敏感等级列表。这三个参数决定了用例的覆盖范围。如果角色列表为空或者数据敏感度等级缺失，后续 Prompt 会生成大量泛化用例，意义不大。

动态场景构建：dynamic_scenarios 列表是这段代码的核心价值所在。它强制覆盖五个权限变迁场景，其中"角色权限变更后的持续访问"和"高权限用户降级后的行为"是两个最容易漏掉的点。很多团队的 Prompt 只问"生成权限测试用例"，结果 AI 就按角色×数据敏感度做一个笛卡尔积，生出一堆静态用例。但真实系统里，权限是动态变化的——用户会入职、转岗、离职，这就是问题的来源。

输出解析：parse_cases 函数负责把 AI 返回的原始文本拆成结构化用例。这里有一个容易忽略的细节——用 chr(10) 来拼接场景列表而不是直接写 \n，是因为 Prompt 模板本身已经包含换行符，嵌套换行会导致格式错乱。输出结果是字典列表，每个字典包含用例编号、场景描述、预期结果和风险等级四个字段，方便后续导入测试管理平台。

异常处理：三段 except 分别处理超时、API 错误和未知异常。超时的情况在实际项目中很常见，AI 生成大量用例时容易触发限流，这时应该给明确的错误提示而不是让测试静默失败。

优快云资料领取方式

Agent 测试框架

Agent 类应用的测试比传统 RAG 复杂得多。传统测试关注输入输出是否正确，Agent 测试还要关注执行路径是否合规、工具调用是否符合权限策略、中间状态是否可追溯。

我最近在用的测试框架思路是三层验证：功能层验证 Agent 最终输出是否正确，过程层验证工具调用链是否合规，可观测层验证日志是否覆盖关键决策节点。

一个典型失败原因是：测试只关注了功能正确性，Agent 在调用外部 API 时绕过了权限检查。比如我们测试过一个工单处理 Agent，它能自主调用创建工单、分配工程师、更新状态三个工具。功能测试全部通过，但上线后发现有用户通过构造特殊输入，让 Agent 调用了"删除工单"这个不应该被普通用户触发的工具。

这个问题的根本原因是测试框架设计时只考虑了正向流程，没有建立权限门禁的测试覆盖。

排查过程

上次提到那个主管用户篡改部门 ID 的问题，排查过程其实走了不少弯路，记录一下完整的故障定位链路。

现象：上线第三天，合规部门举报有数据泄露风险。后台日志显示，某个主管角色用户查询了不属于本部门的客户信息。

验证动作：
1. 第一步先看应用日志，确认请求确实到达了模型层，问答结果也没有异常
2. 第二步检查权限网关日志，发现这个请求的 department_id 参数与用户实际所属部门不一致
3. 第三步追踪到模型侧的 Input Schema，发现模型接收了 department_id 但没有做二次校验
4. 第四步对比代码提交记录，发现权限校验逻辑只在网关层，模型层完全没有感知

排除结果：不是模型幻觉，也不是网关 bug，是测试用例根本没覆盖"用户篡改参数"这个场景。当时用的 AI 生成用例，只覆盖了正常角色和正常参数的组合，没有构造权限越界的输入。

这个排查过程最大的教训是：权限问题的根因往往不在代码本身，而在测试覆盖的盲区。代码是对的，用例是错的。