别被"AI 赋能"忽悠了！测试中那些 AI 搞不定的场景大盘点

写这篇之前要先表个态,避免被误读成"AI 测试无用论"。

AI 在回归测试、接口批量验证、Flaky Test 根因排查这些场景里,效率提升是真实可量化的。前几篇文章里讲过,通过 Skill 体系把领域知识结构化注入 Agent,判断质量也能持续提升。

但"能提升效率"和"能独立承担所有判断"是两件事。市场上一些"AI 赋能测试"的宣传,把这两件事混为一谈,营造出"AI 全能"的错觉。这篇文章要做的,是把那些目前 AI 确实搞不定、且短期内看不到清晰解法的场景,一个一个摆出来。

一、探索性测试中的"直觉式怀疑"

资深测试工程师有一种说不清楚的能力——看到一个功能,凭直觉觉得"这里不对劲",但说不出具体规则。

比如一个工程师在测试一个看似正常的搜索功能时,会无意识地多点几次"快速连续提交"——不是因为需求文档要求测这个场景,而是因为他过去遇到过类似界面在高频点击下触发重复请求、引发数据错乱的事故。这种警觉性不来自任何写下来的规则,来自身体记忆般的经验积累。

这种直觉的来源,是大量真实事故和异常案例在脑子里形成的模式识别,但这个模式往往没有被显式总结成规则,甚至连工程师自己都说不清楚"为什么觉得这里有问题"——只是看到某种界面、某种交互结构,警觉性就被触发了。

AI 的判断依赖结构化输入——Skill 文档里写明的规范、历史踩坑、反模式清单。如果一条经验从来没有被写下来,AI 就无法获得它。探索性测试恰恰是在"已知规则之外"寻找问题,这和 AI 依赖既有知识库的工作方式存在根本性的张力。

二、安全测试中的对抗性思维

安全测试的核心不是"验证功能是否正常",而是"主动寻找系统的薄弱点,模拟攻击者会怎么做"。

这需要一种反直觉的思维方式:不按照预期路径操作,故意输入边界值、构造异常请求、尝试绕过权限校验、组合多个看似无害的操作来制造竞态条件。

这类思维的难点在于,它的输入空间几乎是无限的——攻击者会想到的攻击路径,本质上取决于他们对系统的理解深度和创造力。AI 可以执行已知的攻击模式库(SQL 注入、XSS 等常见模式),这部分价值确定。但面对全新业务逻辑里的创造性漏洞,AI 缺乏"主动构造恶意场景"所需要的那种带有目的性的、试探性的创造力。

三、全新业务模式下,没有历史经验可参照的判断

Skill 的价值建立在"历史经验已经被沉淀"的前提上。但一个全新的业务模式刚上线时,根本不存在历史踩坑记录——没有人知道这个新功能在什么条件下会出问题,因为它从来没有出过问题,也没有人遇到过。

举个例子:团队第一次上线一个涉及多方实时协作的功能,过去所有的 Skill 文档里,都没有"多人同时编辑同一份数据"这类场景的反模式记录,因为团队从来没有做过这种业务。哪些操作顺序会导致数据冲突、哪些网络延迟条件会触发竞态、用户在什么心理预期下会做出意料之外的操作组合——这些都需要靠人去推演,而不是靠查阅已有规范。

这种场景下,AI 没有可以参照的反模式清单,没有"业务高危区域"的标注,它面对的是一片空白。真正能在这种场景里发现问题的,是对业务有深刻理解、能推演各种使用场景的人——这种推演能力本质上是创造性的,不是基于既有规则的匹配。

四、跨系统、跨组织边界的协调性问题

很多真实的线上事故,根因不在单个系统内部,而在系统之间的协调失误——A 系统的某次发布,和 B 系统的某个配置变更,恰好在某个时间窗口叠加,产生了谁都没预料到的后果。

这类问题的发现,依赖的是对多个系统、多个团队、多条业务线的横向理解,以及"这两件事看起来不相关,但实际上会互相影响"的跨域联想能力。AI Agent 通常被限定在某个特定的 Skill 和工具范围内工作,缺乏跨系统、跨组织边界主动建立联系的能力——这不是技术做不到,而是目前的工程实践里,很少有人把"系统间协调风险"这种知识结构化沉淀下来。

五、高风险操作的最终责任判断

涉及真实资金流转、用户数据永久删除、权限变更这类操作,即使 AI 给出的判断是"通过",行业普遍实践仍然要求人工复核才能放行。

比如一次涉及批量退款的功能测试,AI 扫描代码逻辑、跑完所有测试用例,输出"全部通过"。但在真正放行上线之前,团队仍然会安排人工抽样核实退款金额计算的几个关键边界场景——不是不信任 AI 的扫描结果,而是这类操作一旦出错,后果是真实资金损失,容错率极低。

这不是技术能力的限制,是责任归属的问题。AI 系统目前无法承担决策失误后的责任——出了问题,责任主体仍然是设计和操作这套系统的人和组织。这个责任结构,决定了在容错率极低的场景里,人工复核这道关卡不会被取消,至少在可预见的制度框架内不会。

六、模糊需求下的验收标准制定

测试一个明确写清楚验收标准的功能,AI 可以高效执行。但很多真实场景里,需求本身是模糊的——产品经理说"这个体验要做得流畅一点",这不是一个可以直接转化成断言的描述。

把模糊的业务期望,转化成具体、可执行、可验证的测试标准,这个"翻译"过程需要对业务目标、用户心理、产品意图的综合理解。这是一种解释性工作,而不是匹配性工作——AI 擅长在已有规则下匹配和判断,但"从模糊期望中提炼具体标准"这件事,本质上仍然依赖人的诠释能力。

结语

把上面六个场景放在一起看,能找到一条共同的规律。

它们都涉及没有先例可循的判断——探索性测试找的是未知问题,安全测试构造的是未知攻击,新业务面对的是未知风险,跨系统协调发现的是未知关联,高风险场景承担的是未知责任,模糊需求处理的是未知标准。

AI 当前的工作方式,本质上是"基于已注入的知识做匹配和执行"。Skill 体系再完善,注入的也只能是已经被人类总结过的知识。一旦场景要求的是"创造新知识"而不是"应用已有知识",这套机制就触到了它的边界。

这不是说这个边界永远不会移动——技术在进步,知识结构化的方法也在迭代。但今天讨论"AI 赋能测试"时,如果忽略这条边界,营造"AI 能搞定一切"的印象,对团队的实际决策是有害的。

写这篇文章不是要劝退任何人使用 AI 测试工具。恰恰相反——正是因为认清了边界,才能更有信心地在边界内大胆投入,把回归测试、接口验证、Flaky 排查这些 AI 能做好的事彻底交给它,把人的精力集中在 AI 搞不定的判断上。

那些喊着"AI 赋能,无人测试"的宣传,如果不说清楚这条边界在哪里,本质上是在用模糊的承诺换取你的预算和信任。

真正负责的态度,是搞清楚哪些场景该交给 AI,哪些场景必须留给人——然后把这两件事都做好。