【智能体测试】假如一个功能需要5轮对话提取10个指定参数 你要如何测试？

最近越来越多的老学员和粉丝跟我说公司上了智能xxx的功能，让其负责测试，却不知道怎么下手。每个看似简单的功能，如果你不知道智能体是如何开发出来，也不知道内部怎么实现逻辑，那么测试就会很难，无从下手。

比如下面这个功能：

某团公司在自己的外卖软件上上架了智能推荐用户点餐功能，IM对话中最大记忆为5轮，需要获取用户的如下需求参数：预计价位、餐类、冷热、量、口味、餐具等十个参数。

请问你要怎么测试这个功能。

测试之前，你必须先了解这个功能是如何开发的，才能知道痛点在哪。

首先，这十个参数，用户的表述可能并不清晰透彻，甚至是各种错别字，打乱顺序，少字，重复字等等。提取出来的能力取决于你公司研发时候用的底层大模型的能力。如果你测出来发现有如下的bug：

比如，用户说我想吃嘛小。有的大模型会识别出来时麻辣小龙虾，有的大模型则识别不出来，也可能是用的B参数量不够。你给开发提这种bug，开发大概率是无能力更改的，只能回复你说大模型的能力问题，和自己公司无关。除非跟领导申请加钱，比如把deepseek-r1:14B升级成70B，但这样成本会成几倍的上升，而且可能反应时间会更慢。

在看下面这个测试点：

在用户信息可以正常解读提取的情况下，这10个参数，可能会随机分配在用户的5句话中（最大5轮）。为了方便理解，这10个参数我们定位123456789 10.

所以会有下面这些用例：

用户1句话就全部中了10个参数：123456789 10

用户2句话就全部中了10个参数，但第一句中了8个，第二句中了2个。

用户3句话就中了10个参数，但第一句中了0个，第二句也中了0个，第三句一下包括了10个。

用户4句话就中了10个参数，但第一句全中了，后面全是废话。

用户5句话就中了10个参数，平均每句中2个。

....

你以为上面这些用例就完了？ no no no 。。。

上面这些本身来说是有超多个排列组合的，比如2句话全中这条，可能第一句中了2个，第二句中了8个呢？

也可能虽然同样是一句话中了2个参数，但俩个参数顺序颠倒了呢？

又或者俩个参数互相影响了呢？比如有个奶茶店卖奶茶，餐名字就叫做一杯奶茶。用户说：来三杯一杯奶茶。这其中还可能有错别字的情况，大模型还能正确识别出来么？

那这种情况，你要了解这个智能体是怎么开发出来的，才能更好测试，比如你知道，公司开发的时候提前把这些餐名写入了智能体的本地文档，并选中了回复设置中的：对来源以外的问题，按填写内容回答的设定。只有这样，大模型才能识别出来 “一杯奶茶”是一个餐品名。如果没按照这个配置，那八成是要出Bug了。

所以你要知道这些智能体开发的逻辑和配置，才能想到这个测试点。

还有上面的测试用例中，都是能正常提取全部10个参数的情况。

那提取不到的情况呢？

比如说，5句都说完了，10个参数没够呢？第6句补充了，但是第一句说的参数都忘了呢？

又比如说，第一句说了要热的饮，第二句改成了冷的饮。智能体能自动更新这个冷热参数为“冷”嘛？

还比如说，用户每个参数都说的很简洁，甚至是语音转文字时候用的方言呢？

要知道，公司的开发同事，他们也是第一次做这种功能。也不知道应该如何设置，全都是第一次，摸着石头过河。而这些缺陷bug，是需要测试同学不断的反馈，打磨，调整。才能越来越接近一个真正智能的客服的。

上面说的这些其实只是智能体测试的一个关于“工作流”的最简单的功能。

而工作流是需要关键词或者含义来触发的。一个智能体可以包含多个工作流。

那你测试的时候，就应该想到，会不会出现一个模糊有歧义的词语，能同时触发2个以上（含2个）的工作流呢？

或者说，用户一句话中，触发了俩个工作流。那你公司的智能体是执行哪一段工作流？还是有个先后顺序？

如果不能做到足够智能，那么还不如不上这些功能，否则就会被骂人工智障。而这时候，测试肯定是要背锅的。

以上可见，关于智能体的测试远比大家想的要复杂。用例也非常多，这篇文章就拿最简单的提取参数功能举了例，其实也只是庞大逻辑节点中的一个提取节点而已....

还有比如用户进入工作流时候会有个权限控制，根据用户的身份或个人肖像来提供对应的工作流。那会不会有用户区绕过这个权限控制？

你要想测明白这个问题，就要先了解这个功能是如何做出来的：

方法一是：就是在进入智能体的时候，把用户的肖像维度信息告诉智能体，让其提供对应的服务。但用户是可以以对话的方式，给智能体洗脑的，甚至直接给自己洗成了后门管理员或者内部测试人员。此时便能轻松打开智能体的更高权限了，后果会非常危险。

方法二是：智能体进入工作流时候，去触发一个接口，请求自己公司的某个数据库，看看用户的真实身份，然后屏蔽掉用户的洗脑信息。这种情况你所要测的就是抓包了。顺便测一测mock后，能不能骗过智能体。

还有其他很多方法，都是你要足够了解开发智能体的过程才可以做的，起码你要知道智能体也能发出http请求吧。还比如召回设置、召回精度。你要怎么测试，才能给出合理反馈，来证明开发随便设置的这个度数是合适的？

还比如检索策略：混合检索、语义检索。

你要怎么来向开发证明，混合检索有什么bug，语义检索又有什么bug？

归根结底，你还是要懂智能体的开发技术。而且还有精通用例设计的十一中方法。比如那五轮对话和十个参数的例子，你要明白其实用正交法就可以测，至于为啥，你了解智能体开发就会明白，在某俩个参数同时出现在一句话里的时候，是有可能引发理解偏差bug的。而正交法的核心思想，就是用最少的用例数来保证任意俩个子状态，同时出现在一条用例....

如果不懂这些，只在表面想到哪就测到哪，那最多就是相当于从前业务的黑盒测试。

如果你懂了这些，在测试就可以直接测到点子上测到骨髓里。相当于从前业务的白盒测试。

孰高孰低，不用多说了。

本文参与 腾讯云自媒体同步曝光计划，分享自微信公众号。原始发表：2025-03-17，如有侵权请联系 cloudcommunity@tencent 删除配置测试工作流开发模型