《大模型岗位变了测试工程师该补的还是算法吗》看起来是个大话题但真落到项目里常常就是几个具体选择。下面我尽量按实际开发时会遇到的问题来讲。摘要最近跟几个做测试的朋友聊转型发现一个挺有意思的现象——大家都在学Agent、学LangChain简历上也堆了不少Demo项目但真正去面试AI质量工程岗位时聊到权限控制、日志可观测性很多人就卡壳了。今天复盘一下这个学习路线的断点说说从Demo到生产测试工程师真正需要补什么。---目录测试岗位的新变化真实案例Demo跑通的Agent上线后权限越界排查过程问题到底出在哪AI辅助测试别只学调API自动化用例生成关键在断言逻辑Agent测试框架可观测性才是核心代码解释失败原因业务、配置、环境三种错误怎么区分适用边界什么时候该学什么时候先放放总结---测试岗位的新变化先说结论大模型时代的测试不是在原来基础上加几个新工具而是整个质量保障的边界在迁移。传统软件测试关注的是确定性输入输出——给A必须出B。但大模型应用不一样输入稍微变一点输出可能天差地别。这意味着测试工程师不能只盯着功能对不对还得回答几个以前不常问的问题模型在不同边界条件下输出是否稳定工具调用有没有越权风险日志能不能追溯到具体的一次请求失败时是模型问题、配置问题还是环境问题这几个问题不是靠背几个测试框架就能答上来的。我见过不少朋友转型花大量时间学Prompt工程、学Agent框架简历上写了基于LangChain搭建多Agent系统但问到你们怎么测这个Agent的权限边界基本都答不上来。这不是他们不够努力是学习路线上有个明显的断点——Demo阶段根本遇不到这些问题。---真实案例Demo跑通的Agent上线后权限越界去年帮一个做内部知识库的团队做质量评估场景是这样的输入一个基于RAG的问答Agent用户可以通过自然语言查询公司内部文档系统会调用工具读取文件内容并回答。Demo阶段的表现用几个标准问题测试回答准确率85%以上工具调用链路完整日志清晰团队觉得可以上线了上线后的问题有员工通过构造特殊Prompt让Agent输出了不该看到的财务数据日志里看不到具体是哪个工具调用了什么敏感文件权限校验只在入口处做了一次中间环节没覆盖这个问题的核心不是模型能力不够而是测试阶段没有覆盖到权限边界。Demo里用的测试数据都是好人在问正常问题但真实场景里用户可能故意试探系统边界。---排查过程问题到底出在哪这个问题排查花了大概两天过程挺典型的第一步复现问题我们拿到了一条问题记录用户问帮我总结一下Q3的财务数据系统输出了包含具体金额的完整报表。正常情况下普通员工只能看到脱敏后的汇总数据不应该看到明细。第二步定位调用链看日志发现Agent调用了两个工具1.search_documents——搜索文档2.read_file——读取文件内容问题出在第二个工具。搜索阶段做了权限过滤但读取阶段没有再次校验当前用户是否有权限读取这份文件。第三步验证修复方案我们在read_file工具里加了一层权限校验async def read_file(file_id: str, user_id: str) - str: # 获取文件元数据 file_meta await get_file_metadata(file_id) # 校验用户权限 if not await check_user_permission(user_id, file_meta): raise PermissionError(fUser {user_id} cannot access file {file_id}) # 读取文件内容 content await load_file_content(file_id) return content加完这个校验后同样的问题问法系统返回的是您没有权限访问该文件而不是具体内容。第四步扩大测试范围修复后我们不是只测这一个点而是用不同权限级别的账号重复测试构造边界问题比如帮我看看隔壁部门的项目文档检查日志是否记录了每次权限校验的结果这个问题排查下来最关键的发现是Demo阶段的测试数据太干净了没有覆盖到权限边界场景。---AI辅助测试别只学调API很多人学AI测试第一步是调API写测试脚本。这没错但不够。真正有用的AI辅助测试应该覆盖三个层次第一层用例生成用模型根据需求描述自动生成测试用例。比如输入用户登录功能模型可以输出正常登录、密码错误、账号锁定等场景。这一层比较成熟很多工具已经做得不错了。第二层用例执行与结果分析模型执行测试用例分析输出结果是否符合预期。难点在于符合预期的判断——大模型输出是非确定性的同样的输入可能得到不同的结果。这时候需要引入概率判断比如80%的情况下输出应该包含关键词X。第三层边界与异常场景挖掘这是大多数人在Demo阶段忽略的。让模型主动构造边界输入、异常输入测试系统的鲁棒性。比如对一个问答系统可以让模型生成超长输入超过token限制恶意Prompt注入模糊问题跨权限的问题我见过一个团队用AI辅助测试做了权限边界挖掘生成了一组试探性问题发现了三个潜在的数据泄露风险点。这种用例人工测试很难想到。---自动化用例生成关键在断言逻辑自动化用例生成很多人卡在断言怎么写。传统测试的断言很直接输入A期望输出B检查输出是否等于B。大模型测试的断言复杂得多。比如一个客服Agent用户问我的订单什么时候到期望输出应该包含物流信息但具体措辞可能每次都不一样。这时候断言逻辑需要分层def assert_response_quality(response: str, expected_keywords: list[str]) - dict: result { passed: True, issues: [] } # 检查是否包含关键信息 for keyword in expected_keywords: if keyword.lower() not in response.lower(): result[passed] False result[issues].append(fMissing keyword: {keyword}) # 检查输出长度是否合理 if len(response) 20: result[passed] False result[issues].append(Response too short) # 检查是否包含敏感信息如密码、身份证号 sensitive_patterns [r\d{6}[\d*]{4}\d{4}, rpassword.*\d] for pattern in sensitive_patterns: if re.search(pattern, response): result[passed] False result[issues].append(Contains sensitive information) return result这段代码的逻辑是先检查关键信息是否包含再检查输出质量最后检查是否泄露敏感信息。断言的核心思路是不要期望输出完全一致而是检查输出是否满足一组约束条件。---Agent测试框架可观测性才是核心Agent测试和普通接口测试最大的区别在于Agent的执行过程是动态的、非线性的。一个Agent可能1. 接收用户输入2. 决定调用哪个工具3. 获取工具返回结果4. 决定下一步动作5. 最终生成回答这个过程如果缺少可观测性出问题时根本不知道卡在哪一步。我们团队现在做Agent测试强制要求每个步骤都有日志记录import logging logger logging.getLogger(__name__) async def agent_execute(user_input: str, context: dict) - str: logger.info(fAgent started. Input: {user_input}) # 步骤1理解用户意图 intent await parse_intent(user_input) logger.info(fIntent parsed: {intent}) # 步骤2决策工具调用 tools_to_call await decide_tools(intent, context) logger.info(fTools to call: {tools_to_call}) # 步骤3执行工具调用 tool_results {} for tool in tools_to_call: result await call_tool(tool, context) tool_results[tool.name] result logger.info(fTool {tool.name} result: {result[:100]}...) # 步骤4生成最终回答 response await generate_response(intent, tool_results) logger.info(fFinal response generated) return response日志里至少应该记录每一步的输入输出工具调用的参数和结果异常发生的具体位置有了这些日志排查问题才能有的放矢。否则Agent出错了这句话等于没说。---代码解释上面三处关键代码分别对应权限校验、断言逻辑和Agent执行流程。下面逐段拆解实现原理帮助理解代码背后的设计意图。权限校验代码read_file输入file_id文件标识符和user_id用户标识符都是字符串类型。核心逻辑分三步走。首先通过get_file_metadata异步获取文件的元数据包括文件的权限标签、所属部门等信息。然后用check_user_permission校验当前用户是否有权限访问这份文件——这一步是修复权限越界问题的关键。如果校验失败直接抛出PermissionError阻止后续操作。只有权限校验通过后才会调用load_file_content读取文件内容。输出成功时返回文件内容的字符串失败时抛出异常由上层统一处理。异常处理这里用显式的PermissionError而不是静默返回空字符串好处是调用方能明确区分权限不足和文件不存在两种情况便于日志记录和错误分类。断言逻辑代码assert_response_quality输入response是模型返回的文本expected_keywords是期望包含的关键字列表。核心逻辑采用三层递进检查。第一层遍历关键字列表检查响应是否包含必要信息不区分大小写。第二层检查输出长度过短的回答往往意味着模型没有理解问题或工具调用失败。第三层用正则表达式扫描敏感信息模式比如身份证号、密码等。输出返回一个字典包含passed布尔值和issues问题列表。这种结构方便后续集成到测试框架中可以批量处理多个用例的结果。异常处理这段代码本身不做异常捕获因为输入应该是字符串类型。如果传入非字符串Python会自然抛出TypeError这在测试框架中属于输入校验失败应该由调用方负责。Agent执行流程代码agent_execute输入user_input是用户的自然语言问题context是包含用户身份、历史对话等上下文的字典。核心逻辑模拟Agent的典型执行路径。先解析用户意图再根据意图和上下文决定调用哪些工具然后依次执行工具调用并收集结果最后用LLM生成最终回答。每一步都有对应的日志记录。输出返回Agent生成的最终回答字符串。异常处理代码中没有显式的 try-except但这正是设计意图——让异常自然向上传播由调用方或框架统一处理。日志记录了每一步的输入输出这样即使发生异常也能通过日志回溯到具体哪一步出了问题。理解这些代码的实现原理后再看前面的真实案例就能明白为什么权限校验要放在read_file内部而不是入口处——因为工具调用可能有多层嵌套入口校验无法覆盖所有路径。---失败原因业务、配置、环境三种错误怎么区分Agent出问题首先要判断是哪类错误业务错误模型理解错了用户意图或者工具调用逻辑有bug。特征同样的输入有时成功有时失败日志里能看到工具调用链路但某一步的结果不符合预期排查方法检查模型输出的中间步骤用相同的输入重新执行看是否可复现配置错误API Key填错了、模型参数配错了、工具路由配错了。特征所有请求都失败或者所有请求都返回同样的错误错误信息通常比较明确比如Invalid API key排查方法检查配置文件对比正常环境的配置环境错误网络超时、依赖服务不可用、资源不足。特征错误是间歇性的错误信息通常是超时、连接失败等排查方法检查依赖服务的状态检查网络连通性区分这三类错误最快的方法是看日志有明确的错误信息 → 配置错误错误间歇性出现 → 环境错误没有明显错误但输出不对 → 业务错误---适用边界什么时候该学什么时候先放放最后说说学习路线上的取舍。现在应该先补的1. 权限和身份认证的基本概念不用成为安全专家但要理解RBAC、最小权限原则、权限校验应该放在哪些环节。2. 日志和可观测性学会写结构化日志理解traceId的作用知道怎么通过日志回溯一次请求的完整链路。3. Prompt工程的基础不用深入研究但要理解Prompt对输出的影响知道怎么设计Prompt让输出更可控。可以先放放的1. 复杂的Agent框架LangGraph、AutoGen这些框架很强大但对于测试工程师来说先理解Agent的基本模式就够了。框架可以后面再学。2. 模型微调除非你明确要做模型训练相关的工作否则微调不是必须掌握的。3. 分布式部署这是运维和架构的范畴测试工程师不需要深入。什么时候不适合照搬每个团队的Agent架构不一样权限模型不一样日志规范也不一样。别人的测试方案不能直接照搬需要结合自己的系统特点调整。比如如果你们的系统没有用户身份体系那权限测试的重点就不是权限越界而是数据隔离。---总结测试转大模型最大的坑不是学不会新技术而是在Demo阶段养成的习惯到了生产环境会暴露问题。Demo阶段的测试关注的是功能能不能跑通。生产阶段的测试要关注的是权限有没有越界、日志能不能追溯、失败能不能定位。这三个问题比背十个测试框架更重要。我见过太多人花了大量时间学Agent框架、学Prompt优化简历上写满了各种Demo项目但面试问到你们怎么测权限边界、出问题怎么排查基本都答不上来。转型不是换标签是补能力缺口。认清自己的断点在哪里比盲目追热点更有价值。资料展示下面是我整理的AI大模型学习资料和工具包预览适合收藏后按主题逐步学习。如果你想看完整资料目录可以在评论区留言「资料」也欢迎告诉我你更关注AI大模型里的哪类内容。
![[光学原理与应用-521]：对光的错误理解与纠偏](http://pic.xiahunao.cn/yaotu/[光学原理与应用-521]：对光的错误理解与纠偏)
