企业AI上线前到底应该测什么？我理解的AI测试体系

这段时间一直在做企业 AI 项目的测试，我越来越明显地感觉到一件事：

AI 测试最难的地方，其实不是多了多少新的测试技术，而是我们原来习惯的「功能对不对」，已经不足以回答「这个系统能不能上线」了。

传统系统相对容易理解。输入一笔数据，按照既定逻辑处理，最后得到一个确定结果。测试人员重点关注需求有没有实现、数据算得对不对、异常能不能处理、并发上来之后系统扛不扛得住。

但 AI 应用不是这样。

用户问同一个问题，两次答案可能不完全一样；知识库里明明有答案，它可能没有检索出来；模型本身回答没有问题，Agent 却可能调用错工具；单次请求只用了几秒钟，放到几十个并发用户下，却开始排队；再往后，还会遇到提示词注入、越权调用、上下文污染、长时间运行后成功率下降等问题。

所以现在如果让我回答：一个企业 AI 应用上线前，到底应该测什么？

我不会再简单回答「功能、性能、安全」。我更倾向于把它拆成七个部分：功能、模型质量、RAG、Agent、性能、安全、稳定性。

这七部分组合起来，才比较接近我现在理解的企业 AI 测试地图。

图 1 · 企业 AI 测试全景地图：测试对象已经不只是模型，而是应用、模型、知识、工具和基础设施共同组成的一条链路

一、首先还是功能，但功能测试已经不是全部了

AI 应用当然还是要做功能测试。

页面能不能打开、文件能不能上传、会话能不能创建、权限控制是否正确、历史记录能不能查询、接口异常有没有提示，这些都没有发生变化。

如果是企业内部的办公智能体，还可能包括：文档上传、知识问答、文档生成、数据分析、PPT 生成、代码生成、多轮对话、文件下载等业务功能。

这些仍然属于传统软件测试比较擅长的领域。

问题在于，很多 AI 项目容易出现另外一个情况：功能是通的，但结果并不能用。

比如点击「生成报告」，报告确实生成出来了。从传统功能测试角度看，这个功能甚至可以判定通过。

但是进一步看：报告中的数字是不是正确？引用的制度是不是最新版本？有没有把不存在的内容写进去？用户问的是「A 和 B 有什么区别」，模型是不是回答成了「A 和 C」？

这时已经不是简单的功能测试问题了。

所以我现在习惯先把两个问题拆开：第一层，功能有没有完成；第二层，AI 完成得好不好。第一层还是传统功能测试，第二层就进入模型质量测试。

二、模型质量测试，真正难的是「什么叫回答正确」

对于传统系统，一个测试用例通常比较容易写预期结果。比如：输入 100 元，手续费率 1%，预期手续费 1 元。

但如果测试的是「请根据这份 20 页的材料，总结当前项目存在的主要风险」，预期结果怎么写？很难写成一句完全固定的答案。

这也是 AI 测试和传统测试最大的区别之一。AI 应用的很多测试，不再适合简单使用「实际结果 = 预期结果 → PASS」的判断方式，而要变成：实际结果在多个评价维度上是否达到可接受水平。

例如一个企业问答场景，我通常至少会关注：

• 事实是否正确
• 回答是否相关
• 关键内容是否完整
• 有没有编造信息
• 引用是否能够支撑结论
• 不同执行之间结果是否稳定

如果是内容生成类场景，还要再看结构、格式、指令遵循程度。如果涉及敏感问题，则还要判断应该拒答的时候有没有正确拒答。

这里还有一个很容易被忽略的问题：AI 测试不能只执行一次。

同一个问题第一次回答正确，不代表第二次一定正确。所以对于重要场景，我更关注的是一组结果。

比如同一个测试问题连续执行 10 次：8 次正确、1 次漏掉一个关键点、1 次产生事实错误。这时候「通过率 80%」往往比「这个用例通过了」更有意义。

图 2 · 同一问题多次执行的结果分布：传统测试关注一次执行是否正确，AI 测试还要看结果分布

这也意味着 AI 测试方案里必须比过去更加明确几个东西：

• 测试数据是什么
• 使用哪个模型版本
• Temperature 等参数是多少
• 上下文长度是多少
• 一个问题执行多少次
• 谁来评分
• 多少分算通过

如果这些条件都没有固定下来，最后得到的所谓「模型准确率」，其实很难复现，也很难比较。

三、用了知识库以后，要单独测试 RAG

企业 AI 和互联网聊天机器人还有一个明显区别：企业通常不会只让模型依靠自身知识回答。

制度、产品、业务规则、操作手册、内部文档，大量内容都会放进企业知识库，通过 RAG 提供给模型。于是测试对象又多了一层。

用户问「某项业务办理条件是什么」，最后模型回答错了，并不一定意味着模型能力不行。

• 可能是文档没有解析完整
• 可能是切片把关键的两段内容切开了
• 可能是召回没有找到正确内容
• 也可能召回正确，但是排序靠后，被其他内容干扰
• 甚至知识已经正确送给模型，模型最后还是自己编了一个答案

所以我理解的 RAG 测试，本质上应该把「知识进入最终答案」的过程拆开来看：

原始文档 → 解析 → 切片 → 检索 → 重排 → 上下文 → 模型回答

不能只测试最后一句回答。

图 3 · RAG 错误定位链路：回答错误 ≠ 一定是模型错误

对于企业知识问答，我现在认为至少应该分别回答三个问题：

• 正确知识有没有被找到？这是召回的问题。
• 找到以后有没有把真正有用的内容排到前面？这是排序和上下文构造的问题。
• 正确知识已经给到模型以后，模型有没有基于这些知识回答？这是生成质量的问题。

这三个问题如果不拆开，项目现场特别容易出现一句话：「模型回答不准。」但到底哪里不准，没有人说得清。

四、到了 Agent，测试对象从「回答」变成了「完成任务」

现在企业 AI 越来越多的场景已经不是单纯聊天了。例如查一个客户信息、读取某个系统的数据、生成一份报告、调用流程平台发起审批、分析 Excel、生成 PPT、执行一段代码。

这些场景的本质是 Agent。这时候测试重点会再次发生变化。

因为我们关心的不只是模型最后说了什么，而是：它中间到底做了什么。

比如一个简单的任务：「查询 A 客户最近三个月的交易情况，并生成分析报告。」背后可能经历：理解用户意图、识别客户、调用客户信息接口、调用交易查询接口、处理查询结果、调用分析工具、生成报告、把文件返回给用户。

其中任何一步出问题，最终任务都可能失败。

所以 Agent 测试，我更关注「路径」。

图 4 · Agent 任务执行链：Agent 测试的对象不只是最终答案，而是整个执行路径

这里还有一个我认为非常重要的问题：Agent 不能只测「能不能调工具」，还要测试「该不该调这个工具」。

例如一个办公智能体具有知识查询、数据库查询、文件操作、代码执行等多个工具。

• 用户只是问一个知识问题，它却跑去访问数据库
• 或者本来只需要读取数据，却调用了具有写权限的接口

从技术角度看工具调用成功了。从企业控制角度看，这反而是严重的问题。

所以 Agent 测试和权限、安全、业务规则实际上是交叉在一起的。

五、性能测试不能再只看「多少并发」

这一点我最近体会比较深。

过去做性能测试，我们很习惯说：200 并发、500 并发、1000 并发、TPS 多少、响应时间多少。

但是到了大模型和 Agent 场景，只报一个并发用户数，很容易产生误导。因为两个「40 并发」，负载可能完全不是一个数量级。

一个用户问「北京今天星期几？」，和一个用户上传几十页材料要求「分析材料并生成一份完整报告」，虽然都是一次请求，但是模型需要处理的 Token 数量、推理时间、显存占用完全不同。如果再加入多轮会话和 Agent 调用，差异会更大。

一次用户请求，后台可能实际触发：一次意图识别、一次知识检索、两次模型调用、一次工具调用、一次总结。用户看到的是一次操作，后台已经放大成了多次请求。

所以 AI 性能测试，我现在更关注的是一组指标，而不是一个并发数。包括：

• TTFT，也就是用户多久看到第一个 Token
• TPOT，也就是后续 Token 生成速度
• 整体生成速度
• 排队时间
• 端到端响应时间
• Token 吞吐
• 失败和重试情况

再往业务层看，还要关注：一次完整任务到底多久做完。

图 5 · 并发增加后的性能拐点：AI 性能测试不能只报一个并发数

另外，性能场景一定要尽量接近真实业务。

例如办公智能体，如果真实用户主要做知识问答、文档生成、PPT、数据分析、代码、多轮对话，就不能拿几十个完全一样的简单问答请求去证明「系统支持 40 并发」。

真正有意义的是把请求长度、输出长度、Think Time、多轮次数、Agent 调用次数都放进用户模型里。

最后得到的才是：什么样的业务负载下，这套资源能够支撑多少使用量。

六、安全测试最大的变化，是模型本身也变成了攻击入口

传统应用安全更多关注接口、权限、漏洞、数据。这些在 AI 应用里一个也不能少。

但 AI 又增加了一类完全新的输入入口：自然语言。

攻击者不一定需要找到一个 SQL 注入点。一段精心构造的提示词，也可能改变模型的行为。例如：

• 让模型忽略系统要求
• 诱导模型泄露系统提示词
• 通过文档中的隐藏内容影响模型
• 诱导 Agent 调用本来不应该调用的工具
• 尝试获取其他用户的数据

所以企业 AI 安全测试至少要同时看两个世界：一个是传统应用安全，一个是 AI 特有安全。

图 6 · 企业 AI 攻击面：AI 安全要同时看传统安全和 AI 特有风险

这里我尤其关注一个问题：AI 安全不能只测模型会不会说不该说的话，还要看它有没有能力做不该做的事情。

对于纯聊天机器人，错误回答可能只是一个内容问题。但如果 Agent 已经接入生产系统，一个错误决策可能变成真实操作。

所以随着 Agent 权限增加，安全测试的重要性其实是在快速上升的。

七、最后还有稳定性：第一次能跑，不代表可以长期跑

很多 AI 项目性能测试做完以后就准备上线。但我越来越认为，稳定性应该单独拿出来。

因为 AI 系统后面的依赖链通常比传统应用长很多。可能包含：

• 应用服务、Agent 平台、模型服务
• 向量数据库、Embedding 模型、Rerank 模型
• 知识库、GPU/NPU 算力
• 外部工具、数据库、第三方接口

这意味着系统出现故障的方式也更多。比如：

• 模型服务重启以后，会话能不能继续？
• 推理节点异常以后，请求会不会自动切换？
• 工具调用超时，Agent 会不会无限重试？
• 知识库短暂不可用，会不会直接导致整个系统卡死？
• 长时间高负载以后，显存有没有异常增长？
• 连续进行几十轮对话以后，上下文是否越来越慢？
• 任务执行到一半失败以后，重新执行会不会重复提交业务数据？

这些问题单次功能测试很难发现。

图 7 · 长稳测试监控图：稳定性测试要回答的是，系统能不能持续工作，出问题以后还能不能恢复

如果有条件，可以人为制造一次模型服务或工具服务异常，在图上标记故障时间和恢复时间。

稳定性测试真正回答的是：系统不是「某一次能够工作」，而是能不能持续工作，并且出问题以后还能恢复。

对于真正准备面向大量企业用户开放的 AI 系统，这一点往往比一次漂亮的 Demo 重要得多。

八、把这些东西放到一起，才是一套完整的 AI 测试

如果把前面的内容重新整理一下，会发现它其实对应了七个非常朴素的问题：

• 功能测试回答：这个功能能不能用？
• 模型质量测试回答：AI 做得对不对？
• RAG 测试回答：企业知识能不能正确进入答案？
• Agent 测试回答：AI 能不能正确完成一个任务？
• 性能测试回答：人多、任务重以后还能不能用？
• 安全测试回答：会不会被诱导做不该做的事情？
• 稳定性测试回答：能不能持续可靠地运行？

图 8 · 企业 AI 上线七问：不是体验一下感觉还行，而是要基于场景、数据和风险做出准出判断

九、最终测试的，不应该只是模型，而是一整个 AI 应用

企业在刚开始建设 AI 能力的时候，很容易把大量注意力集中在模型上。

这个模型参数多少？排行榜多少分？推理速度多少？上下文支持 128K 还是 200K？

这些当然重要。但真正上线以后，用户面对的从来不是一个裸模型。

用户面对的是：模型 + Prompt + 知识库 + Agent + 工具 + 数据 + 权限 + 算力 + 应用。

其中任何一个环节出现问题，最后体现到用户这里，都是：「这个 AI 不好用。」

所以我现在越来越少单独讨论「模型测试」。我更愿意把测试对象定义成：企业 AI 应用。模型只是其中很重要的一层。

图 9 · 从「测模型」到「测 AI 应用」：测试对象正在扩大，用户面对的不是一个裸模型，而是一整套 AI 应用链路

这也会直接影响测试人员的工作方式。

以前看到一个错误，我们很容易问：「这是前端问题还是后端问题？」

以后看到 AI 回答错误，可能要继续往下问：

• 模型有没有拿到正确上下文？
• RAG 到底召回了什么？
• Agent 实际调用了哪个工具？
• 模型参数是什么？
• 这个问题连续执行十次是什么结果？
• 当时模型服务是不是正在排队？

只有把链路真正打开，AI 测试才有可能从「体验一下好不好用」，变成可以分析、可以复现、可以准出的工程活动。

十、我现在更关心的，是 AI 到底凭什么允许上线

做传统项目时，我们习惯有比较明确的准出标准：严重缺陷有没有解决、核心功能是否通过、性能指标是否达标、安全漏洞是否整改。

到了 AI 项目，我认为这个思路仍然应该保留。只不过准出条件需要变得更丰富。

不能因为「大家试了一下感觉还可以」就认为可以上线。也不能因为「模型排行榜很高」就认为业务场景一定没有问题。

真正有意义的上线判断，应该来自具体场景。

比如一个知识问答场景，我们需要知道：核心问题回答准确到什么程度、关键制度引用有没有错误、高风险幻觉是否存在、知识召回是否稳定、高峰期响应是否还能接受、敏感问题能不能正确处理。

一个 Agent 场景，则还要进一步看：任务成功率、工具调用准确率、异常恢复、权限控制、重复执行风险。

换句话说：AI 测试最终不是为了证明这个模型很强，而是为了证明这个 AI 应用在我们准备开放的业务场景下，可以被安全、稳定地使用。

这可能也是我现在理解的 AI 测试体系，和传统软件测试最大的区别。

图 10 · 从测试执行到上线准出：不是测试「AI 能不能回答」，而是判断「这个 AI 能不能进入真实业务」

结语

企业 AI 还在快速变化，很多测试方法也远没有完全定型。

但至少从目前做项目的经验看，我认为有一个方向已经比较明确：

AI 并没有让传统测试失效，而是在传统软件测试之上，又增加了模型的不确定性、知识检索链路、Agent 执行链路以及新的安全和性能问题。

功能测试依然要做。性能、安全、稳定性依然要做。

只不过现在，我们必须再往模型里面多走一步，也要往完整业务链路外面多看一步。

最终形成的，才是一张真正适合企业 AI 上线前使用的测试地图。

而这张地图的终点，也不是一个漂亮的模型评分。而是一个更实际的问题：当真实用户、真实数据和真实业务进来以后，这个 AI 到底靠不靠谱。