e2e，全称 end-to-end，端到端。过去半年我一直在折腾这三个字母——不是写业务代码，而是确保业务代码在真实用户路径上不翻车。如果你正打算给项目接端到端测试，或者已经被一套三天两头 flaky 的 E2E 套件折磨到怀疑人生，那这篇文章大概率能对你有用。我尽量少讲虚的，多讲实操，包括框架选型、配置文件怎么设计、用例怎么写才不会变成摆设、以及把 E2E 塞进 CI 之后要面对的一系列糟心事。
先说结论：E2E 测试的价值不是“多点几个按钮”，而是把“用户真的能完成这件事”变成一条可重复、可追踪、可回归的验证链路。但它的成本也实实在在——跑得慢、稳定性难搞、改版就碎。所以这篇文章不只是教你装个框架写两个用例，而是把这半年里我踩过的坑、试过的方案、留存的配置，全部摊开给你看。
1. 端到端测试到底在测什么：三层测试体系里最后那道闸门
1.1 一个购物流程，三层测试各自守什么
先别急着写用例。我刚开始接触 E2E 时犯过一个典型错误：把什么都往 E2E 里塞，结果套件跑一次要 40 分钟，还一改前端就红一片。后来才想明白，E2E 在整个测试体系里的定位，不是“替代单元测试”，而是“守住用户路径的最后一公里”。
拿一个最常见的购物流程举例。用户打开商品页 → 加入购物车 → 进入结算页 → 填写地址 → 提交订单 → 跳转支付。这个链路里，单元测试负责的是“购物车 reducer 的状态对不对”“价格计算函数有没有精度问题”；集成测试负责的是“后端接口和前端页面能不能正确对接”；而 E2E 只回答一个问题：如果我真是一个拿着真实浏览器的用户，从商品页一路点到支付成功，系统会不会在某个环节断掉？
这三层不是互斥关系，而是互补关系。我习惯把它们想成做饭的过程：单元测试验证盐和糖各自有没有问题，集成测试验证锅和灶台搭不搭，E2E 则是把整桌菜端上桌请一个人从头吃到尾——哪怕每样食材单独都没问题，也得确认真吃的时候不会噎住。
1.2 E2E 不是“点点点”，而是“用户路径的完整承诺”
有一个认知误区要提前破除：E2E 测试的价值并不在于“测出 bug”，而在于暴露集成断裂。比如前端改了接口字段，后端还没跟上；或者某个页面的路由因为重构被改掉了；或者 localStorage 里存的 token 过期时间变了，导致流程中途跳回登录页。这些问题在单元测试里根本无法被发现，因为它们发生在模块与模块的交互层。
所以，设计 E2E 用例的核心思路不是“尽量覆盖所有页面”，而是“覆盖所有关键用户旅程”。像注册登录、下单支付、搜索筛选、个人信息修改，这些是用户高频操作的核心路径，必须作为 E2E 的常驻用例。而像后台管理系统的某个只给内部员工用的导出按钮，如果日常改动频率低，就可以不塞进 E2E，省下的执行时间给真正的关键路径。
1.3 什么项目暂时别急着上 E2E
我得劝退一些人：如果你的项目还在频繁调整信息架构，页面跳转关系一个月变一次，这时候仓促铺开 E2E 只会写出大量上线即废的用例。E2E 适合的核心前提是核心用户路径相对稳定。另外，如果团队连单元测试都还没有积累，我建议先把单测补起来再碰 E2E，否则你会在一个全是 bug 的地基上盖房，越改越痛苦。
我的经验是：先圈定 3~5 条最核心的用户旅程，用最轻量的方式跑通，再逐步扩展。一上来就追求覆盖率只会让维护成本爆炸。覆盖率这个东西，在 E2E 领域里参考意义远没有单测那么大——一个覆盖了 100 个页面的 E2E 套件，很可能不如 5 条精心设计的核心旅程有价值。
2. 工具选型：为什么我从 Selenium 迁移到了 Playwright
2.1 三个主流框架的横评
E2E 框架的选择直接决定你后面半年是省心还是糟心。这里先把主流的三个方案摆出来做个对比：
| 维度 | Selenium | Cypress | Playwright |
|---|---|---|---|
| 支持语言 | Java、Python、C#、JS 等 | 仅 JavaScript/TypeScript | JavaScript/TypeScript、Java、Python、C# |
| 架构 | 通过 WebDriver 协议控制浏览器，代码与浏览器分离 | 运行在浏览器内的 Node 进程，桥接通信 | 通过 CDP 等协议直连浏览器，无独立 server |
| 多标签页/多浏览器 | 支持，但需要手动切换句柄 | 早期不支持多标签，现代版本有限支持 | 原生支持多页面、多上下文 |
| 自动等待 | 较弱，需要大量显式等待 | 较强，自动重试查询直到元素出现 | 最强，内置自动等待 + 断言重试 |
| 调试体验 | 一般，需要借助第三方报告 | 有时间旅行回放，体验很好 | 有 Trace Viewer，可查看完整网络调用与 DOM 快照 |
| 并发能力 | 依赖外部 runner | 支持，但多浏览器有局限 | 原生支持并行 worker 与分片 |
| 网络拦截 | 需要代理方案 | 支持 | 原生支持路由拦截，极其方便 |
我知道现在很多老项目还在用 Selenium，因为团队里 Java 背景的人多，或者历史用例已经积累了上千条。但如果从零开始选型，我强烈建议在 Playwright 和 Cypress 之间选。Cypress 在纯前端团队的体验很舒服，DSL 直观、调试界面友好；而 Playwright 在大型套件、多浏览器兼容、网络模拟、性能方面的上限更高。
2.2 我选 Playwright 的三个决定性理由
我以前是 Selenium 的深度用户，用 Python 写过几百条用例。最后迁移到 Playwright，决定性理由有三个。
第一是自动等待机制。Selenium 里最常见的噩梦就是sleep(3)赌页面加载完，或者写一堆WebDriverWait条件。Playwright 对元素状态有默认自动等待：点击前会等元素可见、可命中、稳定，页面跳转时会等待导航完成。这套机制极大地减少了 flaky 用例，写起来手顺得多。
第二是测试隔离的粒度。Playwright 提出了 browser context 的概念。一个 context 内的 cookie、localStorage、缓存都是完全隔离的。这意味着我每条用例都能开一个“干净的浏览器环境”，不用手工清理数据，也不用担心用例之间互相污染。
第三是网络层可控。我可以直接拦截接口请求，mock 一个返回值，或者检查某个请求有没有发出去。这在处理第三方登录、支付回调、异常场景时几乎是救命级的功能。Selenium 要做同样的事，通常要起一个代理服务，复杂度完全不是一个量级。
2.3 迁移成本有多高：一次真实的替换记录
我迁移的规模大概是一百多条用例，花了一个周的时间。核心工作其实就是三块：选择器从 XPath 改成>import { defineConfig, devices } from '@playwright/test'; export default defineConfig({ testDir: './tests/e2e', timeout: 30_000, fullyParallel: true, retries: process.env.CI ? 2 : 0, workers: process.env.CI ? 2 : undefined, reporter: [ ['list'], ['html', { outputFolder: 'playwright-report' }], ], use: { baseURL: process.env.E2E_BASE_URL || 'http://localhost:3000', trace: 'on-first-retry', screenshot: 'only-on-failure', video: 'retain-on-failure', }, projects: [ { name: 'chromium', use: { ...devices['Desktop Chrome'] } }, { name: 'firefox', use: { ...devices['Desktop Firefox'] } }, { name: 'webkit', use: { ...devices['Desktop Safari'] } }, { name: 'mobile-chrome', use: { ...devices['Pixel 5'] }, }, ], });
这份配置里我想强调几个关键点。
fullyParallel: true意味着每条用例可以独立并行跑，前提是你的系统没有共享数据库状态。如果用例之间有强依赖，就千万别开全并行，否则你会被随机失败折磨到崩溃。retries我特意只在 CI 里配置，本地不开重试，因为本地失败应该立刻看到，好方便断点调试。
use里的trace配置为on-first-retry，意思是首次失败后自动录制一次完整 trace。这个功能是 Playwright 最值钱的特性之一——它能记录页面每一步的 DOM 快照、网络请求、控制台日志，甚至可以像回放视频一样回看整个执行过程。排查 flaky 用例时，打开 trace 文件，基本十分钟内就能定位问题。
3.3 数据 profile：测试环境的隔离设计
很多 E2E 套件频频报红，根因根本不是代码 bug，而是测试数据和环境串了。典型场景：A 用例用账号buyer@test.com下单，B 用例也用同一个账号，两边同时跑，互相把购物车数据顶掉，于是乱成一团。
我的解决方案是给每套 profile 配独立的测试账号和数据集合。具体做法分几步：
- 每个 profile 定义一组专属账号前缀，比如
e2e-chromium-buyer@domain.com、e2e-firefox-admin@domain.com。 - 用例初始化时，通过 API 创建独立的数据快照，比如每跑一轮就生成一个随机订单号，断言时只查自己的订单号。
- 涉及数据库写操作的用例，尽量用 API 直接造数据，而不是靠 UI 填写表单。因为 UI 造数据慢且不稳，API 造数据三十毫秒就能完成，还能避免很多重复操作。
这一块是 E2E 稳定性治理里最基础也最重要的工作。我见过不少团队一直抱怨 E2E flaky，结果检查最后发现一半问题出在共用测试数据上。
4. 手写一个能过审的真实用例：登录、下单、断言的完整链路
4.1 选对选择器：data-testid 的约定
无论用什么框架，选择器策略都是 E2E 用例长期可维护性的分水岭。我最推荐的做法是：前端代码为每个关键交互元素加 这里的关键细节是：先点击下单，再通过 E2E 用例的断言设计也是一门小学问。最基础的断言是“元素可见”，但只断可见性往往兜不住真正的问题。 举个例子，你点了一个提交订单按钮，如果服务端返回 500，前端可能弹出一个红色错误提示，也可能依然显示“下单成功”的占位页面——这取决于代码的质量。因此，E2E 断言不要只写“页面跳转了”，最好断言用户真正关心的结果：订单详情页出现订单号、金额、收货地址这三项信息，并且与下单时填写的数值一致。 我自己的习惯是：对于写操作类用例，断言三层——UI 上有明确成功反馈、接口调用返回预期状态码、数据在 UI 回显无误。这三层都通过，这条用例才有资格算真正守住了路径。 本地跑通了只是第一步，E2E 真正的价值在于每次代码变更后自动兜底。我目前最常用的一套 CI 配置长这样： 这份配置里有几个细节是多次踩坑后的结论。 E2E 一大痛点就是跑得慢。在仅有 60 条用例的情况下，单机串行可能要 30 分钟。我的做法是两层并行：本地层用 Playwright 自身的 要特别注意并行带来的资源问题：每个 worker 都会开一个新的浏览器实例，内存消耗不小。如果你的 CI 机器只有 2 核 4G，强行开 4 个 worker，只会出现进程被杀、浏览器启动失败这种幺蛾子。保守的策略是先按机器的核心数配置 worker，再用量化的 E2E 项目到后期，最大的敌人已经不是写用例，而是flaky test——今天跑红，重跑一遍就绿，让人怀疑人生。治理 flaky，我有一套固定的排查顺序： 第一类是环境问题：服务端还没起来、数据库没初始化、第三方依赖不稳定。这类问题通常表现为“全片大面积红”，重跑一次就好了。解决办法是加健康检查，真正的 E2E 前置校验要确认应用和服务都可访问，而不是直接开跑。 第二类是时序问题：某个异步请求比预期慢，导致断言时数据还没渲染出来。解法是找到真正的触发信号，比如 第三类是数据冲突问题：两条并行用例污染了同一条数据。解法是回到 3.3 里的数据隔离方案去查，把测试账号和工厂数据彻底隔离开。 第四类是选择器脆弱问题：UI 文案改变导致>import { test, expect } from '@playwright/test'; test('普通用户完成下单全流程', async ({ page }) => { await page.goto('/products'); await page.getByTestId('product-card-1001').click(); await page.getByTestId('add-to-cart').click(); const cartBadge = page.getByTestId('cart-badge'); await expect(cartBadge).toHaveText('1'); await page.goto('/checkout'); await page.getByTestId('email-input').fill('e2e-chromium-buyer@domain.com'); await page.getByTestId('submit-order').click(); const orderSuccess = page.getByTestId('order-success'); await expect(orderSuccess).toBeVisible(); await expect(orderSuccess).toContainText('下单成功'); await page.waitForResponse((resp) => resp.url().includes('/api/orders') && resp.status() === 200, ); });waitForResponse等接口返回，这样我们可以同时验证 UI 状态和接口行为。断言关闭前，再用.toHaveText或者.toContainText做一次精确校验，避免出现“页面显示成功但其实是旧数据残留”的假阳性。4.3 断言写什么才不算白写
5. 把 e2e 塞进 CI：分片执行、失败重试与稳定性治理
5.1 GitHub Actions 里的最小可用配置
name: e2e-tests on: pull_request: branches: [main] push: branches: [main] jobs: e2e: runs-on: ubuntu-latest strategy: matrix: shard: [1, 2, 3] steps: - uses: actions/checkout@v4 - uses: actions/setup-node@v4 with: node-version: 20 - run: npm ci - run: npx playwright install --with-deps chromium - name: Run E2E tests run: npx playwright test --shard=${{ matrix.shard }}/3 env: E2E_BASE_URL: ${{ secrets.E2E_STAGING_URL }} - uses: actions/upload-artifact@v4 if: failure() with: name: playwright-report-shard-${{ matrix.shard }} path: playwright-report/ retention-days: 7npx playwright install --with-deps chromium这句里的--with-deps会帮你把浏览器运行所需的系统库一并装上，省得在 CI 环境里缺依赖报错。shard 矩阵把测试分到三台机器上跑，大幅缩短整体用时。失败时上传报告，这样就算 CI 红了，你也不用去翻构建日志的茫茫大海。5.2 分片与并行：把半小时的套件压到 5 分钟
workers并行数，CI 层用--shard把整个测试集再按机器切分。shard数控制并行度。5.3 flaky test 治理：先分类再动手
waitForResponse，或者把断言换成.toBeVisible这种自带重试的写法。getByText失效。这类问题最好的解法是全面推行>
