AI-Agent走进E2E测试-自动执行工程账
在 AI Agent 是否适合做端到端(E2E)测试这个问题上,工程社区里最近出现了一场有意思的讨论。一边是「AI Agent 能做所有事」的乐观派,另一边是「老老实实用 node + playwright」的实用派。讨论的最终落点,既不是哪一边获胜,也不是非此即彼,而是一种「混合策略」的工程化方案。
事情的起因是一位工程师分享自己用 AI Agent 做 E2E 测试的经验。他做了一个叫 TinyShip 的产品,后面的十几次迭代,核心流程都是 AI Agent 驱动的视觉确认 + 传统脚本的固化测试。这个流程带来了巨大的效率提升。
但评论区立即出现质疑。有人直接说:「E2E 不要用 agent 做啊,用 node + playwright 做,测试稳定,速度快,还不花 token。」这条评论获得了将近 200 个点赞。
争论的核心,其实是一个工程效率问题:AI Agent 在 E2E 测试这种场景下,究竟应该扮演什么角色?
一种新的混合策略
经过多次迭代,工程社区逐渐形成了一种共识——AI Agent 与传统 E2E 测试工具,不是替代关系,而是协同关系。
具体来说,这种协同可以分为三层。
第一层是「想清楚要测什么」。在写新特性的测试之前,先用自然语言描述测试目标,这一步由人来完成,因为「要测什么」这件事,目前 AI 还不能完全替工程师思考。
第二层是「AI Agent 走一遍视觉确认」。这是 AI Agent 真正发挥价值的地方。让 AI 通过语义化的辅助功能树(Accessibility Tree)去确认页面状态、交互流程是否符合预期。这一步的核心是「视觉确认」,不是「完整截图对比」。后者会因为像素差异、字体渲染、动画状态等原因产生大量误报;前者只关注「语义是否正确」,大大节省了上下文消耗和 token 成本。
第三层是「传统脚本固化测试」。等 AI Agent 确认流程没问题之后,用传统的 node + playwright 写出稳定的脚本测试,跑 CI 流水线。这一步必须由人来完成,因为 CI 流水线需要的是稳定、可重复、不依赖外部 AI 服务的脚本。
关键工具:语义化辅助功能树
这套混合策略的核心,是「语义化辅助功能树」这个概念。
传统的 E2E 测试工具如 Playwright、Puppeteer,默认操作方式是 DOM 选择器 + 像素对比。这种方式对视觉变化非常敏感,稍微改一下样式就会导致测试失败。而 AI Agent 看到的「世界」则是语义化的——它不关心某个按钮是蓝色还是绿色,只关心「这里有一个按钮,它的标签是『提交订单』」。这种语义化的视角,让 AI 在处理视觉确认时,远比传统工具稳定。
但 AI Agent 的成本问题不容忽视。每次调用 AI 模型都要消耗 token,而 E2E 测试往往是大量重复执行的任务。如果每个测试用例都要 AI Agent 介入,token 成本会迅速膨胀。因此,这套混合策略的本质,是用 AI Agent 处理那些「需要判断」的环节,用传统脚本处理那些「只需要验证」的环节。
一些工程上的考量
这套流程对工程师有几个具体要求。
一是必须先把测试目标想清楚。如果一个工程师连「要测什么」都说不清楚,那 AI Agent 也无法帮他完成视觉确认。
二是对 Accessibility Tree 的理解要到位。AI Agent 通过这个语义化的接口和页面交互,因此页面的 Accessibility Tree 必须组织良好、语义清晰。如果页面的可访问性很差,AI Agent 也无能为力。
三是 Playwright 或类似工具的脚本能力仍然是基本功。AI Agent 帮你完成了视觉确认,但把测试固化为 CI 流水线中的可重复执行步骤,仍然需要工程师写代码。
TinyShip 的实际使用
TinyShip 是一个相对小众的产品,但它的十几次迭代都跑在了这套流程上。在该项目的实践中,工程师的具体操作流程是这样的。
写新特性的时候,先想清楚要测什么,再写代码,然后让 AI Agent 走一遍视觉确认,确认通过之后,最后写 Playwright 测试。整个流程每一步都有人参与,AI Agent 并不替代工程师的判断,而是替工程师做那些「耗时但不需要太多判断」的工作。
这种模式之所以能在小团队中跑通,核心是它不要求工程师把所有工作都交给 AI。AI Agent 介入的环节是「视觉确认」,这是过去最难自动化的部分;「想清楚要测什么」和「写 Playwright 测试」这两端,仍然需要工程师亲力亲为。
我的评价
AI Agent 在 E2E 测试中的应用,最值得关注的不是「它能做什么」,而是「它应该在哪个环节介入」。从目前的工程实践看,AI Agent 的最佳位置,是在「视觉确认」这一层——既要消耗 token,又要做出判断的工作。它不适合做「跑 CI 流水线」这种需要稳定、可重复、不消耗额外 token 的工作。
更深一层,这套混合策略的本质,是一种「AI 增强人类」而非「AI 替代人类」的范式。工程师依然是核心,AI Agent 只是帮工程师处理那些繁琐、耗时的视觉确认工作。这种范式,在其他软件工程领域,同样适用。
反面观点
对这种混合策略,也有不少质疑。
一种观点认为,AI Agent 介入视觉确认,会带来新的不确定性。传统脚本测试虽然写起来繁琐,但行为完全可预测;AI Agent 视觉确认的结果,可能因为模型版本、温度参数甚至 prompt 的微小变化而不同。这种「不稳定」是 CI 流水线无法接受的。
另一种观点指出,让 AI Agent 走视觉确认,需要消耗大量 token。一个完整页面的 Accessibility Tree 描述,加上 AI 的判断过程,可能要消耗几千 token。如果每个测试用例都这样做,总成本会非常高。
还有一种声音来自「学习曲线」。团队要采用这套混合策略,工程师必须熟悉 AI Agent 的使用,理解 Accessibility Tree,掌握 Playwright 脚本编写。这套技能栈的学习成本,对很多团队来说并不低。
写在最后
E2E 测试领域的这场讨论,反映了一个更大的趋势——AI Agent 不是「万能替代品」,而是一种「特定场景的辅助工具」。把它放在合适的位置,它能带来显著效率提升;放错了位置,它只会带来更多问题。
对于工程师来说,关键不是「要不要用 AI Agent」,而是「在哪里用 AI Agent」。一旦这个问题想清楚,工程效率的提升,会比想象中来得更快。
关键构成
- • 推特讨论中,关于 E2E 测试的两种思路:AI Agent 视觉确认 + node + playwright 传统脚本,后者的评论获得近 200 个点赞。
- • AI Agent 通过语义化的辅助功能树(Accessibility Tree)与页面交互,避免直接使用 DOM 选择器或完整截图。
- • TinyShip 的十几次迭代全部跑在这套混合流程上,核心思路是先想清楚要测什么,再写代码,然后让 AI Agent 走视觉确认,最后写 Playwright 脚本。
- • 关键 token 节省点:用语义化辅助功能树代替完整像素对比,大幅减少上下文消耗。
- • 一个核心限制:CI 流水线仍然需要稳定、可重复的传统脚本,AI Agent 无法承担这个角色。