你以为测了功能、测了性能、测了安全，就够了吗？
大家好，我是某互联网公司质量基础设施团队的负责人。
上个月，我一个在电商大厂做测试架构师的朋友老张，给我打了个电话。电话那头的声音明显有点疲惫：
“哥们儿，我们翻车了。AI客服把投诉用户全拉黑了。 ”
一、事故还原：从“投诉”到“拉黑”，只隔了一行配置
事情是这样的。
老张所在的电商平台，去年底上线了一套基于大模型的智能客服系统。上线前，测试团队做了充分的准备——功能测试、性能测试、安全测试、兼容性测试，该测的全测了。上线后的前两个月，数据也确实漂亮：人工客服咨询量下降了60%以上，老板在周会上点名表扬了好几次。
然后，翻车了。
事故的起因，是一条看似“合理”的产品需求。
产品经理提了一个需求：“当用户投诉频次过高时，AI客服应该将用户标记为高风险，限制其频繁发起投诉的能力，避免恶意刷投诉影响系统效率。”
开发同学实现的方式很简单：在AI客服的“黑名单”模块里加了一条规则——当AI在单次对话中连续识别到3次以上“投诉”类意图时，自动将该用户加入黑名单。
听起来合理吧？保护系统不被恶意刷投诉。但谁也没想到，这条规则会和AI的“情绪识别”模块产生化学反应。
AI客服在处理投诉时，有一个“情绪安抚”的子模块。当检测到用户情绪激动时，它会反复输出安抚性话术，同时反复向意图识别模块确认“用户是否还在投诉” 。结果就是：一个正常投诉的用户，在AI的反复安抚和反复确认中，被意图识别模块累计标记了5次“投诉意图” ——触发了黑名单规则。
用户被拉黑了。不是因为恶意刷投诉，只是因为他正常投诉了一次。
更麻烦的是，这条规则是静默生效的——被拉黑的用户不会收到任何通知，他们只会发现自己“转人工”永远在排队、AI客服永远在重复“当前坐席全忙”。
社交媒体上很快出现了大量帖子：“XX平台的客服把我拉黑了！”“投诉一次就被封号？”“这平台太恶心了！”
舆情发酵了48小时才被发现。 排查发现，被误拉黑的用户超过2000人。
二、根因：一个被绝大多数测试团队忽略的维度
事故复盘会上，老张的团队把测试记录翻了个底朝天。
功能测试：过了。黑名单规则本身逻辑正确，3次投诉意图触发拉黑。
集成测试：过了。意图识别模块和黑名单模块之间的调用正常。
端到端测试：过了。模拟用户发起投诉，AI正常响应。
性能测试：过了。高并发下系统稳定。
安全测试：过了。没有注入漏洞、没有越权风险。
所有测试都过了。但事故还是发生了。
问题出在哪？出在一个几乎没人会单独列出来的测试维度——模块间“副作用”测试。
老张跟我说：“我们测了A模块单独工作正不正常，测了B模块单独工作正不正常，测了A调B能不能调通。但我们从来没测过‘A正常工作的时候，会不会让B做出错误的决策’ 。”
用一句更直白的话说：我们测了“每个零件好不好”，但没测“零件们凑在一起会不会互相干扰”。
这正是AI系统区别于传统软件最危险的地方。传统软件里，模块之间的交互是确定性的——A调用B，B返回什么结果是可预期的。但在AI系统里，每个模块的输出都带有“不确定性” 。意图识别模块输出的不是0和1，而是一个概率分布；情绪识别模块输出的不是一个标签，而是一个置信度分数。
当两个不确定的输出叠加在一起，结果不是你预期中的“1+1=2”，而是“1+1=无穷多个可能”。
更隐蔽的是，传统QA框架评估的是Agent“说了什么”，而AI Agent真正的风险藏在它“做了什么”里面——工具调用、决策路径、实际操作结果。在这个案例里，AI“说”的话没有任何问题——安抚话术很标准。但它“做”的事——调用黑名单接口把用户拉黑——才是真正的灾难。
老张复盘后总结了一句话，我觉得特别精准：
“我们测试了AI能不能回答用户的问题，但我们从来没测试过AI在回答问题的同时，会不会顺手把用户给‘处理’了。”
三、什么是“副作用测试”？
这个案例暴露出的，是一个在AI测试领域被严重低估的维度——副作用测试（Side-Effect Testing） 。
所谓副作用测试，核心就一句话：测试AI在执行主要任务的过程中，会不会产生非预期的、对用户或系统有负面影响的“附带行为”。
传统软件也有副作用的概念——一个函数修改了全局变量、一个事务影响了其他事务。但在传统软件里，副作用是可枚举的——你翻一遍代码就能列出来所有可能被修改的状态。
在AI系统里，副作用是不可枚举的。因为AI的决策不是写死在代码里的，而是动态生成的。你永远无法穷举AI在什么情况下会调用什么工具、修改什么状态。
这个案例里的副作用链条是这样的：
主任务：处理用户投诉 → AI行为：识别投诉意图 + 输出安抚话术 → 副作用：反复确认意图 → 触发条件：意图识别累计3次 → 最终结果：用户被拉黑
每一步单独看都“正常”：
识别投诉意图正常
输出安抚话术正常
反复确认意图正常（产品就是这么设计的）
意图识别累计触发黑名单正常（规则就是这么写的）
但当这些“正常”的模块串联在一起，产生了一个完全非预期的结果。
这种事故在AI领域不是个例。2025年，某电商平台智能客服系统上线后，约15%的合法咨询被系统自动标记为“恶意请求”并拒绝服务。另一家电商平台的AI客服在高峰期将30%的正常客户咨询错误归类为“恶意请求” ，导致用户被强制中断服务，客户投诉量激增470% 。还有平台的智能客服系统将327条有效投诉误标记为“恶意刷单” ，导致用户账户被临时封禁。
这些事故的背后，都有一个共同点：每个模块单独测试都是“绿”的，但合在一起就“红”了。
这正是AI Agent测试中最隐蔽的盲区——AI Agent的失效往往不是单一功能失效，而是多个“正常”行为的组合产生了“异常”结果。
四、如何系统性地做副作用测试？
事故之后，老张的团队建立了一套副作用测试的框架。我整理了一下，分享给大家。
第一步：绘制“行为影响图”
在测试之前，先画出AI Agent的所有可能行为及其影响范围。
不是画架构图——架构图画的是“模块怎么连接”。行为影响图画的是 “AI做了什么事，会影响到什么” 。
比如客服Agent的行为影响图至少包括：
输出文本 → 影响：用户感知、对话记录
调用黑名单接口 → 影响：用户状态、后续服务权限
标记工单优先级 → 影响：人工处理顺序
查询用户数据 → 影响：数据访问日志、隐私合规
发送通知 → 影响：用户手机/邮箱
关键问题不是“这些功能正不正常”，而是“这些行为之间有没有非预期的级联效应”。
第二步：设计“组合场景”测试用例
传统测试用例是单一路径的——“用户输入X，期望输出Y”。
副作用测试用例是多路径组合的——“用户输入X，AI执行了行为A、B、C，我们检查有没有产生非预期的副作用D”。
具体方法：
极端序列生成：连续输入同一类意图的变体，观察AI的行为累积效应
多角色推演：模拟不同用户画像（情绪激动的、表达模糊的、反复追问的），观察AI的差异化响应
交叉压力测试：让多个模块同时处于“高置信度”状态，观察是否存在竞争条件
第三步：建立“行为审计”机制
这是最关键的一环。你不可能在测试阶段穷举所有副作用组合。所以需要在生产环境建立持续的行为审计。
具体做法：
记录AI的每一次“写操作” （修改用户状态、调用外部接口、发送通知）
建立“操作-触发条件”关联分析 ——当AI执行了某个写操作时，自动回溯触发条件链
设置异常模式检测 ——如果同一类触发条件在短时间内触发了大量相同操作，自动告警
在这个案例里，如果有了行为审计，系统会在拉黑第10个用户的时候就触发告警，而不是等到2000个用户被拉黑、舆情发酵之后。
五、给测试同行的几点建议
基于这个案例，我有几点实在的建议：
建议一：别只测“功能”，要测“行为”
传统测试关注的是“AI能不能完成任务”。AI测试需要额外关注 “AI在完成任务的同时，还做了什么” 。
功能测试回答“能不能”，行为测试回答 “会不会乱来” 。
建议二：把“模块间副作用”单独列为一个测试维度
很多团队的测试计划里，有功能测试、性能测试、安全测试、兼容性测试……但几乎没有“副作用测试”这一栏。
把它加进去。 哪怕一开始只是几个简单的组合场景测试，也比完全不测强。
建议三：在生产环境建立“异常行为检测”
测试阶段不可能覆盖所有组合。必须把一部分检测能力放到生产环境。
不是等用户投诉了才发现问题，而是让系统自己发现“自己可能出问题了” 。
建议四：警惕“每个模块都正常”的陷阱
这是最危险的信号。当每个模块的测试报告都是绿色的，反而是最需要警惕的时候。 因为问题不在单个模块里，在模块与模块的“缝隙”里。
最后
老张的事故最终的处理结果是：回滚了黑名单规则，向2000多名被误拉黑的用户逐一发了道歉短信，公关部门花了两周才把舆情压下去。
代价不小，但老张说了一句话让我印象很深：
“这次事故让我明白了一件事：AI测试不能只盯着‘AI能不能回答问题’，还得盯着‘AI在回答问题的同时，手有没有乱摸’。”
传统软件测试，测的是“确定性系统”——代码怎么写，系统就怎么跑。AI系统测试，测的是 “不确定性系统” ——模型怎么想，系统就可能怎么跑。
当系统的行为不再完全由代码决定，测试的边界就必须扩展到“代码之外”——去测试那些“代码没写、但模型可能做”的事情。
这才是AI测试真正的难点，也是真正的价值所在。
本文系作者基于真实事故案例的复盘总结。文中数据已做脱敏处理，欢迎同行交流讨论。
