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

Demo 能跑通只是热身，权限与日志才是 AI 测试的生死线

news 2026/7/26 20:45:58

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

摘要

摘要：很多转大模型的测试工程师卡在“Prompt 调优”上，却忽略了工程化落地的硬骨头。本文通过对比一个丝滑的 Demo 和一个崩盘的 Agent，拆解权限隔离、日志追踪和可观测性在 AI 测试中的核心价值，给出从功能测试向质量工程转型的具体路径。

测试岗位的新变化：从“找 Bug”到“测不确定性”
AI 辅助测试：别只卷 Prompt，先看数据流
自动化用例生成：当测试脚本开始自我进化
Agent 测试框架：权限与日志是上线前的最后一道坎
质量评估：如何量化 LLM 输出的“靠谱程度”
总结：测试背景的优势与短板

测试岗位的新变化：从“找 Bug”到“测不确定性”

以前做传统软件测试，逻辑是确定性的。输入 A，经过函数处理，必然得到 B。如果没得到 B，那就是代码写错了或者环境有问题。这种思维定势在转大模型（LLM）应用测试时非常致命。

我见过不少同事刚接触 AI 测试，第一反应还是用 Selenium 或 Playwright 去抓界面元素，或者对着 API 返回做严格的 JSON Schema 校验。结果发现，LLM 的输出经常是“差不多”，有时候甚至会出现幻觉。你没法像断言assertEquals那样去断言一句自然语言是否完美。

真正的变化在于，我们不再仅仅验证“代码是否执行正确”，而是要验证“智能体是否理解意图”以及“系统是否在安全边界内运行”。这要求测试工程师具备新的能力图谱：不仅要懂业务逻辑，更要懂 Prompt 的结构、Token 的成本、以及模型调用的延迟抖动。

AI 辅助测试：别只卷 Prompt，先看数据流

很多人觉得转大模型就是学怎么写更好的 Prompt。确实，Prompt Engineering 很重要，但它只是表象。

在一次内部复盘项目中，我们发现最大的问题不是 Prompt 写得不好，而是上下文管理混乱。一个典型的 Agent 流程是这样的：用户提问 -> 检索知识库 -> 组装 Prompt -> 调用 LLM -> 解析结果。如果在这每一步都没有明确的日志记录，当结果出错时，你根本无法定位是检索召回率低，还是 LLM 理解偏差，或者是后处理逻辑解析失败。

所以，我的建议是：在写第一个复杂 Prompt 之前，先搭建好可观测性基础。你需要知道每个环节的输入是什么，输出了什么，消耗了多少 Token。没有这些黑盒里的数据，所谓的 AI 测试就是盲人摸象。

自动化用例生成：当测试脚本开始自我进化

自动化测试一直是测试工程师的基本盘。但在 AI 时代，我们可以利用 LLM 来生成或优化测试用例。

比如，面对一个复杂的电商下单接口，传统做法是人工编写 50 个边界用例。现在，你可以让 LLM 基于产品文档和过往 Bug 库，生成一批覆盖极端情况的测试脚本。但这里有个坑：LLM 生成的代码往往不可靠。它可能会忘记导入必要的库，或者逻辑存在死循环。

因此，AI 辅助测试的核心价值不在于“替代人工写代码”，而在于“扩大测试覆盖面的初稿”。你需要做的是 Review 这些代码，将其纳入 CI/CD 流程，并建立回归测试集。

以下是一个简单的 Python 示例，展示如何利用pytest结合 LLM 的 Mock 服务进行基础的功能验证，注意这里强调的是对输出结构的验证，而非内容本身的绝对正确性：

import pytest import json from unittest.mock import patch, MagicMock mock_llm_response = { "choices": [ { "message": { "role": "assistant", "content": "根据查询，库存剩余 5 件，价格 99.00 元。" } } ] } def test_llm_output_structure(): """ 测试重点：不验证内容语义，只验证结构是否符合预期 这是 AI 测试中确定性最高的部分 """ with patch('requests.post') as mock_post: # 模拟 API 调用成功 mock_response = MagicMock() mock_response.status_code = 200 mock_response.json.return_value = mock_llm_response mock_post.return_value = mock_response # 假设这是你的业务代码 from my_ai_app import get_product_info result = get_product_info("item_id_123") # 验证返回类型和关键字段 ![CSDN资料领取方式](https://i-blog.csdnimg.cn/direct/36e9f34b2beb47f1ad35600d9d31e7ae.jpeg) assert isinstance(result, dict) assert "status" in result assert result["status"] == "success" # 验证内容非空 assert len(result.get("data", {}).get("content", "")) > 0 def test_llm_timeout_handling(): """ 测试重点：验证网络异常时的降级策略 AI 服务不稳定是常态，容错机制比成功率更重要 """ with patch('requests.post') as mock_post: mock_post.side_effect = Exception("Connection Timeout") from my_ai_app import get_product_info # 应当返回默认值或错误码，而不是直接崩溃 result = get_product_info("item_id_123") assert result["status"] == "error" assert "timeout" in result.get("message", "").lower()

这段代码看似简单，但体现了 AI 测试的一个关键取舍：将确定性测试与非确定性测试分离。结构校验用自动化手段固定下来，而内容语义则交给后续的评估环节。

Agent 测试框架：权限与日志是上线前的最后一道坎

近期热点常说“大模型应用从 Demo 转向权限、日志和可观测”。这句话对测试工程师意味着什么？

在 Demo 阶段，Agent 可能只是读取本地文件。但一旦上线，它可能需要访问数据库、调用第三方 API，甚至修改用户数据。这时候，权限隔离（Permission Isolation）就成了生死线。

我参与的一个项目曾因未限制 Agent 的文件写入权限，导致它在调试模式下覆盖了生产环境的配置文件。教训是惨痛的。作为测试，你必须设计专门的安全测试用例：
1. 最小权限原则：Agent 只能访问它所需的最少资源。
2. 输入过滤：防止 Prompt Injection（提示词注入）绕过安全限制。
3. 操作审计：所有 Agent 发起的外部调用必须有不可篡改的日志。

此外，日志的可追溯性至关重要。当用户投诉“机器人答非所问”时，你不能只看最终回复。你需要通过 Trace ID 串联起整个请求链路：用户问了什么 -> 检索了哪些片段 -> Prompt 长什么样 -> 模型输出了什么 -> 后处理做了什么。没有这套链路，AI 测试就失去了根基。