测试转大模型：把方案拆到可执行

发布时间：2026/7/25 13:38:49

这篇不先堆名词。我们把《测试转大模型实战第一道门槛可能不是算法》拆成几级台阶看完至少知道下一步该学什么、该练什么。摘要做测试出身的人转型做 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(fIs 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大模型里的哪类内容。