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