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

测试转大模型：Demo 跑通了，权限日志才是真实门槛

news 2026/8/4 23:15:08

聊《同样转大模型，测试背景的优势和短板分别是什么？》之前，先说一句实在的：别急着背概念，先看它在真实项目里到底解决什么问题。

摘要

摘要：从功能测试转做 AI 测试，很多人以为学会了写 prompt 和调 API 就万事大吉。但真正让我踩坑的，不是用例怎么写，而是权限、日志、可观测这些" boring 工程"。本文复盘我从自动化测试转向大模型质量保障的真实路径，给出一个可落地的学习顺序——哪些先补，哪些暂时放一放。

---

测试岗位的新变化：从边界到概率
AI 辅助测试：别急着学框架，先搞清楚你在测什么
自动化用例生成：从 deterministic 到 probabilistic
Agent 测试框架：权限和日志才是生产环境的生死线
质量评估：跑分高不等于能干活
总结：测试背景的优势和短板

---

测试岗位的新变化：从边界到概率
AI 辅助测试：别急着学框架，先搞清楚你在测什么
自动化用例生成：从 deterministic 到 probabilistic
Agent 测试框架：权限和日志才是生产环境的生死线
质量评估：跑分高不等于能干活
总结：测试背景的优势和短板

测试岗位的新变化：从边界到概率

我做测试出身，过去十年干的最多的事情就是定义边界：输入是什么、预期是什么、异常怎么处理。这套思维在大模型时代并不过时，但有个根本性的变化——结果从确定变成了概率。

以前我测一个接口，传同样的参数，返回一定一样。现在同样的 prompt，同一个模型，可能每次输出都不一样。这意味着什么？意味着传统的"预期输出匹配"那套方法，在大模型场景下直接失效了。

我刚开始转的时候，也走过弯路。以为学会了写 few-shot prompt、会调几个 API 就能做 AI 测试了。后来接了一个真实项目才发现，能写 prompt 的人很多，但能把 AI 系统的质量保障做扎实的人很少。差距不在 prompt 工程，而在工程化能力。

具体来说，测试背景的人有几个天然优势：

1. 对边界条件的敏感度：大模型应用的异常输入、越权调用、上下文溢出，这些场景测试人员比开发更敏感
2. 对质量指标的量化习惯：准确率、召回率、F1 分数，这些指标在 AI 评估里依然适用
3. 对回归测试的理解：模型更新、prompt 变更、数据漂移，都需要回归策略

但短板也很明显：对权限、日志、可观测这些工程基础设施不够重视。很多人学 Agent 开发，上来就玩 LangGraph、玩工具调用，结果项目一上线，权限配错导致数据泄露，日志没有导致问题定位困难，可观测性缺失导致无法评估效果——这些坑我全都踩过。

---

AI 辅助测试：别急着学框架，先搞清楚你在测什么

现在市面上有很多 AI 辅助测试的工具：自动写用例、自动生成测试数据、智能分析失败原因。这些工具确实能提效，但我的建议是：不要一上来就追求工具链的完整，先搞清楚你在测什么。

以一个真实的 RAG 系统测试为例。很多人看到 RAG 就想着用工具自动生成测试用例，但实际上，RAG 系统的质量评估维度非常复杂：

检索质量：召回的文档是否相关？有没有噪声？
生成质量：模型的回答是否准确？有没有幻觉？
系统质量：响应时间、并发能力、权限控制

如果直接用 AI 工具生成用例，很可能只覆盖了"功能正确性"这一层，而忽略了权限和可观测性这些生产环境的关键维度。

我当时做的项目里，有一个场景是：用户通过 Agent 查询公司内部数据。测试时我只关注了"查询结果是否正确"，结果上线后出现了两个问题：

1. 普通员工能查询到高管薪酬数据——权限漏洞
2. 查询超时没有兜底，直接返回空结果——可观测性缺失

这两个问题，传统的功能测试完全覆盖不到。所以我后来调整了学习路线：先补工程化能力，再学 AI 测试框架。具体来说：

先搞懂 OAuth、RBAC 这些权限模型
先学会用 OpenTelemetry 做链路追踪
先理解日志的结构化规范和告警策略
然后再学 pytest-ai、LangSmith 这些测试框架

顺序反了，工具再先进也填不上工程化的坑。

---

自动化用例生成：从 deterministic 到 probabilistic

自动化测试是我原来的老本行。但大模型场景下，自动化用例的写法需要根本性的转变。

以前写自动化用例，核心是确定性：给定输入 A，预期输出 B。现在需要接受概率性：给定输入 A，输出可能是一个分布，我们需要评估这个分布是否在可接受范围内。

举个例子，我之前写过一个 LLM 输出评估的测试框架，核心思路是这样的：

import pytest from llm_evaluator import AnswerEvaluator class TestRAGSystem: @pytest.mark.parametrize("question,expected_keywords,unacceptable_hallucinations", [ ( "Q1: 公司2024年Q1营收是多少？", ["营收", "亿元", "同比"], # 答案中应该包含这些关键词 ["保密", "无法回答"], # 不应该出现这些表述（除非确实无法回答） ), ( "Q2: 帮我总结近三个月的销售数据", ["销售", "环比", "增长"], ["虚构", "不存在"], ), ]) def test_rag_answer_quality(self, question, expected_keywords, unacceptable_hallucinations): # 调用 RAG 系统 answer = rag_system.query(question) # 评估答案质量 evaluator = AnswerEvaluator( expected_keywords=expected_keywords, unacceptable_hallucinations=unacceptable_hallucinations, threshold=0.7 # 相似度阈值 ) result = evaluator.evaluate(answer) # 概率性断言：不要求完全匹配，而是评估质量分数 assert result.quality_score >= 0.7, f"答案质量过低: {answer}" assert not result.contains_hallucination, f"发现幻觉内容: {answer}"

这个例子里有几个关键转变：

1. 用关键词覆盖代替精确匹配：不再要求输出完全一致，而是检查关键信息是否包含
2. 引入阈值判断：质量分数低于阈值才失败，而不是二元判断
3. 关注负面案例：不仅要检查答案对不对，还要检查有没有幻觉

但这里有个坑：阈值怎么定？ 0.7 是拍脑袋还是数据驱动？我的经验是，先收集 100 个真实查询的评估分数，看分布情况，再定阈值。否则阈值设高了等于没测，设低了全是误报。

---

Agent 测试框架：权限和日志才是生产环境的生死线

这是我最想强调的部分。很多人在学 Agent 测试时， focus 在工具调用、记忆管理、任务规划这些"高级功能"上，但生产环境真正会崩的，往往是权限和日志。

我有一个朋友做了个内部知识问答 Agent，Demo 阶段非常漂亮：能理解问题、检索文档、生成回答。但上线一周后出现了问题：

1. 有员工发现可以通过构造特殊 prompt，让 Agent 返回其他部门的敏感数据
2. 出现响应超时，但监控没有告警，运维完全不知道发生了什么
3. 模型更新后，某些问题的回答质量下降，但没有人发现

这三个问题，对应三个工程化维度：

权限问题：Agent 调用工具时，有没有校验调用者的权限？检索文档时，有没有做数据隔离？

# 错误的做法：直接让 Agent 访问所有数据 agent = Agent(tools=[search_documents, query_database]) # 正确的做法：在工具层做权限校验 def search_documents(query: str, user_id: str) -> list: user_permissions = get_user_permissions(user_id) # 过滤掉用户无权访问的数据 results = database.query(query) return [r for r in results if r.access_level <= user_permissions.max_level] agent = Agent(tools=[ lambda q: search_documents(q, current_user_id) ])

日志问题：Agent 的每一步决策、每一次工具调用，有没有记录？日志结构是否规范？

import logging from opentelemetry import trace logger = logging.getLogger("agent.tracing") def run_agent_step(user_query: str, context: dict): # 结构化日志：便于后续分析 logger.info({ "event": "agent_step", "user_id": context["user_id"], "query": user_query, "timestamp": datetime.utcnow().isoformat(), "step": context.get("step_count", 0) }) # 链路追踪：便于定位性能瓶颈 with trace.get_tracer(__name__).start_as_current_span("agent_tool_call") as span: result = call_tool(context["current_tool"], context["tool_input"]) span.set_attribute("tool_name", context["current_tool"]) span.set_attribute("latency_ms", result["latency"]) return result

可观测性问题：模型质量下降时，能不能快速定位是模型问题、prompt 问题还是数据问题？

我后来做了一个简单的评估 pipeline：

# 每周自动评估模型质量 def weekly_quality_check(): test_cases = load_golden_dataset() # 人工标注的黄金测试集 results = [] for case in test_cases: answer = agent.run(case["question"]) score = evaluator.score(answer, case["ground_truth"]) results.append({ "question": case["question"], "answer": answer, "score": score, "model_version": get_current_model_version() }) # 如果平均分下降超过 5%，触发告警 avg_score = sum(r["score"] for r in results) / len(results) if avg_score < baseline_score * 0.95: alert_team(f"模型质量下降: {avg_score:.2f} < {baseline_score * 0.95:.2f}") return results

这套机制让我能在问题影响用户之前发现它，而不是等运维告警或者用户投诉。

---