二、根因：一个被绝大多数测试团队忽略的维度事故复盘会上，老张的团队把测试记录翻了个底朝天。功能测试：过了。黑名单规则本身逻辑正确，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 测试等内容，侧重测试实践、工具应用与工程经验整理。
发布于 北京
分享
评论
赞
未登录
友善发言
评论
加载中
