测试转大模型：权限日志才是我上线前翻车的拦路虎

聊《我用测试经验做了次 AI 项目最先失效的是旧方法》之前先说一句实在的别急着背概念先看它在真实项目里到底解决什么问题。摘要摘要从传统测试到大模型应用权限、日志和可观测性成了新的“生死线”。本文以一次 AI 项目实战复盘讲述测试工程师如何在权限与日志的盲区里踩坑并总结如何构建一套适配 Agent 工程的测试策略。目录测试岗位的新变化AI 辅助测试不只是自动化用例自动化用例生成从规则驱动到提示驱动Agent 测试框架权限隔离与日志可观测质量评估Demo 能跑不等于能上线总结目录测试岗位的新变化AI 辅助测试不只是自动化用例自动化用例生成从规则驱动到提示驱动Agent 测试框架权限隔离与日志可观测质量评估Demo 能跑不等于能上线总结测试岗位的新变化两年前我还在用脚本做 UI 回归、写 JUnit 断言、跑 Selenium 页面验证一切按部就班。直到公司把一个基于 LLM 的客服问答系统交给测试团队我才意识到测试的边界被重新定义了。以前测的是“确定性输入→确定性输出”现在面对的是“非确定性输入→概率性输出”。更棘手的是这个系统不仅涉及模型推理还涉及权限校验、日志记录、异常兜底和回滚机制。Demo 跑得好不代表能上线。权限错了数据泄露日志缺失排查无门异常没兜底用户等来的是 500。我第一次碰壁就出在权限校验上。模型在测试环境里随便读用户信息因为测试环境没启用 RBAC基于角色的访问控制。上线前我才发现某些角色竟然能调用敏感接口。那次差点被安全团队叫停。AI 辅助测试不只是自动化用例我尝试让 AI 写测试用例起初挺兴奋。把一段业务逻辑丢进 Prompt模型居然生成了几十条边界用例。但很快我发现这些用例大多基于“理想路径”很少考虑权限越界、日志缺失、异常重试失败这些工程细节。比如对一个“用户修改订单状态”的 Agent 任务模型生成了“正常修改”“状态冲突”“权限不足”等用例但没写“日志中是否记录操作人”“失败时是否触发告警”“回滚是否正确执行”。这些才是上线前的真考点。后来我改策略不只让模型生成用例还让它生成“测试检查点清单”比如每个关键操作是否写入结构化日志JSON/ELK 兼容权限校验是否通过中间件拦截异常是否被捕获并触发降级逻辑是否有可观测指标延迟、错误率、token 用量我把这个清单写进测试框架作为自动化校验的一部分。自动化用例生成从规则驱动到提示驱动以前我们写测试用例靠经验现在靠 Prompt。但我发现直接让模型生成用例效果一般。于是我们设计了一个“模板化提示”你是一个资深 AI 测试工程师。请为一个基于 LLM 的 Agent 功能生成测试用例该功能允许用户查询订单状态。要求 1. 覆盖正常流程、权限不足、模型响应超时、日志未记录等场景。 2. 每个用例包含输入、预期输出、验证点如日志中是否存在 user_id、权限校验码等。 3. 用 Markdown 表格输出字段用例编号、场景描述、输入数据、预期输出、验证点。这个模板让模型输出的用例更结构化也更容易被自动化框架解析和执行。我们后来还加入“负面用例生成”任务让模型主动找漏洞比如“如果权限校验被绕过会发生什么”Agent 测试框架权限隔离与日志可观测我们自研了一个轻量级 Agent 测试框架核心是“权限沙箱 日志探针”。权限沙箱每次测试前为 Agent 分配一个临时角色限制其可访问的资源。比如测试“客服 Agent 查询用户信息”时沙箱只允许它访问脱敏后的字段真实数据被掩码。日志探针我们插入了一个中间件记录每次 Agent 调用的输入、输出、权限角色、耗时、异常类型。日志格式统一为 JSON可直接接入 ELK。代码片段简化版class PermissionSandbox: def __init__(self, role: str): self.role role self.allowed_resources self._load_role_permissions(role) def can_access(self, resource: str) - bool: return resource in self.allowed_resources class LogProbe: def log(self, event: dict): # 写入结构化日志含 trace_id, user_id, action, status print(json.dumps(event, ensure_asciiFalse))在测试用例中我们这样调用sandbox PermissionSandbox(rolecustomer_service) if not sandbox.can_access(order_detail): raise PermissionDenied(角色无权限查询订单) probe LogProbe() probe.log({ trace_id: generate_trace_id(), user_id: user_123, action: query_order, status: success, timestamp: now() })这套框架帮助我们发现了三类问题权限越界、日志缺失、异常未兜底。质量评估Demo 能跑不等于能上线我们制定了一套“上线前检查清单”包含[ ] 所有关键操作是否写入结构化日志[ ] 权限校验是否通过统一中间件[ ] 异常是否被捕获并有降级方案[ ] 是否有可观测指标延迟、错误率、token 用量[ ] 是否支持回滚如 Agent 状态回退到上一版本[ ] 是否通过安全评审数据脱敏、访问控制这个清单在每次 CI/CD 流水线中强制执行。有一次一个 Agent 功能在本地测试完美但因为缺少日志 trace_id被流水线拦下。补上后才通过。总结从测试到大模型最大的转变不是工具而是思维。以前我们关注“功能对不对”现在要问“权限够不够、日志清不清晰、异常兜没兜底”。如果你也是测试工程师想转大模型方向建议1. 先学权限模型RBAC、ABAC和日志规范OpenTelemetry、ELK。2. 尝试写一个带权限沙箱和日志探针的测试框架。3. 在简历里展示你设计的“Agent 测试检查清单”或“可观测性测试用例”。4. 别只写“会 Prompt 工程”要写“能保障 Agent 上线安全”。Demo 只是入场券权限、日志和可观测性才是你真正的护城河。资料展示下面是我整理的AI大模型学习资料和工具包预览适合收藏后按主题逐步学习。如果你想看完整资料目录可以在评论区留言「资料」也欢迎告诉我你更关注AI大模型里的哪类内容。