这篇不先堆名词。我们把《测试转大模型实战，第一道门槛可能不是算法》拆成几级台阶，看完至少知道下一步该学什么、该练什么。

摘要

做测试出身的人，转型做 AI 工程化或者 LLM 应用开发时，最容易陷入的一个误区是：只要 Prompt 写得漂亮，模型输出准确，项目就是成功的。

我之前也是这么想的。直到上个月，我们团队把一个基于 LangChain 的自动化测试 Agent 从 Demo 环境推向内部预发布环境时，崩盘了。不是因为模型“笨”，也不是因为逻辑有 Bug，而是因为权限失控和日志不可观测。

那个 Agent 在本地跑得好好的，能生成测试用例，能调用 API 执行。但一旦并发上来，它就开始乱删数据库里的脏数据——因为它没有做好隔离；更致命的是，当它出错时，我们根本不知道它是哪一步幻觉了，还是调错了工具。

这就是我今天想复盘的重点：从传统软件测试转向大模型测试与质量保障，最大的挑战不是掌握新的算法理论，而是建立一套针对“不确定性系统”的工程化质量观。 特别是当应用从 Demo 走向生产，权限隔离、可观测性和成本控制才是真正的护城河。

目录

• 测试岗位的新变化：从确定性到概率性
• AI 辅助测试：别把 Agent 当万能钥匙
• 自动化用例生成：从“写脚本”到“管提示词”
• Agent 测试框架：权限隔离是生死线
• 质量评估：可观测性优于准确率
• 总结

测试岗位的新变化：从确定性到概率性

在传统软件测试中，我们的核心思维是“确定性”。输入 A，经过逻辑 B，必然得到结果 C。如果没有得到 C，那就是 Bug。这种思维模式在处理 AI 应用时，直接失效了。

大模型应用的核心特征是“概率性”。同样的 Prompt，不同的温度参数（Temperature），甚至不同时间点调用，返回的结果都可能不同。这意味着，传统的“断言（Assertion）”不再够用，我们需要引入“评估（Evaluation）”。

对于测试工程师来说，这种转变带来了两个具体的痛点：

1. 回归测试的成本激增：以前改一行代码，跑一下单元测试就行。现在改了一点 Prompt 或换了个模型版本，可能需要跑几百条评测集，还要人工抽检。
2. 边界条件模糊：传统软件的边界是明确的（如空值、越界）。AI 应用的边界是语义上的，比如“用户是否隐含了恶意攻击意图？”这需要更复杂的测试策略。

我在转型初期，曾试图用大量的单元测试去覆盖 LLM 的输出，结果发现维护成本极高，且毫无意义。后来我意识到，测试的重点必须从“验证单次输出的正确性”转移到“验证整个流程的稳定性和安全性”上。

AI 辅助测试：别把 Agent 当万能钥匙

现在市面上有很多“AI 生成测试用例”的工具，宣传语都很诱人。但在实际项目中，我强烈建议保持警惕。

AI 生成的测试用例，往往缺乏业务深度。它能写出标准的 CRUD 用例，但对于复杂的业务逻辑关联、异常场景的覆盖，远不如一个资深测试人员结合业务理解写出来的用例有价值。

我的建议是：用 AI 做“扩列”，而不是“决策”。

比如，你可以让 AI 基于一个核心业务场景，生成 10 个变体用例，然后由人来判断哪些是有价值的。同时，不要过度依赖 AI 自动执行测试。在初期，人工 Review AI 生成的测试脚本质量，远比让 AI 全自动运行更重要。

这里有一个具体的实践建议：在 CI/CD 流水线中，加入一个“LLM 输出质量检查”阶段。这个阶段不检查功能是否正确，而是检查输出是否符合预设的格式规范和安全红线。

import json from openai import OpenAI client = OpenAI() def check_llm_output_safety(llm_response: str, schema: dict) -> bool: """ 简单的静态检查示例：验证 LLM 返回的 JSON 结构是否合规， 并检查是否包含敏感关键词。 """ try: data = json.loads(llm_response) # 1. 结构校验 if not all(key in data for key in schema.keys()): return False # 2. 安全内容过滤 sensitive_words = ["password", "secret_key", "admin_token"] response_lower = llm_response.lower() if any(word in response_lower for word in sensitive_words): print("Warning: Sensitive information detected in output!") return False return True except json.JSONDecodeError: return False # 使用示例 sample_response = '{"status": "success", "token": "secret_key_123"}' schema = {"status": str} is_safe = check_llm_output_safety(sample_response, schema) print(f"Is safe: {is_safe}")

这段代码很简单，但它解决了一个大问题：防止 LLM 泄露敏感信息。在生产环境中，这是必须的第一道防线。

自动化用例生成：从“写脚本”到“管提示词”

很多测试同学担心，AI 时代还要写自动化脚本吗？答案是：要写，但写的不再是单纯的 Selenium 或 Appium 脚本，而是Prompt 模板和测试编排逻辑。

在实际项目中，我发现“Prompt 版本管理”比“代码版本管理”更难。为什么？因为 Prompt 是自然语言，细微的改动可能导致输出巨大的偏差。

我的做法是建立一套“Prompt 测试框架”：

1. 基线记录：每次更新 Prompt，必须记录当前的“黄金数据集”（Golden Dataset）及其预期输出。
2. 漂移检测：定期运行基线测试，计算新输出与预期输出的相似度（可以使用 Embedding 向量余弦相似度）。如果相似度低于阈值，触发报警。
3. A/B 测试：在新模型或新 Prompt 上线前，并行运行两个版本，对比关键指标。

这样做的好处是，即使模型升级，你也能量化地知道“这次升级到底让测试准确率提升了多少，还是下降了”。

Agent 测试框架：权限隔离是生死线

回到文章开头提到的踩坑经历。那个崩盘的 Agent，最大的问题在于它拥有过高的权限。

在传统的单体应用中，权限通常由框架（如 Spring Security）严格管控。但在 LLM Agent 架构中，Agent 通过 Function Calling 动态调用工具，如果这些工具对应的 API 接口权限配置宽松，Agent 就可能被 Prompt 注入攻击诱导，执行非预期的危险操作。

实战建议：

1. 最小权限原则（Least Privilege）：给 Agent 使用的每个 Tool（工具函数），都绑定独立的、仅具备必要权限的 Service Account。例如，一个只负责查询订单的 Agent，不应该拥有删除订单的 API Key。
2. 沙箱执行：对于高风险操作（如修改数据库、执行 shell 命令），必须在隔离的沙箱环境中运行，或者增加二次确认机制（Human-in-the-loop）。
3. 输入净化：在将用户输入传递给 LLM 之前，进行严格的清洗和过滤，防止 SQL 注入或 Prompt Injection。

我曾见过一个案例，测试人员在本地测试时，发现 Agent 能正常响应。但上线后，由于没有对“系统提示词”中的变量进行转义，导致攻击者通过构造特殊输入，让 Agent 输出了数据库的完整结构。这就是典型的“Demo 里跑通，上线即崩溃”。

质量评估：可观测性优于准确率

最后，谈谈如何评估一个大模型测试项目的质量。

很多人关注“准确率（Accuracy）”，但这在 AI 领域是个伪命题。因为 LLM 的输出是开放的，很难定义唯一的“正确答案”。

我更看重三个指标：

1. 响应时间（Latency）：包括首字延迟（TTFT）和总生成时间。慢的用户体验会直接抵消准确性的价值。
2. 成本（Cost）：每千次请求的费用。如果一个测试用例生成耗时 5 秒，花费 $0.1，那它在大规模回归测试中是不可接受的。
3. 可观测性（Observability）：这是最关键的一点。你需要知道每一次请求的完整链路：输入是什么？Prompt 是什么？调用了哪些 Tool？中间状态是什么？最终输出是什么？

推荐使用 LangSmith 或 Arize Phoenix 这样的可观测性平台。它们不仅能记录日志，还能追踪 Trace，让你直观地看到 Agent 的思考路径。当出现 Bug 时，你能迅速定位是 Prompt 的问题、模型的问题，还是 Tool 的问题。

总结

从传统测试转型到大模型测试，本质上是从“规则驱动”向“数据与模型驱动”的思维跃迁。

不要迷信算法，也不要忽视工程细节。权限隔离、日志可观测、成本控制，这些看似枯燥的工程化事项，才是决定大模型应用能否真正落地的关键。

对于想入行的测试工程师，我的建议是：

1. 补齐工程短板：深入学习 API 安全、微服务架构和可观测性工具。
2. 建立评估思维：学会设计针对 LLM 的评测集，而不仅仅是自动化脚本。
3. 关注生产环境：多思考如何在高并发、不安全的环境下保证系统的稳定性。

大模型的应用浪潮才刚刚开始，测试工程师的价值，将从“找 Bug”转变为“定义质量”和“构建信任”。这条路不容易，但值得投入。

资料展示

下面是我整理的AI大模型学习资料和工具包预览，适合收藏后按主题逐步学习。

如果你想看完整资料目录，可以在评论区留言「资料」；也欢迎告诉我你更关注AI大模型里的哪类内容。