Playwright/Appium 新选择：爆火开源 AI E2E 框架，解锁自动化测试新思路

哈喽，宝子们，最近在GitHub 上翻到一个项目，人气一路飙升。它就是：TesterArmy 推出的开源 E2E 测试框架 e2e。

它火的原因其中有很重要的一点就是：大佬点赞不代表适合你，但「确定性加智能体」这个混合方向，确实被一圈人验证过值得做。

今天就带大家详细了解下这款火爆的AI E2E框架。

一、什么是e2e？

e2e 是 TesterArmy 开源的一款端到端Agent测试框架，GitHub地址：https://github.com/tester-army/e2e，开源协议为Apache2.0。

一句话简介：你用自然语言描述业务目标，AI Agent自动驱动Web、iOS、Android应用完成操作；同时保留传统locator定位+代码断言，用来校验结果，操作交给AI，结果校验交给代码。

直接看官方示例，一段代码就看明白。

   
   
   
   // tests/checkout.e2e.ts
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');
}); 

二、你为什么需要它？

理由1：混合式 Agent E2E 框架

用 AI 做 e2e 测试，这两年大家多少都用过一些，但基本最后都会遇到两类问题。

第一类，让 AI 生成 Playwright 脚本，生成完就归脚本管。看着省事，老问题一点没少。UI 改一个按钮文案，一堆定位器跟着失效，CI 红一片，你还是得人工去修。AI 只在写脚本那一刻出场，后面的维护成本还是全归你。

第二类，测试本身就是一段自然语言，每次运行都让模型现场推理着把流程走完。灵活是真灵活，贵也是真贵。CI 每晚跑一遍回归，登录页一个字没改，模型也得重新看一遍、重新想一遍、重新点一遍，每次都是真金白银的 token。而且纯靠模型驱动的测试在 CI 里跑，稳定性没法看，今天过明天挂。

e2e 项目的解题思路，是让两种写法在同一条测试里各管一段。哪个步骤你写得出稳定定位器，就用传统写法；哪个步骤界面复杂、selector 难写、改动频繁，就丢一句自然语言给 agent.act()。

官网有句话总结得很准：AI where it helps, code where it counts，AI 管不确定的部分，代码管必须精确的部分。

Vercel CEO Guillermo Rauch、Sentry 创始人 David Cramer、Expo 官方团队都在 X 上公开夸过它（我在它官网口碑墙上翻到的，这类背书听听就行）。大佬点赞不代表适合你，但「确定性加智能体」这个混合方向，确实被一圈人验证过值得做。

理由2：和主流 E2E 框架差异

简单理解： Playwright/Appium：你精确告诉框架，去找哪个元素，做什么动作； e2e Agent模式：你告诉框架业务目标是什么，AI自己寻找元素完成动作；关键校验环节，依旧由你精准控制。

三、它的核心亮点是什么？

✅ Web、iOS、Android 一套框架不用同时维护Playwright + Appium两套自动化技术栈，一套API同时支持网页、模拟器App测试，降低多端自动化的学习和维护成本。

✅ Agent步骤缓存回放，降低成本，提升稳定性Agent操作成功执行一次后，框架缓存操作序列。后续执行如果页面没有大改动，直接回放动作，不再调用大模型，节省token费用，CI流水线执行更稳定；只有页面发生明显变化，缓存失效，才会重新调用AI识别页面。

✅ 存量脚本支持迁移官方提供Playwright、Appium脚本迁移工具，可以自动转换原有自动化脚本，不用从零开始重写全部用例，降低团队试点门槛。

✅ Apache2.0开源，本地部署可控区分开源e2e框架和TesterArmy商业SaaS平台，开源版本代码本地运行，不受制于云平台，测试资产完全自己掌控。

当然，亮点之外也要理性看待短板：

1. 复杂页面、弹窗嵌套、元素高度相似场景，Agent依然存在识别出错的可能性；
2. Agent执行效果，高度依赖自然语言描述的质量，需要团队统一描述规范；
3. 项目比较新，国内社区案例、踩坑资料偏少，调试工具、测试报告体系还在持续迭代；
4. 页面改动导致缓存失效后，依旧会产生大模型调用成本；
5. 不适合金融等高合规场景，这类场景要求每一步操作完全确定性、可追溯。

四、如何快速上手？

1. 初始化项目

一行命令直接生成脚手架：

   
   
   
   npx e2e@latest init

初始化向导会引导你选择被测端（Web/移动端）、配置模型服务商，自动生成配置文件与示例用例。

2. 一份典型混合式测试用例

   
   
   
   import { test, expect } from 'e2e';

test('账号登录后访问个人中心页面', async ({ agent, page }) => {
  // AI Agent：自然语言描述业务目标，无需手写元素定位器
  await agent.act('打开网站，输入用户名密码完成登录操作');

  // 传统硬编码断言，确定性校验结果，不依赖AI判断
  await expect(page.getByText("个人中心")).toBeVisible();
})

脚本中登录操作交给AI，即便前端修改按钮文案、微调DOM结构，只要业务不变，Agent依然可以完成登录；但结果校验，坚持使用代码断言，规避AI幻觉带来漏测风险。

五、适合哪些人群？

✅ 适合尝试

1. 测试/测开同学：Web、React Native App产品迭代快，UI频繁改版，现有自动化定位器维护工作量巨大；
2. 团队同时需要维护Web+移动端自动化，希望统一技术栈，减少Playwright+Appium两套框架的运维压力；
3. 想体验AI Agent自动化，但不想完全交出测试控制权，希望保留代码断言保障结果可靠；
4. 用来做产品主流程、冒烟回归，而不是大批量细粒度校验场景。
   
   

❌ 不建议直接引入

1. 后台管理系统，UI长期稳定几乎不改动，传统Playwright性价比更高；
2. 金融等高合规系统，对每一步操作确定性、可追溯性有硬性要求；
3. 需要大批量细粒度断言、强稳定门禁的全量回归场景。

结尾

总的来说，e2e并不是用来取代Playwright、Appium，而是提供了一条「AI智能操作 + 代码确定性断言」的新路线。

如果你正在被大量自动化脚本定位器维护折磨，不妨拿项目跑个demo亲自体验。但切记不要直接把核心流水线全部迁移，优先小范围试点，评估稳定性与收益之后，再决定是否扩大使用范围。

💬 本期讨论话题（欢迎在评论区聊聊）

讨论1. 在你的自动化项目中，脚本维护占日常测试工作的比例大概有多少？

讨论2. 如果引入e2e这类AI Agent测试框架，你最担心的风险是稳定性、模型成本还是团队学习成本？

讨论3. 你觉得AI E2E未来是补充现有自动化，还是会慢慢完全替代传统Playwright这类框架？

以上话题，任选其一，欢迎评论区留言。小编会在下下周一（2026 年 10 月26 日）下午，选取 1 位“关注+点赞+留言”的幸运用户，送出《HarmonyOS应用开发实战》1 本，快来评论区互动吧~