Web 测试智能体到底是什么：和 Selenium 脚本的五个本质区别

上个月团队里一个做了六年自动化的同事问我：“现在天天说Web测试智能体，它跟我把Selenium脚本写厚一点、加几个重试和截图，到底差在哪？”

我说：“你先别看‘智能体’这三个字。你先回答我一个问题：你的Selenium脚本，知道自己在测什么吗？”

他愣了一下：“知道啊，我写的用例，我知道。”

“那脚本知道吗？”

他没说话。

这就是第一个区别的入口。 Selenium脚本知道“下一步执行哪行代码”，但它不知道“当前页面意味着什么、这个结果算不算对、失败了该换哪条路”。Web测试智能体不一样，它的核心不是“执行步骤”，而是“围绕一个目标，持续感知、决策、执行、验证”。

一句话定义：Web测试智能体是一个以自然语言目标为输入，通过感知页面、决策下一步动作、执行操作、验证结果，并在失败时自主调整的测试执行系统。 Selenium脚本是“人把路径写死，机器照着走”；智能体是“人给目标和边界，机器自己找路走，但每一步都要拿证据”。

下面五个区别，不是“功能多和少”，是抽象层不同。

区别一：输入不是“步骤”，是“目标 + 边界”

Selenium脚本的输入，本质上是一段确定性路径：打开哪个URL、点哪个元素、输入什么值、断言哪个字段。路径是人写的，机器只负责执行。

Web测试智能体的输入，是一个目标加一组约束。比如：“验证用户能用优惠券完成下单，优惠券金额必须正确抵扣，订单状态必须变为已支付，不允许使用过期券。”智能体自己决定先做什么、后做什么、走哪条路径。

这个区别带来的变化是：Selenium脚本的“测试设计”发生在写脚本之前，智能体的“测试设计”一部分发生在运行过程中。 它不是替你写脚本，它是替你在页面上“找一条能走通、并且能拿到证据的路”。

但注意：目标越模糊，智能体越容易跑偏。 “测一下登录”不是目标，“用正确账号登录后必须跳转到首页，错误密码必须提示且不跳转”才是目标。智能体不是不需要人，它需要人把“什么算对”说清楚。

区别二：执行模型不是“线性脚本”，是“感知—决策—执行—再感知”的闭环

Selenium脚本的执行模型是线性的：第1行、第2行、第3行。页面变了、元素没了，脚本就报错停下。它的世界是“代码执行到哪了”。

Web测试智能体的执行模型是闭环：先感知页面（快照/可访问性树/DOM状态）→ 决策下一步（点哪个、填什么、要不要等）→ 执行 → 再感知 → 判断结果是否接近目标 → 继续或调整。

这个闭环的关键在“再感知”。Selenium脚本点完按钮，下一行是写死的等待或断言。智能体点完按钮，会重新“看”一眼页面，确认状态变了没有，再决定下一步。它不是“执行完就算”，它是“执行完要拿到反馈才算” 。

这也是为什么智能体在“页面动态变化、流程有分支”的场景里更稳——它不是靠“提前预判所有分支”，是靠“每一步都重新看”。但代价是：每次“看”都有推理开销，响应时间从毫秒级变成了秒级。它不是更快，它是换了一种快法。

区别三：定位不是“选择器匹配”，是“语义理解 + 多策略降级”

Selenium的定位，核心是选择器：ID、class、XPath、CSS。选择器一旦失效，脚本就挂。行业里有一个很扎心的数字：团队30%到40%的自动化工程时间，花在网站改版后更新选择器上。

Web测试智能体的定位，通常是语义优先、多策略降级。它先看可访问性树里的角色和名称（比如“button，名字叫提交订单”），再退到文本、testid、属性组合，最后才考虑CSS或位置。某些实现还会结合视觉信息做交叉验证。

这个区别的本质不是“智能体用的选择器更高级”，是它把“元素是什么”和“元素长什么样”分开了。Selenium脚本绑定的是“长什么样”（class、DOM路径），智能体优先绑定“是什么”（角色、名称、业务语义）。UI改版时，“长什么样”会变，“是什么”通常不变。

但别误解：语义定位不是万能的。 如果页面上有两个都叫“提交”的按钮，智能体也会犹豫。它需要你给边界，比如“在结算弹窗内找提交按钮”。智能体的定位能力，取决于你给它的上下文够不够。

区别四：断言不是“单点比对”，是“分层验证 + 证据链”

Selenium脚本的断言，通常是单点比对：assert status_code == 200、assert text == "提交成功"。它回答的是“这个点等不等于预期值”。

Web测试智能体的断言，更接近分层验证：工具层（动作有没有报错）、页面层（关键元素和文案对不对）、网络层（关键请求状态码和核心字段）、业务层（最终业务状态有没有变）。它不只回答“页面对不对”，还回答“系统真的做了没有、结果真的对吗”。

这个区别在AI系统上尤其关键。前端可以乐观更新，页面弹了“提交成功”，接口其实返回了500。Selenium脚本如果只断言Toast，会判通过。智能体的分层断言会去捕网络请求、查业务状态，把“假通过”拦下来。

但分层断言不是自动就有的。 智能体需要你告诉它“哪些层必须验、哪些字段是关键字段”。你不说，它可能只验页面层。智能体的断言深度，仍然由人的验收标准决定。 一个很现实的数据是：AI智能体本身没有像Selenium的assertEquals那样内建的断言机制，断言的质量完全取决于你把“什么算通过”定义得多清楚。

区别五：失败处理不是“报错停止”，是“诊断—修复—重试—升级”

Selenium脚本失败，默认行为是报错、截图、停止。修不修、怎么修，是人后续的事。

Web测试智能体的失败处理，是一个分级的闭环：先诊断失败类型（定位失效、等待超时、页面异常、断言失败、环境问题），再决定策略（重新感知换定位、调整等待、重试、标记疑似Bug、升级人工）。

这里最需要划清边界的是“自愈”。智能体可以修定位器和等待条件，但不应该修改业务断言。 因为它分不清“应用改版了”和“应用坏了”。一个因为改版而失效的定位器应该被修；一个因为真Bug而失败的断言，如果被“修”宽了，测试会变绿，Bug会被藏起来。

所以工程上更稳妥的做法是：自愈只发生在定位和等待层，断言的修改必须走人工审批，每一次自愈都要留日志、可审计。 智能体负责把噪音过滤掉，人负责判断“这个修复对不对”。

一个真实对比：同一个登录流程，两种写法

Selenium脚本的思路：

打开登录页 → 等元素出现 → 输入账号 → 输入密码 → 点击登录 → 等跳转 → 断言URL包含/dashboard → 断言页面出现“Welcome”。

页面改了一个按钮的class，脚本挂。错误提示是Element not found。人打开DevTools，找新选择器，改脚本，重跑。

Web测试智能体的思路：

目标：用正确账号登录后必须跳转到/dashboard，且页面出现Welcome；错误密码必须提示且不跳转。

智能体打开页面 → 获取可访问性快照 → 找到“textbox，名字叫邮箱”和“textbox，名字叫密码” → 输入 → 找到“button，名字叫登录” → 点击 → 重新获取快照 → 判断是否跳转 → 检查页面关键元素 → 捕获登录接口响应 → 校验状态码和token字段。

如果按钮的class变了，快照里的角色和名称没变，它照样能找到。如果页面跳转慢，它会等状态信号，而不是死等固定秒数。

区别不在“谁更快”，在“谁在失败时还能继续拿到证据”。

避坑指南

坑一：把智能体当成“不用写目标的自动化”。 智能体需要目标，而且目标要可验证。“测一下下单”不是目标，“用有效优惠券下单后金额抵扣正确、订单状态为已支付”才是。

坑二：以为智能体能替代所有Selenium脚本。 高频、稳定、路径固定的回归测试，Selenium/Playwright脚本依然更可控、更便宜。稳定的页面结构、需要确定性行为的场景，传统脚本依然是更优解。智能体适合探索性验证、动态页面、流程分支多、需要自适应的场景。两者是不同抽象层，不是替代关系。

坑三：让智能体随便改断言。 自愈修定位器可以，修断言必须人工审批。自愈最大的风险不是修不好，是把真Bug修成绿色。

坑四：不给边界，只给目标。 智能体会在开放空间里做合理猜测。你给它的边界越清楚（哪些元素、哪些字段、什么算不可接受），它越稳。

坑五：不看证据链，只看通过/失败。 智能体的价值不只在结论，在过程证据：快照、截图、网络请求、动作序列。没有证据链的智能体测试，和没有日志的脚本一样不可信。

最后

Web测试智能体和Selenium脚本，差的不是“有没有AI”，是测试的执行主体从“人写死的路径”变成了“围绕目标的感知—决策闭环”。

Selenium脚本回答的是：“我按这条路径走，每一步对不对？” Web测试智能体回答的是：“我要达到这个目标，当前页面允许我怎么走，我走完之后拿到的证据够不够证明目标达成了？”

它不是让测试工程师失业，它是把测试工程师从“维护路径”里拉出来，去做更值钱的事：定义目标、划清边界、审核证据。

下次你再听到“Web测试智能体”，别先想它用了什么模型。先问一句：它有没有感知、有没有决策、有没有分层验证、失败时能不能留下可审计的证据？

这四个问题答不上来，它就只是一个“会写Selenium代码的聊天机器人”。