当测试不再是脚本：e2e 让 AI Agent 替你跑端到端测试
项目: tester-army/e2e 语言: TypeScript 协议: Apache-2.0 今日 Star: +344
目录
项目: tester-army/e2e
语言: TypeScript | 协议: Apache-2.0
今日 Star: +344
一、一个 QA 工程师的日常崩溃
想象你是一个 QA 工程师。你写了一个测试脚本：点击"结账"按钮，等待跳转，断言页面显示"支付成功"。脚本跑了一周，一切正常。然后产品经理说："我们把'结账'按钮改成图标了。"
你的测试挂了。不是因为功能坏了，而是因为 getByText('结账') 找不到元素了。你修脚本，跑一遍，绿了。第二天，前端把按钮位置从右上角挪到了底部导航栏。你的测试又挂了。
这不是测试的问题，是测试方式的问题。传统 E2E 测试是"脚本驱动"的——你告诉它每一步怎么走，它照着走。UI 一变，脚本就废。测试工程师 70% 的时间不是在写新测试，而是在修旧测试。
tester-army/e2e 提出了一个不同的思路：你只描述目标，AI Agent 自己想办法走到那里。
二、Goal-Driven Testing：从"怎么走"到"走到哪"
看一段 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')
})
注意 agent.act() 这一行。你没有告诉它点哪个按钮、填哪个表单、走哪个流程。你只说了一句话："把工作区升级到 Pro 计划"。Agent 自己看页面、找元素、点按钮、填表单、确认提交。
这叫 Goal-Driven Testing——测试不再是步骤序列，而是意图声明。
但这里有个显而易见的问题：每次跑测试都调 LLM，又慢又贵。e2e 的解法是整个项目最精巧的部分。
三、Record-Replay：AI 只在"变了"的时候才工作
e2e 的核心机制是 Record-Replay：
1. 第一次跑：Agent 调用 LLM 看页面、决策、执行动作。每一步都被记录下来——点了哪个元素、填了什么值、跳转到了哪个 URL。 2. 后续跑：不调 LLM。直接回放上次记录的动作序列。快、免费、确定性。 3. 当 UI 变了：回放失败。Agent 自动切回 LLM 模式，重新探索路径，更新记录。
这把 AI 的角色从"运行时依赖"变成了"差异引擎"——只在东西变了的时候才花钱。类比一下：传统 E2E 是"每次都手写脚本"，e2e 是"AI 帮你写一次脚本，以后照着跑，坏了 AI 自己修"。
一个测试如果没有 agent.act() 步骤——纯断言+定位器——完全不需要模型。这意味着你可以混合使用"确定性测试"和"AI 驱动测试"，前者免费，后者按需付费。
四、Web 和 Mobile 统一引擎
e2e 不只是 Web。它的架构是分层的：
| 包 | 作用 |
|---|---|
e2e | SDK + 运行器 + CLI |
@e2e-dev/web | 浏览器引擎：Chromium / Firefox / WebKit（通过 Playwright） |
@e2e-dev/mobile | iOS / Android 引擎：模拟器和仿真器（通过 agent-device） |
@e2e-dev/github | CI 集成：把结果发到 PR 评论 |
agent.act() API，底层可以是浏览器也可以是手机。对 Agent 来说，"升级到 Pro"这个意图在 Web 和 Mobile 上是一样的——只是执行路径不同。这解决了一个长期痛点：Web 测试和 Mobile 测试是两套完全不同的工具链。Playwright 和 Appium 的 API 风格、选择器策略、等待机制都不一样。e2e 在上面套了一层"意图层"，让两者共享同一个测试逻辑。
五、BYO Model：不绑死任何供应商
e2e 的模型策略是 Bring Your Own——订阅、API Key、本地模型都行。npx e2e init 会问你用什么引擎（Web/Mobile）和什么模型供应商，然后写配置。
这很关键。测试框架绑死一个 LLM 供应商是危险的——价格变了、模型下线了、数据合规要求变了，你都得换。BYO Model 把选择权留给用户，框架只负责"把意图翻译成动作"这件事。
六、为什么这比"AI 生成测试脚本"更靠谱
过去一年有很多"AI 帮你写测试"的项目——给 AI 一个需求文档，它生成一段 Playwright 脚本。这比手写好，但本质上还是"脚本驱动"——生成的脚本一样会在 UI 变化时挂掉。
e2e 的区别在于：Agent 在运行时看页面，不是在生成时看页面。UI 变了，Agent 当场就能适应，不需要重新生成脚本。Record-Replay 又保证了不需要每次都付 LLM 的钱。
这是"AI 作为代码生成器"和"AI 作为运行时执行器"的根本区别。前者生成的代码和手写代码有一样的脆弱性；后者把"适应变化"内置进了运行时。
七、TesterArmy 的商业模式
开源框架是入口，tester.army 提供托管服务——$99/月起，250 次运行。这很聪明：框架免费用，你用得好了，不想自己维护 CI 里的模型调用和记录存储，就买托管版。开源是获客，不是慈善。
八、一个值得关注的信号
e2e 今日 +344 stars，首次上榜。它切中的痛点是真实的——E2E 测试维护成本是每个工程团队的头号抱怨。Record-Replay 机制是技术上最优雅的解法：既享受了 AI 的适应性，又避免了 AI 的运行时成本。
但真正的考验在模型成本上。Record-Replay 在"UI 稳定期"很省钱，但在"UI 频繁改版期"（比如大重构）会频繁触发 LLM 调用。一个 PR 改了 10 个页面的布局，e2e 可能要重新探索 10 条路径——这比传统脚本一次性修 10 个定位器贵得多。
e2e 的价值主张不是"比传统测试便宜"，而是"比传统测试适应变化更快"。在快速迭代的项目里，这个主张成立。在 UI 极少变化的项目里，传统脚本仍然更划算。