当前位置：首页 > news >正文

测试转大模型：从上线前检查开始讲

news 2026/8/4 12:54:59

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

摘要

从传统测试转大模型质量工程，很多人以为会调 API、会写 Prompt 就够了。但真实项目里，最头疼的从来不是模型能力，而是权限边界、日志可观测性和上线后的质量守门。本文以一次需求评审开场，拆解测试工程师在大模型项目中的能力跃迁路径，给出可落地的实战建议。

---

一次需求评审，暴露了 Demo 和上线的鸿沟
测试岗位的新变化：从验证结果到守护边界
AI 辅助测试：不是替代，是放大
自动化用例生成：从模板到上下文感知
Agent 测试框架：可观测性才是基础设施
质量评估：用权限和日志重新定义验收标准
总结：测试工程师的价值跃迁在哪里

---

一次需求评审，暴露了 Demo 和上线的鸿沟

上周一场需求评审，产品经理说："AI 客服助手能自动查订单、退款，用户满意度能提升 30%。" 技术负责人追问："权限怎么管？日志能追溯到具体调用链吗？异常 fallback 是什么？" 产品经理愣了一下，说："这个……后面再说。"

会场上没人接话。

这就是 Demo 和上线的鸿沟。Demo 阶段，模型能跑、接口能通、结果看起来合理，就敢往前冲。但一旦进入生产环境，权限越界、日志断链、异常兜底缺失，问题会集中爆发。测试工程师在这里的角色，不再是"验证功能对不对"，而是"守护边界能不能守得住"。

---

测试岗位的新变化：从验证结果到守护边界

传统测试关注的是输入输出是否匹配预期。大模型测试的输入是自然语言，输出是概率分布，传统的确定性验证逻辑在这里失效。

我接触的几个项目里，测试团队面临三个新挑战：

第一，用例不再是固定的。同一个问题，模型每次返回可能不同。测试需要从"验证结果"转向"验证边界"——输出是否在安全范围内、是否越权、是否符合业务约束。

第二，可观测性成为刚需。传统系统的日志是结构化的，大模型系统的日志包含 Prompt、Token 消耗、模型调用链、权限上下文。测试需要理解这些日志，才能定位问题是出在模型侧、权限侧还是业务逻辑侧。

第三，权限成为第一道防线。大模型应用的核心风险不是模型幻觉，而是权限越界——模型被诱导执行了不该执行的操作。测试需要验证权限边界，而不是只验证功能正确性。

---

AI 辅助测试：不是替代，是放大

很多人担心 AI 会替代测试工程师。我的判断是：AI 替代的是"写用例"这个动作，但替代不了"判断边界"这个能力。

实际项目中，我用 AI 辅助做了这几件事：

用例生成辅助。传统测试写用例需要人工拆解场景，现在可以用 AI 快速生成场景列表，然后人工审核边界条件。比如对于一个退款功能，AI 能生成"正常退款、超时退款、部分退款、权限不足退款"等场景，但"权限不足时是否正确拒绝"这个边界，需要人工判断。

日志分析辅助。上线后出现异常，传统做法是人工逐条看日志。现在可以用 AI 辅助分析，快速定位异常调用链。但关键是：测试工程师需要理解日志结构，知道该让 AI 分析什么。

# 用 AI 辅助分析日志的示例思路 def analyze_model_log(log_entry): """ 解析大模型调用日志，提取关键信息 """ # 日志结构示例： # { # "trace_id": "abc123", # "prompt": "帮我查询用户 U12345 的订单", # "model": "gpt-4", # "tokens": 150, # "permission_context": {"user_id": "U12345", "role": "customer"}, # "output": "订单列表：...", # "fallback": null # } key_fields = ["trace_id", "permission_context", "fallback"] analysis = {field: log_entry.get(field) for field in key_fields} # 判断是否存在权限越界风险 if analysis["permission_context"].get("role") == "customer": if "删除" in log_entry.get("prompt", ""): analysis["risk"] = "权限越界：普通用户尝试删除操作" return analysis

提示词优化辅助。测试需要验证 Prompt 的稳定性，可以用 AI 辅助生成边界 Prompt，测试模型的鲁棒性。

---

自动化用例生成：从模板到上下文感知

传统自动化测试的核心是"输入-预期输出"的映射。大模型测试的自动化需要引入"上下文感知"。

我参与的一个项目中，自动化测试框架做了这样的设计：

场景库驱动。不是硬编码用例，而是维护一个场景库，每个场景包含输入、权限上下文、预期边界。

动态断言。不再断言"输出等于某个值"，而是断言"输出符合业务约束"。比如退款金额不能超过订单总额、不能访问非授权用户的数据。

回归测试策略。大模型版本更新后，用边界用例集做回归，而不是全量用例。

# 上下文感知的自动化测试框架示例 class ContextAwareTestCase: def __init__(self, scenario, permission_context, expected_boundary): self.scenario = scenario self.permission_context = permission_context self.expected_boundary = expected_boundary def execute(self, model_client): # 构造带权限上下文的请求 request = { "prompt": self.scenario["prompt"], "permission": self.permission_context } response = model_client.call(request) # 动态断言：检查是否越界 violations = self.check_boundary(response) return { "passed": len(violations) == 0, "violations": violations, "response": response } def check_boundary(self, response): violations = [] # 检查权限边界 if response.get("action") in self.expected_boundary["forbidden_actions"]: violations.append(f"越权操作: {response.get('action')}") # 检查数据边界 if response.get("data_scope") not in self.expected_boundary["allowed_data_scope"]: violations.append(f"数据越界: {response.get('data_scope')}") return violations

---

Agent 测试框架：可观测性才是基础设施

Agent 系统的测试比传统系统更复杂，因为 Agent 有自主决策能力，行为路径不固定。我总结了一个原则：可观测性先于自动化。

一个可观测的 Agent 测试框架需要：

Trace 追踪。每次 Agent 决策都要有完整的调用链追踪，包括思考过程、工具调用、权限验证结果。

日志结构化。日志需要包含 trace_id、权限上下文、模型版本、Token 消耗等关键字段，方便后续分析。

异常兜底记录。 Agent 遇到异常时的 fallback 行为必须记录，这是定位问题的关键。

# 可观测性日志结构示例 observed_log = { "trace_id": "agent_trace_001", "timestamp": "2026-08-01T10:30:00Z", "agent_id": "refund_agent_v2", "model_version": "gpt-4-2024-11", "permission_context": { "user_id": "U12345", "role": "customer", "permissions": ["query_order", "refund_own"] }, "decision_chain": [ { "step": 1, "thought": "用户请求退款订单 O67890", "tool_called": "query_permission", "tool_result": {"allowed": True, "reason": "用户有退款自己订单的权限"} }, { "step": 2, "thought": "查询订单详情", "tool_called": "get_order", "tool_result": {"order": {"id": "O67890", "amount": 299, "status": "shipped"}} }, { "step": 3, "thought": "订单已发货，检查退款政策", "tool_called": "check_refund_policy", "tool_result": {"can_refund": True, "reason": "发货7天内可退"} } ], "final_action": "process_refund", "fallback_triggered": False, "tokens_used": 320 }

---