上个月和几个老朋友吃饭，一个在大厂带测试团队的说了一句话，桌上安静了五秒。

他说他们团队现在招人，简历上写“精通Selenium”的，已经不加分了。

不是Selenium不好。是2026年的测试，已经不在那个维度上了。

AI写代码的速度，早就超过了人类维护测试脚本的速度。Cursor和Claude Code一个下午就能重构掉你整个前端目录，你辛辛苦苦维护的几百条XPath，一夜之间全部失效。

这不是危言耸听。Meta最近公布了一组数据，他们用即时测试方法在代码评审期间动态生成测试，bug检出率提升了4倍。Slack工程团队直接把AI智能体塞进了端到端测试流程，测试用例只描述目标，不写操作步骤。

很多人已经开始感觉到——以前那套“写脚本-跑脚本-修脚本”的循环，跑不动了。

目录
一、现象：Selenium的维护成本正在吃掉你的交付速度

二、本质变化：从“告诉工具怎么做”到“告诉AI要什么”

三、核心机制拆解：AI测试框架到底怎么工作的

四、典型案例对比：三套框架，三种打法

五、工程落地启示：你现在能做什么

六、最后问一个问题

一、现象：Selenium的维护成本正在吃掉你的交付速度
先看几个数字。

Selenium仍是目前使用最广泛的端到端测试工具。但2026年的现实是：测试套件长期维护成本占比超过60%。超过一半的测试开销在修，不在测。

问题出在哪？Selenium的定位机制本质上是“坐标思维”：用CSS选择器或XPath去锁定页面上的某个元素。按钮换了个class，测试就挂了。页面加了个wrapper div，测试又挂了。

更麻烦的是，2026年的UI迭代速度跟2004年完全不是一回事。Selenium诞生那年，一个页面改一次可能要两周。现在Cursor或Claude Code改一个组件，几分钟的事。你的测试脚本根本跟不上。

结果就是：CI上30%的失败是flaky测试，不是真正的bug。工程师开始无视测试结果——一旦开始无视，bug就开始往外冒。

这不是工具的问题。这是工具的前提假设被打破了。

二、本质变化：从“告诉工具怎么做”到“告诉AI要什么”
传统自动化测试的核心是“指令”——告诉工具每一步具体怎么操作。点击哪个按钮、输入什么内容、等待什么元素出现。

AI驱动的测试框架，核心是“意图”——告诉系统你要达成什么目标，它自己想办法。

这个区别不是语言层面的，是架构层面的。

传统框架的核心是执行引擎。它接收的是确定性的操作序列，按顺序执行，遇到变化就崩溃。

AI框架的核心是决策引擎+执行引擎的组合。LLM负责理解意图、规划路径、处理异常；执行层负责把规划变成实际操作。

本质上是把“测试脚本”从步骤列表变成了目标描述+约束条件。

举个例子。

Selenium写法：

driver.findElement(By.id(“submit-btn”)).click();
driver.findElement(By.name(“email”)).sendKeys(“test@example.com”);
AI框架写法（以Karate Agent为例）：

click(‘{button}Submit’)
定位依据是用户看到的文字“Submit”，不是DOM里的id或class。class改了、结构调了，测试照跑。

这不是语法糖，是改变了测试和UI之间的耦合方式——从结构耦合变成了语义耦合。

三、核心机制拆解：AI测试框架到底怎么工作的
2026年的AI测试框架，主流架构可以抽象成三层。

意图层
接收的是“做什么”，不是“怎么做”。可以是自然语言、需求文档、Figma原型，甚至用户会话日志。

这一层的价值在于抽象层次。传统测试脚本的抽象层次是“操作”，AI框架的抽象层次是“业务目标”。抽象层次越高，对UI变化的容忍度越大。

决策层
这是AI框架的核心差异所在。

LLM拿到意图后，不是直接生成代码就完事了。它需要：

理解当前页面状态（DOM结构或视觉信息）
规划达到目标的操作路径
每一步执行后验证状态，决定下一步
遇到异常时动态调整策略
这里面有个关键设计选择：用DOM还是用截图。

截图方案（如Anthropic的computer use）：LLM看整个浏览器截图，推理出要点击的坐标。优点是通用性强，缺点是一个操作消耗上万token。

DOM方案（如Karate Agent）：LLM接收结构化DOM摘要——元素、角色、标签、状态。模型返回意图，执行层解析成具体操作。token消耗是截图方案的十分之一到五十分之一。

两种方案没有绝对优劣。截图方案适合UI高度定制、DOM不可靠的场景；DOM方案适合追求效率和成本的场景。

执行层
决策层输出的不是直接的操作指令，而是意图+参数。执行层负责把意图变成真实的浏览器操作、API调用或移动端交互。

执行层还有一个重要功能：证据录制。每一步的截图、操作日志、决策依据都要保留，方便出问题时回溯。

这个闭环是AI框架和传统框架最根本的区别。传统框架是开环的——脚本怎么写就怎么跑，跑不通就失败。AI框架是闭环的——跑不通就自己想办法。

四、典型案例对比：三套框架，三种打法
2026年的AI测试框架市场，不是一个赢家通吃的局面。不同框架解决不同的问题。

Karate Agent：AI原生的Selenium替代品
定位最明确：用AI解决定位器维护问题。

核心机制是“显示文本定位+LLM故障恢复”。正常路径下用文本定位，零token消耗，速度跟Selenium一样快。只有定位失败时才调用LLM分析页面、恢复流程。

关键设计：LLM是备用方案，不是默认方案。这保证了成本和速度可控。

适合场景：有大量现有Selenium测试、被定位器维护折磨的团队。

Midscene.js：视觉驱动的跨平台方案
字节跳动开源，核心理念是用自然语言描述目标，AI完成操作。

跟Karate Agent的区别在于视觉优先。Midscene用多模态模型理解界面，不依赖DOM。这意味着它可以在canvas、移动端、桌面端等DOM不可用的场景工作。

适合场景：跨平台UI测试、canvas应用、移动端自动化。

QA Wolf：Agentic自动化测试平台
输出的是可审查、可入库、可在CI里稳定执行的Playwright代码。

QA Wolf用多个专门的AI agent分工协作：有的识别业务流程，有的生成测试代码，有的诊断失败原因并更新测试。

关键区别：它不是“运行时靠AI动态执行”，而是“用AI生成确定性代码，然后在CI里确定性执行”。

适合场景：需要代码审计、版本管理、CI集成的团队。

怎么选
这不是一个“哪个最好”的问题。这是一个“你的约束条件是什么”的问题。

如果你的痛点是维护成本，选Karate Agent这类“传统框架+AI增强”
如果你的痛点是跨平台适配，选Midscene.js这类“视觉驱动”
如果你的痛点是测试生成效率，选QA Wolf这类“Agentic自动化”
如果你的痛点是视觉回归，选Applitools这类“视觉AI测试”
五、工程落地启示：你现在能做什么
说几个实在的建议。

1. 别急着全量替换
   Slack工程团队的做法值得参考：确定性测试继续跑，AI智能体测试用在端到端层。前者保证核心业务逻辑的快速、可复现验证，后者解决界面变更带来的测试脆弱问题。

先把最痛苦的几条流程切过去，跑通了再扩大。

2. 关注架构，不只是工具
   2026年的主流开源方案普遍采用“可编程测试运行时”（PRT）作为执行引擎。Apache OpenTAP 3.0已经把测试步骤抽象为可插拔的Action Node。

这意味着什么？测试正在从“脚本编写”变成“架构设计”。

你不需要学会所有AI测试框架的API。你需要理解的是：意图如何表达、决策如何闭环、执行如何验证。

3. 重新审视你的测试数据
   AI测试框架的决策质量，高度依赖上下文信息的质量。DOM摘要是否完整、页面状态是否可观测、业务规则是否可描述——这些比“会不会用某个工具”更重要。

4. 关注可观测性
   AI智能体驱动的测试，执行路径是不确定的。如果出了问题你不知道它当时看到了什么、做了什么决策，你就没法排查。

结构化执行日志、每一步的截图和决策记录，不是可选项，是必选项。

六、最后问一个问题
上面聊了这么多，核心其实就一句话：

你的测试体系，是面向“稳定UI”设计的，还是面向“持续变化”设计的？

如果今天你的前端团队全面接入AI编码助手，UI迭代速度翻三倍，你现在的测试套件能撑多久？一周？一个月？还是第一天就崩了？

这个问题没有标准答案。但值得你现在就想清楚。

毕竟，等到CI全线飘红的时候再想，就晚了。

本文部分内容参考了霍格沃兹测试开发学社整理的相关技术资料，主要涉及软件测试、自动化测试、测试开发及 AI 测试等内容，侧重测试实践、工具应用与工程经验整理。