一文说明AI 测试都在干什么

最近经常刷到：「功能测试完了」「自动化也完了」。

岗位是在收缩，简历石沉大海，应届生甚至说不清软件测试还能从哪里入行。

招聘标题换成了「AI 测试」「大模型测评」「智能体测评」。但我的判断比较直接：测试要回答的问题没变。变的是被测系统里多了一层模型或智能体，以及你要多学一套专门对着这层下判断的方法。

工作骨架仍然是：给定输入，观察实际行为，对照预期，给出是否通过。AI 测试是在这套骨架上，增加一类新的被测对象。

这篇想把边界说清楚。功能测试增加的，是如何面对「系统里嵌了一个大模型，或一个会调工具的智能体」。测评增加的，是一套用来判断这类输出的方法。二者都还是测试。

01先把两件焦虑拆开

裁员，和 JD 改名，要分开看。

编制减少，多半是业务收缩。它说明岗位变少了，说明不了「测试这项工作消失了」。JD 改名，是因为产品形态变了：很多系统除了返回写死的页面和接口字段，还会返回一段生成的话、一次工具调用、一轮可以继续追问的对话。招聘词跟着产品走，是正常更新。

三件事可以放在一张表里看：

新的是被测对象，以及「通过」二字要比以前写得更明确。用例设计、边界、异常、回归，仍然是这门手艺的主体。

02先认清你在测哪一类系统

「带了大模型的系统」至少要分成三类。测法不同，指标也不能混在一个结论里。

功能测试最容易接住的，是第三类里那些仍然可以断言的部分：该调用的接口调用了没有，不该改的数据有没有被改掉，失败时用户看到的是明确提示，还是一段听起来很完整的胡话。

可以先记住：对话产品看「这句话能不能用」。带检索的问答要拆开看「找得对不对」和「说得对不对」。智能体还要多看一眼「手有没有伸对地方」。

03入门动作：先把模型用顺

对功能测试来说，第一步是让这些工具为你所用。元宝、豆包、Trae，平时就打开。初期只做一件事：多跟它们对话，看它们怎么组织输出。

看四类现象就够：

· 什么情况下答得稳，换种问法仍然落在同一个事实上

· 什么情况下开始编，把没有的单号、政策、步骤说得很具体

· 什么情况下答非所问，态度完整，问题没接住

· 同一个问题问两遍，关键事实是否还在

这些观察后面都会变成用例。你知道「正常输出长什么样」，才写得出「这题不应该长成什么样」。手感建立在大量真实回答上，建立在指标名词上是不够的。

04体验：用户等的是第一个字

对话产品里，有一个指标会先于「答得对不对」打击用户：首字延迟。从点击发送，到屏幕上出现回答的第一个字，中间那段空白，就是首字延迟。业界常叫 TTFT，Time To First Token。

这段空白要单独立项。你问一个智能体，它半天不吐字，你自己都会想刷新、重发，或者直接关掉。用户也一样。答案如果在十秒之后才是对的，很多人已经看不到这个正确答案。

Web 端我们熟悉的两档经验，量级上仍然可以当参照。它们描述的是人的耐心，可以用来给首字延迟定一个量级，模型产品的 SLA 仍要按业务单独约定。

智能体往往更吃亏。它可能要先查接口、再查知识库，然后才开始生成。最终答案也许是对的，第一个字来得太晚，用户已经走了。所以「答对了」和「来得及被看见」是两项测试。

另一项要一起记的是端到端延迟：从发送，到整段回答结束。首字很快、后文挤很久，阅读会被打断，也更容易在中途超时。两个数都留下，一个平均值盖不住这两种失败。

05成本：把 token 消耗记进结果

再往后是 token 消耗。一次请求吃掉多少输入 token、吐出多少输出 token，直接对应费用，也对应上下文会不会被撑满。

功能看起来没问题，但每问一句都把全部历史塞进模型，上线之后账单和超时会一起出现。演示环境里很难靠感觉发现这种问题。和接口测试里记录响应时间、报文大小一样，消耗要写进同一条测试记录：这题花了多少，慢在首字还是慢在整段。

上线前值得单独看一眼：回答正确、工具也调对了，如果单轮就把上下文打满，下一轮会变慢、变贵，甚至把前面的关键事实挤掉。正确性通过，不代表这次调用可以放量。

06正确性：整理成结果集，再由人来裁判

最后才是大家最关心的：回答准不准，工具调用准不准。

做法和功能测试整理结果集是同一条路。准备一批固定输入：问题、场景、订单号，这类能锚定上下文的数据。每条事先写下预期。实际跑一遍，记下模型或智能体的真实输出。然后由人来裁判：实际和预期是否对得上。

最小的数据就是三列。

被测如果是智能体，再加两列：预期调用的工具，实际调用的工具。只看最后一句话，会把「说对了但没去查」和「查对了但说错了」收成同一个结论。参数也要看。查的是这张订单，还是另一张，结论完全不同。

生成式回答很少逐字相同。预期写「订单已发货，单号 SF123」，实际写成「您的包裹已发出，顺丰单号是 SF123」，人看是对的，程序做全等会判失败。这一阶段的「一样」，指的是要点是否命中：关键事实在不在，不该出现的承诺有没有出现，工具和参数是否正确。

先分三档就够用：通过、部分通过、不通过。部分通过要写下差在哪一条要点，否则复跑时无法知道是修好了，还是换成了另一种错法。

为什么这一阶段先人工裁判：样本还不大、标准还在收敛的时候，先让人看过一批真实回答，规则才写得出来。自动打分可以放在规则稳定之后。打分器和被测一起错的时候，分数越高，越难看出来。

07原先那些测试，一条都没有退出

登录是否生效，权限是否越界，异常分支是否有明确提示，兼容和回归是否还在，接口契约是否被破坏——这些检查仍然要做。模型接入之后，它们的优先级往往更高，因为一条胡话就可能把用户带去一个错误操作。

模型带来的是一种新的不确定：同一输入，措辞可能不同；它还可能多做一步，或少做一步。测试要兜住的，是这层不确定落到系统上之后，业务是否仍然可信。订单状态要落对，不该改的数据不能改，失败要能被用户看懂，也要能被你按同一条输入复现。

模型决定这一次怎么说、怎么选动作。测试仍然决定：说完、做完之后，系统是否过关。

08今天可以带走的四件事

1. JD 里的新名词，对应的是新的被测对象。用例、断言、回归这些基本功继续用。

2. 先分清裸对话、带检索的问答、会调工具的智能体，再选指标。

3. 体验看首字延迟和端到端延迟，成本看 token，正确性看结果集。

4. 结果集最少三列：问题、预期、实际。智能体再加工具和参数。判定按要点命中，按逐字相等会误伤大量可用回答。

做到这四条，你已经在做 AI 测试里最靠前、也最容易被功能测试接住的那一层。后面的榜单、自动指标、裁判模型，都是在这张结果集上继续加列，骨架不用推倒。

下期预告

下一篇回答：测开、自动化测试、大模型评测、智能体评测各自在干什么 。有疑问，评论区直接留。