做过端到端(End-to-End)测试的老手都清楚,痛点从来不在第一行脚本怎么写。真正的麻烦在于,前端界面只要稍微动一下,之前辛辛苦苦维护的定位器就齐刷刷失效。要是业务流程再复杂点,维护成本更是高得离谱。
有人想到用自然语言降低编写门槛,可问题是,如果每次跑测试都得让大模型现场“临场发挥”,不仅速度慢、烧 Token,关键还极难复现问题。
最近 TesterArmy 开源的 e2e 框架恰好切中了这个要害。它到底是怎么解决这个两难问题的?
1. 让 AI 去探路,让断言来说话
e2e 是一个面向网页和移动端的端到端测试工具。在脚本里,开发人员可以直接用自然语言定义目标,剩下的交给 Agent 去操作应用,最后再配合定位器和断言完成验证。

看下面这段测试会员升级的代码:
import { test, expect } from 'e2e';
test('a member upgrades to Pro', async ({ app, agent, screen }) => {
await app.open('/settings/billing');
await agent.act('upgrade the workspace to the Pro plan');
await agent.assert('the invoice preview shows a prorated amount');
await expect(screen.getByRole('status')).toContainText('Pro');
});

框架并没有把整个测试流程都塞进一个含糊的 Prompt 里。agent.act 负责理解“升级到 Pro 版”这个目标并找出实现路径,agent.assert 则负责做语义校验。在此之后,我们依然可以沿用熟悉的定位器去做确定性的断言。
这种方式显然比“让 AI 看一遍网页再下结论”要可靠得多。模型可以帮我们应付界面的千变万化和操作语义的歧义,而传统的断言则给出了可追溯的失败依据。
2. 第一次探索,往后直接回放
最精妙的设计,在于它会把那些已经通过断言验证的 Agent 操作轨迹给记录下来。等下次跑同一条用例时,只要业务逻辑没变,它就能直接回放这些操作,压根不用再调用模型去重新摸索。对于那些压根没有 agent 步骤的纯逻辑测试,甚至完全不需要消耗模型。
说白了,AI 在这里更像是一个“探路者”,而不是每次都必须在场的“驾驶员”。它既保留了自然语言写用例的自由度,又把稳定运行这件事拉回到了可预期、可控制的状态。
从工程角度讲,这个取舍相当务实。毕竟进了持续集成之后,团队盯着的远不止“脚本跑没跑通”,更在乎的是执行成本、运行效率、结果复现率,以及出问题后的定位速度。录制与回放,正好帮 AI 测试补齐了这几块核心短板。
3. 安装上手并不复杂
官方给出的初始化命令很干净:
npx e2e init
初始化时会一步步引导你选择测试引擎、Web 还是移动端,以及模型提供方,最后自动写入配置和示例用例。你完全可以用自己的订阅、API Key,甚至是本地部署的模型。
Web 引擎底层依托 Playwright,兼容 Chromium、Firefox 和 WebKit;至于移动端引擎面向 iOS 模拟器和 Android 模拟器。仓库里还贴心地准备了 Vite、Next.js、Astro、Expo、SwiftUI、Jetpack Compose、Kotlin Multiplatform、Flutter 等一堆示例,方便大家按现有技术栈对号入座。
需要注意的是,项目目前还在奋力向 1.0 版本演进。README 里也明确提醒了,小版本之间 API 和配置仍可能发生变动。
CLI 默认会匿名发送一些使用数据,不过不含任何测试内容、业务数据或凭据。如果你介意,可以随手关掉:
npx e2e telemetry disable
或者直接把环境变量 E2E_TELEMETRY_DISABLED 设为 1。
4. 它并不是要“消灭”测试代码
e2e 的真正价值,并不在于用几句 Prompt 取代测试工程师,而是更聪明地重新分配了任务:把容易受界面变更冲击的“操作”交给 Agent,把关乎业务正确性的“核心结果”留给明确断言,而那些已被证明可靠的流程则沉淀为可复用的动作。
比起一味追求所谓的“全自动 AI 测试”,这条路线要克制得多,也要接地气得多,是真正能落进团队日常开发流程里的思路。
尤其是那些同时在维护 Web 和移动端、业务流程三天两头在变,又不想每次回归都像做一场模型推理实验的团队,这个开源项目绝对值得持续观望。
项目地址:https://github.com/tester-army/e2e