E2E测试实战指南：从选型到CI集成，Playwright最佳实践

大概很多人一听到"e2e"这个词，第一反应是"端到端测试"。没错，End-to-End，这是我在日常工作中打交道最多的一个词。但说实话，真正搞明白 e2e 该怎么写、怎么跑、怎么维护的人，远比想象中少。我见过太多团队把 e2e 当成"点按钮的自动化脚本"，也见过太多项目把 e2e 跑成了"每周一挂、没人敢碰的定时炸弹"。这篇文章不讲空话，把我这些年摸爬滚打总结出来的 e2e 测试实战经验，从零到一完整过一遍，包括选型、设计、踩坑、排查、CI 集成，每一块都拿出来说透。

先说清楚一个事：e2e 测试不是银弹，它解决的是"系统整体行为是否符合预期"这个问题。单元测试告诉你"这个函数是对的"，集成测试告诉你"这些模块连起来没爆炸"，而 e2e 测试模拟的是真实用户的操作路径——从登录、填表、提交、到页面跳转、数据落库、最终渲染，整条链路按真实场景走一遍。它的目的不是替代前两者，而是在它们之上加最后一道保险。

我写这篇文章的核心受众，是那些已经写过一些自动化脚本、但还没把 e2e 测试体系搭起来的人。如果你刚接触这个领域，也能跟着这篇文章把整个框架搭明白。如果你已经跑了好几个月的 e2e 还在被稳定性折磨，那后面的排查部分应该能帮到你。

1. E2E测试的真实定位：它不是UI自动化，是产品验收机制

1.1 先想清楚：你的E2E到底要守护什么

很多团队上来就写 e2e，第一个问题就没想明白——你这套测试到底在守护什么价值？

我在评估一个项目的 e2e 测试方案时，先看三件事：核心用户旅程、关键业务链路、最容易回归出错的地方。什么是核心用户旅程？就是用户每天都在走的那条路，比如电商的下单流程、SaaS 的创建工作区流程、内容平台的发布流程。关键业务链路是那些一旦出错就出大事的路径，比如支付回调、权限变更、数据导出。最容易回归出错的地方，通常是那些多团队协作的公共模块、改动频繁的历史代码，以及依赖第三方服务的边界。

举个例子，我之前接手一个项目管理工具的测试体系，接手时已经有 300 多个 e2e 用例，覆盖率看着漂亮，但每次发版前跑一遍要 2 个多小时，而且挂掉一半都是因为一些无关紧要的页面样式断言。后来我做了一次大清理，把用例砍掉 70%，留下 30 个全部围绕"创建项目—邀请成员—分配任务—更新进度—生成报表"这条核心链路，跑批时间缩短到 20 分钟，可靠性大幅提升，回归时的信心反而比以前足得多。

这个例子的核心逻辑是：e2e 的投入成本远高于单元测试和接口测试，它应该被用在刀刃上——那些核心的、高价值的、失败代价高的路径。长尾功能、边缘交互、纯展示型页面，根本不应该出现在 e2e 的用例集里。

1.2 测试金字塔里E2E的位置

做测试的人都知道测试金字塔这个概念，从下到上依次是单元测试、服务测试（接口测试）、UI 测试（e2e）。越往下，执行速度越快、稳定性越高、排查成本越低；越往上，越贴近真实用户行为、覆盖链路越完整、但也越贵越脆弱。

我个人的参考比例是：50% 单元测试、40% 接口测试、10% e2e。这不是严格标准，但方向是对的——e2e 应该配比最小，因为它覆盖的是"整条链路对不对"，而不是"每个零件好不好"。

一个互联网产品从用户输入到后端返回结果，中间经过了前端路由、组件渲染、HTTP 请求、网关鉴权、服务端校验、数据库读写、缓存更新、消息队列投递等等环节。接口测试能够覆盖从请求进入到服务端返回的大部分逻辑，但它验证不了前端的真实交互；单元测试只能验证某个函数、某个类的行为，它根本不知道页面长什么样。e2e 测试的独特价值恰恰就在这里——它站在用户的视角，把整个系统当成一个黑盒来验证。

所以，e2e 测试在我的认知里，本质上是一套"产品验收机制"。它不追求覆盖率，而是追求关键路径的可用性保障。

1.3 E2E测试的边界：它不能做什么

讲清楚 e2e 能做什么，也要讲清楚它不能做什么。

• 它不能替代视觉回归。像素级的样式对比、布局错乱、字体渲染问题，e2e 测不全面。这类问题应该交给专门的视觉回归工具，比如 Percy、Chromatic 这类截图对比方案。
• 它不能精确告诉你性能问题在哪里。e2e 能测出"页面加载超过 5 秒"，但定位不了是接口慢还是渲染慢。定位性能问题需要 Profiling 工具和链路追踪。
• 它不能捕捉所有的异常边界。e2e 是预置脚本，它只会按你写好的路径走，不会像真实用户那样瞎点、乱敲、连点、拖拽。异常路径和随机操作要靠混沌测试、模糊测试去补。
• 它不能保证"接口数据格式变了"这类问题的及时发现。这类问题往往在接口测试层就能拦截，等 e2e 发现问题时，通常已经是最后一层防线了。

把 e2e 的角色想清楚，后面所有的选型、设计、排错思路，才有立足点。

2. 关键技术选型：为什么Playwright是我的首选

这篇文章不是工具测评文，但选型直接决定你后续的维护成本和使用体验，值得花一段来掰扯。目前 e2e 领域的主流工具集中在三个：Selenium、Cypress、Playwright。

2.1 三个主流工具的核心差异

先给一张表，直观感受下差异：

Selenium 是老牌工具，最大的优势是语言生态丰富，团队用什么语言都能接。但它的问题在于 API 不够现代，等待机制笨拙，写出来的脚本天然容易脆弱。我早期大量用 Selenium，最大的痛点是隐式等待和显式等待混用时，元素稍微晚出现半秒测试就挂，为了调等待逻辑耗费的时间比写用例还多。

Cypress 的体验做得很出色，时间旅行调试让定位问题非常直观，内置的自动重试让脚本稳定性也还不错。但 Cypress 的设计哲学是"只测你能控制的同源页面"，所以天然不支持多标签页、多域名场景，这在现代前端应用中非常受限——你测的页面要跳转个支付页面，跳转到第三方 OAuth 登录，直接被架住。

2.2 为什么我最终选Playwright

Playwright 的架构优势决定了它的天花板更高。它通过 CDP 协议直接与浏览器内核通信，而不是像 Selenium 那样通过中间层转发命令，所以执行效率高、控制粒度细。它的自动等待机制是我用过的工具里最完善的，不是简单的"等 3 秒"，而是等待元素可交互（visible、enabled、stable），大大减少了脚本随意写 sleep 的场景。

几个让 Playwright 胜出的关键能力：

• WebKit 支持：我可以直接跑 Safari 浏览器内核的测试，这在 Selenium 时代很难做到。iOS 上 Safari 的兼容性问题，在本地就能模拟，不用等真机。
• 网络拦截 API：page.route()一行代码就能 mock 接口、模拟慢网络、返回特定状态码。e2e 里最怕的外部依赖不稳定问题，在 Playwright 这里解决得很干净。
• Trace Viewer：测试失败时自动录制完整的浏览器操作轨迹，包括网络请求、控制台日志、DOM 快照、鼠标移动轨迹。定位 e2e 失败原因的时间，从小时级降到分钟级。
• 多浏览器并行：Playwright 默认设计就是多浏览器、多 worker 并行执行，CI 上的加速效果非常明显。

另外，Playwright 的 Codegen（代码生成器）非常好用，手动点一遍页面就能生成脚本骨架，对于业务人员参与用例设计、新手快速上手，帮助极大。当然，生成的代码通常要改造，不能直接用，但它能把最常见的交互写法给你一个正确的起点。

2.3 一个大项目的选型参考参数

如果你的团队面临选型，我建议用这些维度去打分会更清晰：

• 测试场景复杂度（多标签页/多域名/iframe/文件上传下载）
• 团队技术栈（JS/TS优先？还是Python/Java为主？）
• CI基础设施成本（要不要跑并行、跑几台机器）
• 调试效率要求（失败时定位要花多久）
• 长期维护成本（社区活跃度、版本更新频率、生态完善度）

在我自己的测试体系里，Playwright 配合 TypeScript 写测试代码，是维护体验最好的组合。类型安全让你在写测试代码时就能发现低级错误，比如选择器参数写错、方法名拼错，这个收益在大型测试项目里会被放大得非常明显。

3. E2E Profile：怎么理解"测试画像"这个概念

3.1 从Profile到E2E Profile

"e2e profile"这个说法，很多刚从传统测试思维转过来的人不理解。我换一种说法你就明白了：Profile 就是一套"测试环境画像"，它描述的是测试执行的场景上下文——用哪套环境、跑哪些用例、用什么账号、开不开网络拦截、用什么数据库种子数据、在什么浏览器内核上跑。

同一个 e2e 测试套件，在不同 Profile 下执行，可能跑的是同一个测试文件，但断言结果可能完全不同。比如某个用例在开发环境的 Profile 下跑是过绿色，切到生产环境的 Profile 下可能就红了，因为生产环境有更严格的鉴权策略或更复杂的风控规则。

我实际搭建测试体系时，会设计多个 Profile：

这个概念实操层面的核心，是把"测试套件"和"执行场景"解耦。同一套代码，在不同 Profile 下跑：本地快速调试、CI 全量回归、staging 环境上线前验证。不用为不同环境维护多份测试代码。

3.2 多环境配置的落地方式

以 Playwright 为例，它的配置文件 playwright.config.ts 天然支持多 Profile 设计。我会用 environment 变量或独立的配置文件来区分 Profile。

// playwright.config.ts 的简化示例 import { defineConfig } from '@playwright/test'; export default defineConfig({ testDir: './e2e', timeout: 60000, retries: 1, workers: 4, use: { baseURL: process.env.E2E_BASE_URL || 'https://staging.example.com', trace: 'retain-on-failure', screenshot: 'only-on-failure', video: 'retain-on-failure', }, projects: [ { name: 'chromium', use: { browserName: 'chromium' } }, { name: 'firefox', use: { browserName: 'firefox' } }, { name: 'webkit', use: { browserName: 'webkit' } }, ], });

实际跑的时候，通过环境变量在不同 Profile 之间切换：

# 冒烟测试 Profile E2E_PROFILE=smoke E2E_BASE_URL=https://test.example.com npx playwright test --grep "@smoke" # 预发布 Profile E2E_PROFILE=staging E2E_BASE_URL=https://staging.example.com npx playwright test e2e/payments/*

Profile 里除了环境地址，还包含测试账号的隔离策略。强烈建议每个 Profile 用独立的测试账号，避免不同环境的登录态互相污染。测试账号的数据尽量做成幂等的——跑十遍和跑一遍，最后的数据状态应该是一样的。

3.3 为什么Profile设计能解决90%的环境冲突问题

团队协作中最高频的 e2e 问题是什么？两个人同时跑同一套 e2e，互相把对方的数据改了，测试一会过一会挂。Profile 设计里的数据隔离策略，就是专门解决这个问题的。

我的做法是：每个 Profile 绑定一个独立的测试账号集合，配置里用一个 JSON 文件维护各个 Profile 的账号信息。跑批前有一个"数据准备"脚本，会用 API 把测试数据库重置到基线状态。用例里写死的数据——比如"轮播图ID""测试商品SKU"——都通过 Profile 的配置中心读取，而不是硬编码在测试代码里。

有一个教训值得讲。有一个阶段我们团队在测试环境跑 e2e，某天开始频繁出现"创建任务失败"的报错，排查两天没结论，最后发现是另一个同事在跑手工测试时，把测试环境的任务数上限给填满了。后来，我们把所有 e2e 用例涉及的测试数据统一加了前缀标识，并通过 Profile 数据准备脚本做定期清理，这类问题彻底绝迹。

4. 一整套E2E测试用例设计的实操方法

有了选型和 Profile 框架，接下来就是最核心的部分——用例设计。这个环节直接决定你的测试套件值不值钱。很多人认为用例设计就是"打开页面——点按钮——看结果"，这是最大的误区。

4.1 用例设计的第一原则：状态隔离

e2e 用例之间最常互相干扰的东西是什么？数据、登录态、URL、本地存储、浏览器缓存、第三方 Cookie。我在设计用例时，第一条铁律就是：每个测试用例必须能在完全隔离的状态下独立运行，它可以单独跑、乱序跑、并行跑，结果都应该是一样的。

流水线式的"上一个用例依赖下一个用例留下数据"的做法，短期很爽，长期是灾难。你想想，当第 7 个用例挂了，你为了复现它，还得先把前 6 个用例完整跑一遍，这个调试成本有多高。

状态隔离常用的手段包括：

• 用test.beforeEach在每个用例前重置关键数据状态
• 使用 API 请求而非 UI 操作来准备前置数据，比如直接用 POST 接口创建一个测试项目，而不是在页面上一步步点
• URL 里带上唯一时间戳或随机数做隔离
• 登录态通过 storageState 快照复用，而不是每个用例现场走一遍登录流程

4.2 登录态复用：E2E性能的关键优化点

登录是一个典型的"收效极低但拖慢所有用例"的操作。每次用例都走"输入账号——输入密码——点登录——等待跳转"，一来看起来很冗余，二来一旦登录接口有波动，全部用例跟着遭殃。

秘诀：把登录状态序列化保存下来，做成 storageState 文件，之后每个用例直接复用。

// 生成登录态 import { test } from '@playwright/test'; test('save authenticated session', async ({ page }) => { await page.goto('/login'); await page.getByLabel('用户名').fill('e2e-runner'); await page.getByLabel('密码').fill('secret-password'); await page.getByRole('button', { name: '登录' }).click(); await page.waitForURL('/dashboard'); await page.context().storageState({ path: 'e2e/.auth/user.json' }); });

然后在 Playwright 配置里通过storageState全局复用这个登录态，其他用例就不再走登录流程，直接从登录后的页面开始跑。

projects: [ { name: 'chromium', use: { browserName: 'chromium', storageState: 'e2e/.auth/user.json', }, }, ]

这么做，一能节省大量执行时间，二能减少登录环节的脆弱性。但要注意一个坑：storageState 里存有 Cookie，一旦账号的密码变化或者 Token 过期时间很短，这个文件会失效。解决方案是在 CI 流程里每次跑批前先执行一个"登录态生成"用例，确保用的始终是新鲜的 Token。

某些极敏感场景可以不复用登录态，比如账号注销、修改密码这类用例，就故意用未登录状态跑。这类用例在设计的时需要单独标注，不走全局 storageState。

4.3 用例断言的设计：断言的是行为，不是样式

e2e 用例里的断言，最容易踩的坑是断言一些"看着重要但其实与业务无关"的东西。比如断言某个按钮的背景色是蓝色、断言某个元素的宽度是 240 像素、断言某个图片的 src 包含特定文件名。这些断言在页面改版时第一个挂掉，而且挂掉的时候没有任何业务意义。

我的断言语义是分层的：

• 核心断言：断言业务结果。比如"下单成功，页面出现订单号""详情页显示总金额为 XX 元""导出文件的下载成功"。这类断言是 e2e 用例存在的意义。
• 关键状态断言：断言页面进入了某个关键状态。比如"从列表页跳转到了详情页""弹出了确认对话框"。这类断言确认的不是 UI 外观，而是交互流程。
• 弱断言/可选项：断言某些 DOM 存在但不断言具体内容。比如"页面底部存在版权信息"，只做存在性检查。

写断言时给自己一个检验标准：如果把这个断言删掉，测试能不能漏掉一个真实故障？如果答案是不能，这个断言就是多余装饰。反过来，如果这个断言你只是怕页面样式变了才写的，删掉它。

4.4 数据准备脚本：测试用例的"后厨"

我常说 e2e 测试里 60% 的工作量不在写用例，而在准备跑用例的环境和数据。一个合格的 e2e 项目，应该有专门的fixtures和seed目录来管理测试数据。

项目里比较健壮的目录结构长这样：

e2e/ fixtures/ users.json projects.json products.json helpers/ api.ts login.ts dataFactory.ts page-objects/ loginPage.ts dashboardPage.ts projectDetailPage.ts specs/ auth.spec.ts project.spec.ts payment.spec.ts .auth/ user.json playwright.config.ts

Page Object 模式（页面对象模式）在 e2e 测试界应该是一个常识了。核心思想是把页面结构和操作封装成类，测试用例写业务逻辑，不写 DOM 操作。这不仅让用例更可读，还能在页面结构变化时只改一个地方的代码，而不是把所有用例翻个底朝天。

举一个典型例子。这是未用 Page Object 的写法：

await page.getByTestId('project-name').fill('我的项目'); await page.getByTestId('project-desc').fill('这是一个描述'); await page.getByTestId('project-create-btn').click(); await page.getByText('创建成功').waitFor();

换成 Page Object 后，测试用例读起来就像在看一份业务报告：

const projectPage = new ProjectPage(page); await projectPage.createProject('我的项目', '这是一个描述'); await projectPage.expectCreateSuccess();

对于维护者，后者能省下大量理解成本。

5. 稳定性的源头：等待、重试与运行策略

e2e 测试到了后期，比拼的不再是用例数量，而是稳定性。一套几十个用例，跑十次有八次全绿，和一套上千个用例，跑十次有六次全绿，后者的价值其实更低。稳定性不过关，e2e 就会被团队逐渐抛弃。

5.1 等待策略：消灭一切裸sleep

Playwright 内建的自动等待已经解决了很多问题，但使用它的人依然会写出大量page.waitForTimeout(3000)这种垃圾代码。这种写法本质上是"祈祷服务器在 3 秒内给响应"，一旦网络慢一点、服务端有偶然延迟，测试就会随机挂。

推荐的等待做法：

• 等待元素可交互：page.getByText('保存成功').waitFor()或await expect(page.getByText('保存成功')).toBeVisible()
• 等待网络请求完成：page.waitForResponse()，比如等待某个 API 返回后再走下一步
• 等待 URL 变化：page.waitForURL('**/project/**')
• 尽量避免无条件的固定时长等待

// 推荐写法：等待接口响应 const [response] = await Promise.all([ page.waitForResponse(resp => resp.url().includes('/api/v1/projects') && resp.status() === 201), page.getByTestId('project-create-btn').click(), ]); // 之后可以断言 response 的 JSON expect(response.ok()).toBeTruthy();

等待策略的最高原则是：永远等一个你真正关心的事件，而不是等一个猜测的时间。

5.2 重试机制：区分"测试不稳定"和"真Bug"

我见过的团队对 retries 有两种极端态度：一种是从不开重试，挂了就报错，默认全部是真 Bug；另一种是遇到红就加重试，看到用例过了就不管了。这两种都不敢恭维。

正确的思路是：重试的目的是排除环境抖动带来的假阴性，但绝不能靠重试掩盖真实缺陷。我的建议是在全局配置里开 1 次重试，也就是一个用例首次失败后自动重跑一次。如果重跑后通过，系统会标记为 flaky；重跑后仍失败，标记为 failed。

问题集中在 flaky 用例上。flaky 用例跑十次成功九次失败一次，是最棘手的存在。它通常是某个时序问题、某个数据污染问题、某个元素偶发不可见，找到根因往往能发现隐藏的 Bug 或设计缺陷。对 flaky 用例直接加大重试次数遮掩问题，是在给未来埋雷。

5.3 并行执行的正确打开方式

e2e 测试跑得慢是最影响团队迭代体验的。Playwright 默认支持多 worker 并行执行，理论上测试文件之间互不干扰，就可以开并行。并行时最需要注意的还是数据隔离，这也是我在 4.1 里强调状态隔离的原因。

我的 CI 实践中，会把 e2e 按模块拆分成几个 shard，分别跑在不同的 CI 节点上。比如前端核心链路一个 shard、支付链路一个 shard、管理后台一个 shard。每个 shard 独立执行，整体时间能缩减到原来的四分之一。

一个值得渲染的配置：Playwright 的workers可以按 CI 机器的 CPU 核数配置。我一般用 CI 机器的 75% CPU 核数作为 worker 数，既跑得快又不会把机器资源吃满导致网络超时。

5.4 稳定性监控：给E2E加一个"体检报告"

跑了大量 e2e 之后，你会需要一份"体检报告"来观察测试健康度。我维护一个简单的指标面板：用例通过率、flaky 率、平均执行时长、单个模块的失败分布。每周看一眼趋势，flaky 率持续上升通常是某个功能模块在持续变动、测试代码没跟上，或者外部依赖质量在下降。

这个体检报告，也是和产品经理、开发团队沟通时的重要素材。你说"e2e 稳定性下降了"，他们没概念；你说"支付这条核心链路的用例本周有 40% 跑不过，主要因为支付回调超时"，他们立刻就知道优先级了。

6. 踩坑实录：一段让我改掉测试架构的排查经历

讲一段真实的排查经历，它是推动我重构整个 e2e 架构的关键点。

6.1 背景：一个莫名其妙的偶发失败

那是一个支付模块的 e2e 用例，核心步骤是：选商品——加入购物车——提交订单——跳转支付页——模拟支付成功——回到订单详情页——断言订单状态为"已支付"。这套用例连续跑了一周基本稳定，但每隔两三天会莫名挂一次。挂的位置固定在页面断言订单状态为已支付这一步，报错信息是"等待元素超时"。

当时的初步判断是支付结果回调慢了，页面状态来不及更新。于是加了等待时间和重试，但问题依旧间歇性出现。这个阶段暴露了第一个问题——只用等待时间解决问题，是在猜原因，而不是找原因。

6.2 用Trace Viewer抓出元凶

后来我开启了 Playwright 的 trace 录制，重新跑了几轮，终于在一次失败中抓到了完整录屏。

Trace Viewer 里的线索非常清晰：支付成功的请求发出后，页面上出现了一个确认弹窗，文案大意是"检测到当前会话有风险，请输入验证码"。我的测试代码根本没有处理这个弹窗的逻辑，它在等待订单状态变为"已支付"，但页面卡在验证码弹窗上。

追查根因后发现，问题出在风控系统上。支付成功的频率一旦超过阈值，风控系统就会对当前会话打上"高风险"标签，强制要求验证码验证。也就是说，测试本身没问题，是我频繁跑同一套支付用例触发了风控。

6.3 方案：重构为可控的"内部风控旁路"

这个问题的解法方向有两个，一是让风控系统放宽测试账号的阈值，二是为测试环境提供风控旁路能力。前者协调成本高，而且治标不治本——测试账号用久了仍然会被历史行为特征影响；后者的思路是把 e2e 测试的支付动作从"真实风控链路"中抽离出来。

实际操作中，我在测试环境的网关层加了一个适配器：识别到特定测试账号的支付请求时，直接返回固定成功响应，不经过真实风控判定。这一步带来的收益是巨大的，支付链路的 e2e 用例从偶发失败变成稳定通过，而且速度更快了，因为跳过了真实支付网关的等待。

这个案例给我最大的教训是：**e2e 测试要测的是你自己的系统逻辑，不是你依赖的外部系统的行为。**外部依赖要么 mock、要么旁路、要么做契约测试，绝不能让它成为你测试稳定性的短板。

7. 把E2E接入CI：落地到流水线的工程细节

最后一个关键环节是 CI 集成。很多团队的 e2e 测试写了、跑了、本地全绿，一到 CI 就疯狂挂。这通常是环境和编排的问题。

7.1 CI上最容易翻车的三个环境差异

第一个坑是屏幕尺寸和视口。本地浏览器默认视口和 CI 无头浏览器默认视口不一样，某些响应式布局的元素在 CI 上不可见或不满足可见性断言。解决方式是统一配置视口大小。

第二个坑是浏览器依赖缺失。CI 的基础镜像通常不包含浏览器依赖库，需要显式安装。推荐用 Playwright 官方的 Docker 镜像，mcr.microsoft.com/playwright:v1.40.0-focal，依赖全部打包好了，省去大量排错时间。需要注意官方镜像的版本和你的 Playwright 版本保持一致，否则容易因为浏览器版本不匹配出现奇怪问题。

第三个坑是测试数据的实时变化。本地你可能手动准备了数据，CI 每次从空库开始，如果没有数据准备脚本，测试一定会挂。所以数据准备脚本必须是 CI 流水线的一部分，而不是本地人肉操作。

7.2 CI流水线的推荐编排

这是我实践的 CI 流水线结构，可以直接借鉴：

1. 代码提交触发 pipeline
2. 单元测试+静态检查（快速反馈层）
3. 构建前端产物，启动测试环境服务
4. 执行数据准备脚本（重置数据库+写入种子数据）
5. 生成登录态（storageState）
6. 运行 e2e 测试（并行 + 失败重试 1 次）
7. 生成测试报告和 trace，归档 artifact
8. 失败时自动在 PR 上评论失败用例详情

哪个环节失败都不要慌，把每一步的日志和产出物留干净。玩 CI 玩久了你会发现，真正让人抓狂的不是报错，而是报错之后你不知道环境当时长什么样。Playwright 的 trace 工件和截图、视频工件，务必长期保留，这比任何排查工具都有用。

7.3 分支策略：什么情况下该跑什么

全量 e2e 每趟跑 20 分钟，在大型团队里如果每次 PR 都跑，开发效率会大打折扣。我按分支做分级策略：

• main 分支：合并后跑全量 e2e，作为发版前的最后闸门
• release 分支：全量 e2e + 跨浏览器项目（Chromium、Firefox、WebKit 全开）
• feature 分支：只跑 smoke Profile，验证核心链路没有因为本次改动而爆炸
• 定时任务：每天晚上跑一次 staging Profile 的全量回归，顺便验证预发布环境健康度

这套分级策略的执行效果，是把 e2e 从"发版前的负担"变成"日常开发的安全网"。团队在 feature 分支阶段就能获得关于核心链路的关键反馈，而不是等到合并之后才面对一地鸡毛。

8. E2E测试的长期维护：让测试跟着产品演进

测试代码也是代码，而且是需要持续维护的代码。很多团队的 e2e 测试为什么最终废弃？不是因为它没用，而是因为没人愿意维护它。

8.1 把测试代码当作一等公民来管理

我的实践里，测试代码和业务代码走同一套代码评审流程。测试代码的评审重点是：用例是否覆盖了核心链路、断言是否反映了关键业务规则、是否有无意义断言混入、是否有裸等待。

还有一个容易被忽视的点：Page Object 里的选择器命名和语义。选择器尽量优先使用>