1. 这个项目到底在解决什么问题第一次看到“用自然语言写 E2E 测试”这个说法我脑子里第一反应是又是一个把 Playwright 包一层、让大模型生成脚本的玩具吧。但仔细看完 e2e 这个项目的思路之后我发现它真正有意思的地方不在“生成”而在“录制”和“回放”。先说清楚它是什么。e2e 是一个开源测试工具核心能力有两条第一你可以用自然语言描述一个端到端测试场景比如“打开首页搜索某个关键词确认结果列表里出现目标条目然后点进详情页检查标题”它会驱动一个 Agent 去真实浏览器里把这些操作跑一遍第二Agent 跑过的每一步操作会被记录成一份“回放缓存”下次再跑同样的场景时直接走缓存不再调用模型。这两条能力组合起来解决的是一个非常现实的痛点大模型驱动的自动化测试单次跑起来很惊艳但成本高、速度慢、结果不稳定根本没法进 CI。你不可能每次提交代码都让模型重新“思考”一遍怎么点按钮那既烧钱又不可靠。e2e 的思路是——让模型只负责“第一次探索”把探索结果固化成可复现的操作序列后续回归测试全部走缓存。适合谁来参考这个项目我梳理了三类人。第一类是正在做自动化测试、被传统选择器维护成本折磨的测试工程师元素一改一堆># 初始化项目以 Node 生态为例 mkdir e2e-demo cd e2e-demo npm init -y # 安装测试工具与浏览器驱动 npm install -D e2e-runner npx e2e-runner install-browsers安装完成后创建配置文件。配置里通常需要指定几个关键项// e2e.config.js module.exports { baseUrl: http://localhost:3000, cacheDir: ./.e2e-cache, model: { provider: your-provider, modelName: your-model, apiKeyEnv: E2E_MODEL_KEY }, replay: { selfHeal: true, maxHealAttempts: 2 } };selfHeal控制是否开启自愈maxHealAttempts限制单步最多自愈几次防止无限循环。这两个参数建议初期都开着等缓存稳定后再考虑关闭自愈以追求极致速度。4.2 编写第一个自然语言测试创建一个测试文件用自然语言描述场景。不同工具的语法略有差异但核心结构类似# tests/login-and-search.yaml name: 登录后搜索商品 steps: - 打开首页 - 点击页面右上角的登录按钮 - 在用户名输入框输入测试账号 - 在密码输入框输入测试密码 - 点击登录按钮并等待跳转完成 - 确认页面顶部显示用户昵称 - 在搜索框输入关键词并回车 - 确认搜索结果列表中出现至少一条包含该关键词的记录 - 点击第一条搜索结果 - 确认详情页标题包含该关键词这份描述里每一步都是单一意图断言具体定位基于语义。这是探索成功率最高的写法。4.3 执行探索并生成缓存第一次执行时工具会走探索模式调用模型驱动 Agent 完成操作。npx e2e-runner run tests/login-and-search.yaml --explore执行过程中你能看到浏览器自动打开、逐步操作。如果某一步卡住了工具会报错并提示是哪一步失败。这时候不要急着改缓存先检查自然语言描述是否有歧义或者页面本身是否有问题。探索成功后缓存文件会生成在cacheDir下。打开看一眼确认操作序列和你的预期一致。4.4 回放执行与 CI 集成缓存生成后再次执行同样的测试工具会自动走回放模式。npx e2e-runner run tests/login-and-search.yaml --replay回放模式下执行速度会快很多而且不依赖模型服务。这时候就可以把它接进 CI 了。CI 配置里只需要保证应用能启动、缓存文件存在即可。# CI 流水线片段示意 test: steps: - 启动应用 - 等待应用就绪 - 执行 e2e 回放测试 - 上传测试报告提示CI 里建议先用--replay跑一遍如果失败再决定是否触发自愈。不要让 CI 默认开启自愈否则一次失败可能触发大量模型调用既慢又不可控。4.5 缓存更新的正确姿势当页面改版导致回放失败时有两种更新策略。第一种是局部自愈让工具自动修复失败的步骤第二种是重新探索整个场景。我的建议是如果改动只影响一两个步骤用自愈如果改动涉及多个步骤或整体流程直接重新探索避免缓存里新旧逻辑混杂。重新探索前建议把旧缓存备份一下方便对比。有时候新探索的结果反而不如旧的可以回滚。5. 常见问题与排查技巧实录5.1 探索阶段频繁失败怎么办这是最常见的问题。排查顺序建议如下现象可能原因排查方法Agent 找不到元素页面可访问性差检查元素是否有 role、aria-labelAgent 操作顺序混乱自然语言描述有歧义拆分步骤明确每步意图Agent 卡在某一步页面加载慢或异步渲染在描述中加入等待条件Agent 定位到错误元素页面存在多个相似元素用更具体的文案或上下文限定我踩过最深的坑是页面用了大量图标按钮没有文字也没有 aria-labelAgent 完全不知道那个按钮是干嘛的。后来给关键按钮补了 aria-label探索成功率立刻上来了。这件事让我意识到自动化测试的很多问题本质上是页面质量问题的暴露。5.2 回放时定位失败但自愈也失败自愈失败通常意味着target_description也不够明确或者页面变化太大模型也无法根据描述定位。这时候要手动介入检查缓存里的定位策略补充更稳健的定位方式。一个实用技巧是在缓存里给关键元素加多个定位策略形成 fallback 链。比如{ target_locator: [ { type: role, role: button, name: 提交订单 }, { type: text, value: 提交订单 }, { type: css, value: [data-actionsubmit-order] } ] }这样即使 role 定位失效还有文本和 CSS 兜底。5.3 缓存文件冲突怎么处理多人协作时缓存文件容易冲突。我的做法是把缓存文件按测试场景拆分一个场景一个文件减少冲突面。同时在 CI 里加一个检查如果缓存文件在 PR 里被修改要求必须有人 review避免误提交。5.4 模型调用成本失控探索阶段调用模型是必要的但如果不加控制成本可能超预期。几个控制手段限制单次探索的最大步数避免 Agent 陷入死循环给模型调用设置超时避免长时间挂起在本地开发时用较小的模型做探索稳定后再用大模型重新探索一遍。5.5 断言太弱导致漏测Agent 探索时倾向于“能跑通就行”断言往往偏弱。回放阶段如果断言太弱测试通过了但实际功能已经坏了。解决办法是在缓存里手动加强断言比如增加对关键文本、数量、状态的检查。这一步没有捷径需要测试人员根据业务理解来补。6. 这套模式还能怎么扩展把 e2e 的“探索一次、回放多次”模式抽象出来它其实是一个通用的 Agent 产物持久化方案。我想到几个可以迁移的方向。第一个方向是网页数据采集。用自然语言描述要采集的字段Agent 探索一次找到数据位置把定位策略缓存下来后续批量采集直接走缓存速度快且稳定。第二个方向是RPA 流程自动化。很多后台操作流程固定但界面复杂用自然语言描述一次缓存操作序列后续定时回放执行。第三个方向是接口测试的探索式生成。虽然 e2e 针对的是浏览器但同样的思路可以用在接口测试上——Agent 探索一次接口调用链缓存请求序列后续回归直接重放。我在实际使用中最大的体会是Agent 的价值不在于每次都智能而在于把一次智能的成果固化下来变成可复用的资产。这个思路比单纯追求“更聪明的模型”要务实得多。毕竟工程世界里稳定和可复现永远比惊艳更重要。最后分享一个小技巧如果你在评估类似的工具重点看它的缓存格式是否透明、是否可人工编辑、是否有版本管理机制。这三点决定了它能不能真正进生产环境而不是停留在演示阶段。