1. 从“e2e”说起端到端测试到底在测什么第一次看到“e2e”这个词很多人会愣一下——它其实是 end-to-end 的缩写中文叫“端到端”。在软件研发语境里e2e 测试指的是从用户真实使用路径出发把整个系统当作一个黑盒验证从入口到出口的完整链路是否走得通。它不关心某个函数写得漂不漂亮也不关心某个接口返回的字段是不是符合预期它只关心一件事用户点下去结果对不对。我做了十多年一线研发和测试见过太多团队在单元测试上覆盖率刷到 90%结果一上线用户连登录都登不进去。问题出在哪单元测试测的是零件e2e 测的是整车。零件都好装在一起未必能跑。e2e 的价值就在于它把“整车能不能上路”这件事用自动化手段反复验证。最近“e2e profile1”这个词在技术社区里被频繁提及我理解它指的是一套端到端测试的配置档案或者说预设方案——类似你打开一个测试框架它给你一个开箱即用的 profile里面预置了浏览器驱动、超时策略、重试机制、报告格式等一整套参数。这个思路很实用因为 e2e 测试最让人头疼的往往不是写用例而是环境配置和稳定性调优。一个成熟的 profile 能帮你省掉大量踩坑时间。这篇文章适合谁看如果你是刚接触 e2e 测试的开发者想搞清楚它和单元测试、集成测试的边界在哪如果你是团队里负责搭建测试体系的人正在纠结选什么工具、怎么配参数或者你已经被 flaky test不稳定用例折磨得够呛想找一套可复现的稳定方案——那接下来的内容应该对你有用。我会从设计思路、核心细节、实操过程、问题排查四个维度把 e2e 测试这件事拆开揉碎讲清楚所有参数和步骤都尽量给到可直接抄作业的程度。2. e2e 测试体系的设计思路与方案选型2.1 为什么 e2e 不能替代单元测试但也绝不能被替代很多团队在资源紧张的时候会做一个取舍要么只写单元测试要么只写 e2e 测试。这两种做法我都试过结论是都不对。单元测试和 e2e 测试的关系更像是“体检”和“试驾”。体检能查出你血脂高不高、心率齐不齐但没法告诉你这辆车开起来方向盘会不会跑偏。试驾能告诉你整车感受但没法定位到是哪个螺丝松了。e2e 测试的核心设计原则是“用户视角”。这意味着你在写用例的时候不能想着“我先调这个接口再调那个接口”而要想“用户打开页面看到什么点了什么期待什么”。这个视角的切换说起来简单做起来难。我见过不少团队写的 e2e 用例本质上是一堆接口调用的堆砌只是套了个浏览器的壳。这种用例跑起来很快但一旦失败排查成本极高因为它跳过了 UI 层你根本不知道是前端渲染错了还是后端数据错了。所以我的设计思路是e2e 用例必须经过真实的 UI 交互。该点击的点击该输入的输入该等待的等待。只有这样它才能覆盖到那些单元测试永远覆盖不到的问题——比如某个按钮在特定分辨率下被遮挡了比如某个异步加载的数据在慢网络下没渲染出来比如两个组件之间的状态传递出了偏差。2.2 工具选型为什么我最终选了 Playwright 而不是 Selenium工具选型这件事没有绝对的好坏只有适不适合。我早期用的是 Selenium后来试过 Cypress再后来转到 Playwright。说一下我的决策逻辑。Selenium 的优势是生态老、语言绑定多、社区大。但它的痛点也很明显等待机制原始需要手动写大量sleep或WebDriverWait浏览器驱动版本管理麻烦Chrome 一升级驱动就得跟着换多标签页和 iframe 的处理写起来很啰嗦。Cypress 的开发者体验很好自带时间旅行调试但它的架构决定了它很难做多标签页测试而且跨域场景支持有限。Playwright 是我目前的主力选择。它的自动等待机制做得非常扎实——你写click它会自动等到元素可点击才点不需要你手动加等待。它的浏览器上下文隔离很干净每个测试用例跑在独立的 context 里cookie 和 localStorage 不会互相污染。它还内置了网络拦截、文件下载、多标签页支持这些在 e2e 场景里都是刚需。最关键的是它的 trace viewer 在排查失败用例时非常好用每一步操作都有截图和 DOM 快照定位问题效率极高。当然如果你的团队已经在 Cypress 上投入了大量用例迁移成本很高那继续用 Cypress 也没问题。工具是手段不是目的。2.3 “e2e profile1”背后的配置哲学回到热词“e2e profile1”。我理解它代表的是“一套预设好的端到端测试配置”。为什么需要 profile因为 e2e 测试的配置项太多了而且很多配置之间有关联。比如你设置了全局超时 30 秒但某个用例里又设置了元素等待 60 秒那到底以哪个为准再比如你开了并行执行但测试数据没有做隔离两个用例同时操作同一条数据结果互相干扰。一个成熟的 profile 应该包含以下几类配置执行环境配置浏览器类型、视口大小、是否无头模式、是否开启视频录制。超时与重试配置全局超时、断言超时、操作超时、失败重试次数。并行与分片配置worker 数量、分片策略、数据隔离方案。报告与追踪配置报告格式、截图策略、trace 采集策略。网络与认证配置base URL、代理设置、认证状态复用。我自己的 profile1 方案是这样的无头模式跑 CI有头模式跑本地调试全局超时 30 秒断言超时 5 秒失败重试 2 次worker 数量设为 CPU 核心数的一半每个 worker 使用独立的测试账号失败时自动截图并保留 trace认证状态通过 storageState 复用避免每个用例都走一遍登录流程。这套配置不是拍脑袋定的每一条都有背后的考量。比如 worker 数量为什么是 CPU 核心数的一半因为 e2e 测试是 IO 密集型任务浏览器渲染和网络请求占大头CPU 并不是瓶颈。开太多 worker 反而会因为资源竞争导致用例不稳定。再比如失败重试为什么是 2 次而不是 3 次因为重试次数太多会掩盖真正的问题而且 CI 时间会拉长。2 次是一个平衡点既能过滤掉偶发的网络抖动又不会让真正的 bug 被反复重试掩盖。3. 核心细节解析与实操要点3.1 用例设计从“用户故事”到“可执行脚本”的转化写 e2e 用例最怕的是什么是写成一堆步骤的流水账。我见过一个用例写了 200 多行从打开首页一直点到订单详情中间穿插了十几个断言。这种用例一旦失败你根本不知道是哪一步出了问题。我的做法是一个用例只验证一个用户故事。比如“用户可以成功登录”是一个用例“用户可以搜索商品”是另一个用例“用户可以将商品加入购物车”又是另一个。每个用例独立运行不依赖前一个用例的状态。这样做的好处是失败时定位精准而且可以并行执行。具体到代码层面我会把用例拆成三层Page Object 层、Flow 层、Test 层。Page Object 层封装页面元素和基本操作比如loginPage.usernameInput、loginPage.clickSubmit()。Flow 层封装业务流程比如loginFlow.loginAs(user)。Test 层只写断言和用例逻辑。这样分层之后页面改版只需要改 Page Object 层业务流程调整只需要改 Flow 层用例本身非常稳定。3.2 选择器策略为什么我优先用 role 和 text而不是 CSS 类名选择器是 e2e 测试的基石。选错了选择器用例就会变得极其脆弱。我早期喜欢用 CSS 类名比如.btn-primary、.form-control。后来发现前端一改样式类名就变了用例全挂。再后来用 XPath写起来复杂可读性差而且性能不好。现在我优先用 Playwright 推荐的 role 选择器比如page.getByRole(button, { name: 登录 })。这种选择器基于无障碍属性语义清晰而且前端改样式通常不会影响 role。其次是 text 选择器比如page.getByText(欢迎回来)。最后才考虑 test-id也就是专门为测试加的属性比如>mkdir e2e-project cd e2e-project npm init -y npm install -D playwright/test npx playwright installnpx playwright install会下载 Chromium、Firefox、WebKit 三个浏览器。如果你只需要跑 Chromium可以加--with-deps chromium只装一个节省时间。接下来创建配置文件playwright.config.tsimport { defineConfig, devices } from playwright/test; export default defineConfig({ testDir: ./tests, timeout: 30000, expect: { timeout: 5000 }, retries: 2, workers: 50%, reporter: [[html], [list]], use: { baseURL: http://localhost:3000, headless: true, viewport: { width: 1280, height: 720 }, screenshot: only-on-failure, trace: retain-on-failure, video: retain-on-failure, }, projects: [ { name: chromium, use: { ...devices[Desktop Chrome] }, }, ], });这份配置里timeout: 30000是单个用例的全局超时expect.timeout: 5000是断言的超时。retries: 2表示失败后重试两次。workers: 50%表示使用一半的 CPU 核心数作为并行 worker 数量。trace: retain-on-failure表示只在失败时保留 trace 文件节省磁盘空间。4.2 第一个用例登录流程的完整实现我以登录流程为例展示一个完整的 e2e 用例怎么写。首先创建 Page Object// pages/LoginPage.ts import { Page, Locator } from playwright/test; export class LoginPage { readonly page: Page; readonly usernameInput: Locator; readonly passwordInput: Locator; readonly submitButton: Locator; readonly errorMessage: Locator; constructor(page: Page) { this.page page; this.usernameInput page.getByTestId(username-input); this.passwordInput page.getByTestId(password-input); this.submitButton page.getByRole(button, { name: 登录 }); this.errorMessage page.getByTestId(error-message); } async goto() { await this.page.goto(/login); } async login(username: string, password: string) { await this.usernameInput.fill(username); await this.passwordInput.fill(password); await this.submitButton.click(); } }然后写测试用例// tests/login.spec.ts import { test, expect } from playwright/test; import { LoginPage } from ../pages/LoginPage; test.describe(登录功能, () { test(用户使用正确凭证可以成功登录, async ({ page }) { const loginPage new LoginPage(page); await loginPage.goto(); await loginPage.login(testuser, correct-password); await expect(page).toHaveURL(/dashboard); await expect(page.getByText(欢迎回来)).toBeVisible(); }); test(用户使用错误密码会看到错误提示, async ({ page }) { const loginPage new LoginPage(page); await loginPage.goto(); await loginPage.login(testuser, wrong-password); await expect(loginPage.errorMessage).toHaveText(用户名或密码错误); }); });这个用例里我没有写任何sleep也没有写任何显式等待。fill和click自带自动等待toHaveURL和toBeVisible自带重试机制。整个用例读起来就像在描述用户行为非常直观。4.3 认证状态复用让每个用例跳过登录步骤如果每个用例都走一遍登录流程测试时间会很长。Playwright 提供了 storageState 机制可以把登录后的 cookie 和 localStorage 保存下来后续用例直接复用。首先创建一个 setup 项目// tests/auth.setup.ts import { test as setup } from playwright/test; const authFile playwright/.auth/user.json; setup(authenticate, async ({ page }) { await page.goto(/login); await page.getByTestId(username-input).fill(testuser); await page.getByTestId(password-input).fill(correct-password); await page.getByRole(button, { name: 登录 }).click(); await page.waitForURL(/dashboard); await page.context().storageState({ path: authFile }); });然后在配置文件里加一个依赖projects: [ { name: setup, testMatch: /auth\.setup\.ts/ }, { name: chromium, use: { ...devices[Desktop Chrome], storageState: playwright/.auth/user.json, }, dependencies: [setup], }, ],这样配置之后所有 chromium 项目下的用例都会自动带上登录状态不需要再走登录流程。实测下来一个包含 50 个用例的测试套件认证复用能节省 30% 以上的执行时间。4.4 并行执行与分片如何把测试时间从 20 分钟压到 5 分钟当用例数量上去之后串行执行的时间会变得不可接受。我的做法是开启并行执行并且根据 CI 环境做分片。并行执行只需要在配置里设置workers数量。但要注意并行执行的前提是用例之间没有数据依赖。如果你的用例共享了测试数据并行就会出问题。所以我在 3.4 节里强调的“每个用例创建自己的数据”是并行执行的前提。分片是指把用例分成多个组在不同的 CI 机器上同时跑。Playwright 支持--shard参数npx playwright test --shard1/3 npx playwright test --shard2/3 npx playwright test --shard3/3这三条命令可以同时在三个 CI job 里执行每个 job 只跑三分之一用例。最后把报告合并即可。我实测过一个 200 用例的套件单机串行需要 20 分钟分成 4 个 shard 并行跑总时间压到了 5 分钟左右。5. 常见问题与排查技巧实录5.1 用例不稳定Flaky Test的根因分析与解决Flaky test 是 e2e 测试的头号敌人。同一个用例跑十次挂三次你都不知道该不该信它。我排查过大量 flaky 用例根因基本集中在以下几类问题类型典型表现排查方法解决方案等待不足偶发元素找不到看 trace 里失败时刻的截图用自动等待或断言重试替代 sleep数据竞争并行时偶发失败单独跑通过并行跑失败每个用例隔离测试数据网络抖动偶发超时看网络请求耗时增加重试次数优化后端性能动画干扰点击无效看元素是否在动画中禁用动画或等待动画结束视口差异本地通过 CI 失败对比本地和 CI 的视口大小统一视口配置我的经验是遇到 flaky 用例第一件事是看 trace。Playwright 的 trace viewer 会记录每一步操作的截图和 DOM 快照你能清楚地看到失败那一刻页面长什么样。大部分时候看一眼截图就知道问题在哪了。5.2 选择器失效的三种场景与应对策略选择器失效是另一个高频问题。我总结下来主要有三种场景第一种是前端改了类名或结构。这种最常見解决方案就是前面说的优先用 role 和 text关键元素加> 
长河君 · 2026/10/27 6:13:51 · 阅读 1.2k 端到端测试实战：从e2e profile1配置到Playwright稳定用例设计
1. 从“e2e”说起端到端测试到底在测什么第一次看到“e2e”这个词很多人会愣一下——它其实是 end-to-end 的缩写中文叫“端到端”。在软件研发语境里e2e 测试指的是从用户真实使用路径出发把整个系统当作一个黑盒验证从入口到出口的完整链路是否走得通。它不关心某个函数写得漂不漂亮也不关心某个接口返回的字段是不是符合预期它只关心一件事用户点下去结果对不对。我做了十多年一线研发和测试见过太多团队在单元测试上覆盖率刷到 90%结果一上线用户连登录都登不进去。问题出在哪单元测试测的是零件e2e 测的是整车。零件都好装在一起未必能跑。e2e 的价值就在于它把“整车能不能上路”这件事用自动化手段反复验证。最近“e2e profile1”这个词在技术社区里被频繁提及我理解它指的是一套端到端测试的配置档案或者说预设方案——类似你打开一个测试框架它给你一个开箱即用的 profile里面预置了浏览器驱动、超时策略、重试机制、报告格式等一整套参数。这个思路很实用因为 e2e 测试最让人头疼的往往不是写用例而是环境配置和稳定性调优。一个成熟的 profile 能帮你省掉大量踩坑时间。这篇文章适合谁看如果你是刚接触 e2e 测试的开发者想搞清楚它和单元测试、集成测试的边界在哪如果你是团队里负责搭建测试体系的人正在纠结选什么工具、怎么配参数或者你已经被 flaky test不稳定用例折磨得够呛想找一套可复现的稳定方案——那接下来的内容应该对你有用。我会从设计思路、核心细节、实操过程、问题排查四个维度把 e2e 测试这件事拆开揉碎讲清楚所有参数和步骤都尽量给到可直接抄作业的程度。2. e2e 测试体系的设计思路与方案选型2.1 为什么 e2e 不能替代单元测试但也绝不能被替代很多团队在资源紧张的时候会做一个取舍要么只写单元测试要么只写 e2e 测试。这两种做法我都试过结论是都不对。单元测试和 e2e 测试的关系更像是“体检”和“试驾”。体检能查出你血脂高不高、心率齐不齐但没法告诉你这辆车开起来方向盘会不会跑偏。试驾能告诉你整车感受但没法定位到是哪个螺丝松了。e2e 测试的核心设计原则是“用户视角”。这意味着你在写用例的时候不能想着“我先调这个接口再调那个接口”而要想“用户打开页面看到什么点了什么期待什么”。这个视角的切换说起来简单做起来难。我见过不少团队写的 e2e 用例本质上是一堆接口调用的堆砌只是套了个浏览器的壳。这种用例跑起来很快但一旦失败排查成本极高因为它跳过了 UI 层你根本不知道是前端渲染错了还是后端数据错了。所以我的设计思路是e2e 用例必须经过真实的 UI 交互。该点击的点击该输入的输入该等待的等待。只有这样它才能覆盖到那些单元测试永远覆盖不到的问题——比如某个按钮在特定分辨率下被遮挡了比如某个异步加载的数据在慢网络下没渲染出来比如两个组件之间的状态传递出了偏差。2.2 工具选型为什么我最终选了 Playwright 而不是 Selenium工具选型这件事没有绝对的好坏只有适不适合。我早期用的是 Selenium后来试过 Cypress再后来转到 Playwright。说一下我的决策逻辑。Selenium 的优势是生态老、语言绑定多、社区大。但它的痛点也很明显等待机制原始需要手动写大量sleep或WebDriverWait浏览器驱动版本管理麻烦Chrome 一升级驱动就得跟着换多标签页和 iframe 的处理写起来很啰嗦。Cypress 的开发者体验很好自带时间旅行调试但它的架构决定了它很难做多标签页测试而且跨域场景支持有限。Playwright 是我目前的主力选择。它的自动等待机制做得非常扎实——你写click它会自动等到元素可点击才点不需要你手动加等待。它的浏览器上下文隔离很干净每个测试用例跑在独立的 context 里cookie 和 localStorage 不会互相污染。它还内置了网络拦截、文件下载、多标签页支持这些在 e2e 场景里都是刚需。最关键的是它的 trace viewer 在排查失败用例时非常好用每一步操作都有截图和 DOM 快照定位问题效率极高。当然如果你的团队已经在 Cypress 上投入了大量用例迁移成本很高那继续用 Cypress 也没问题。工具是手段不是目的。2.3 “e2e profile1”背后的配置哲学回到热词“e2e profile1”。我理解它代表的是“一套预设好的端到端测试配置”。为什么需要 profile因为 e2e 测试的配置项太多了而且很多配置之间有关联。比如你设置了全局超时 30 秒但某个用例里又设置了元素等待 60 秒那到底以哪个为准再比如你开了并行执行但测试数据没有做隔离两个用例同时操作同一条数据结果互相干扰。一个成熟的 profile 应该包含以下几类配置执行环境配置浏览器类型、视口大小、是否无头模式、是否开启视频录制。超时与重试配置全局超时、断言超时、操作超时、失败重试次数。并行与分片配置worker 数量、分片策略、数据隔离方案。报告与追踪配置报告格式、截图策略、trace 采集策略。网络与认证配置base URL、代理设置、认证状态复用。我自己的 profile1 方案是这样的无头模式跑 CI有头模式跑本地调试全局超时 30 秒断言超时 5 秒失败重试 2 次worker 数量设为 CPU 核心数的一半每个 worker 使用独立的测试账号失败时自动截图并保留 trace认证状态通过 storageState 复用避免每个用例都走一遍登录流程。这套配置不是拍脑袋定的每一条都有背后的考量。比如 worker 数量为什么是 CPU 核心数的一半因为 e2e 测试是 IO 密集型任务浏览器渲染和网络请求占大头CPU 并不是瓶颈。开太多 worker 反而会因为资源竞争导致用例不稳定。再比如失败重试为什么是 2 次而不是 3 次因为重试次数太多会掩盖真正的问题而且 CI 时间会拉长。2 次是一个平衡点既能过滤掉偶发的网络抖动又不会让真正的 bug 被反复重试掩盖。3. 核心细节解析与实操要点3.1 用例设计从“用户故事”到“可执行脚本”的转化写 e2e 用例最怕的是什么是写成一堆步骤的流水账。我见过一个用例写了 200 多行从打开首页一直点到订单详情中间穿插了十几个断言。这种用例一旦失败你根本不知道是哪一步出了问题。我的做法是一个用例只验证一个用户故事。比如“用户可以成功登录”是一个用例“用户可以搜索商品”是另一个用例“用户可以将商品加入购物车”又是另一个。每个用例独立运行不依赖前一个用例的状态。这样做的好处是失败时定位精准而且可以并行执行。具体到代码层面我会把用例拆成三层Page Object 层、Flow 层、Test 层。Page Object 层封装页面元素和基本操作比如loginPage.usernameInput、loginPage.clickSubmit()。Flow 层封装业务流程比如loginFlow.loginAs(user)。Test 层只写断言和用例逻辑。这样分层之后页面改版只需要改 Page Object 层业务流程调整只需要改 Flow 层用例本身非常稳定。3.2 选择器策略为什么我优先用 role 和 text而不是 CSS 类名选择器是 e2e 测试的基石。选错了选择器用例就会变得极其脆弱。我早期喜欢用 CSS 类名比如.btn-primary、.form-control。后来发现前端一改样式类名就变了用例全挂。再后来用 XPath写起来复杂可读性差而且性能不好。现在我优先用 Playwright 推荐的 role 选择器比如page.getByRole(button, { name: 登录 })。这种选择器基于无障碍属性语义清晰而且前端改样式通常不会影响 role。其次是 text 选择器比如page.getByText(欢迎回来)。最后才考虑 test-id也就是专门为测试加的属性比如>mkdir e2e-project cd e2e-project npm init -y npm install -D playwright/test npx playwright installnpx playwright install会下载 Chromium、Firefox、WebKit 三个浏览器。如果你只需要跑 Chromium可以加--with-deps chromium只装一个节省时间。接下来创建配置文件playwright.config.tsimport { defineConfig, devices } from playwright/test; export default defineConfig({ testDir: ./tests, timeout: 30000, expect: { timeout: 5000 }, retries: 2, workers: 50%, reporter: [[html], [list]], use: { baseURL: http://localhost:3000, headless: true, viewport: { width: 1280, height: 720 }, screenshot: only-on-failure, trace: retain-on-failure, video: retain-on-failure, }, projects: [ { name: chromium, use: { ...devices[Desktop Chrome] }, }, ], });这份配置里timeout: 30000是单个用例的全局超时expect.timeout: 5000是断言的超时。retries: 2表示失败后重试两次。workers: 50%表示使用一半的 CPU 核心数作为并行 worker 数量。trace: retain-on-failure表示只在失败时保留 trace 文件节省磁盘空间。4.2 第一个用例登录流程的完整实现我以登录流程为例展示一个完整的 e2e 用例怎么写。首先创建 Page Object// pages/LoginPage.ts import { Page, Locator } from playwright/test; export class LoginPage { readonly page: Page; readonly usernameInput: Locator; readonly passwordInput: Locator; readonly submitButton: Locator; readonly errorMessage: Locator; constructor(page: Page) { this.page page; this.usernameInput page.getByTestId(username-input); this.passwordInput page.getByTestId(password-input); this.submitButton page.getByRole(button, { name: 登录 }); this.errorMessage page.getByTestId(error-message); } async goto() { await this.page.goto(/login); } async login(username: string, password: string) { await this.usernameInput.fill(username); await this.passwordInput.fill(password); await this.submitButton.click(); } }然后写测试用例// tests/login.spec.ts import { test, expect } from playwright/test; import { LoginPage } from ../pages/LoginPage; test.describe(登录功能, () { test(用户使用正确凭证可以成功登录, async ({ page }) { const loginPage new LoginPage(page); await loginPage.goto(); await loginPage.login(testuser, correct-password); await expect(page).toHaveURL(/dashboard); await expect(page.getByText(欢迎回来)).toBeVisible(); }); test(用户使用错误密码会看到错误提示, async ({ page }) { const loginPage new LoginPage(page); await loginPage.goto(); await loginPage.login(testuser, wrong-password); await expect(loginPage.errorMessage).toHaveText(用户名或密码错误); }); });这个用例里我没有写任何sleep也没有写任何显式等待。fill和click自带自动等待toHaveURL和toBeVisible自带重试机制。整个用例读起来就像在描述用户行为非常直观。4.3 认证状态复用让每个用例跳过登录步骤如果每个用例都走一遍登录流程测试时间会很长。Playwright 提供了 storageState 机制可以把登录后的 cookie 和 localStorage 保存下来后续用例直接复用。首先创建一个 setup 项目// tests/auth.setup.ts import { test as setup } from playwright/test; const authFile playwright/.auth/user.json; setup(authenticate, async ({ page }) { await page.goto(/login); await page.getByTestId(username-input).fill(testuser); await page.getByTestId(password-input).fill(correct-password); await page.getByRole(button, { name: 登录 }).click(); await page.waitForURL(/dashboard); await page.context().storageState({ path: authFile }); });然后在配置文件里加一个依赖projects: [ { name: setup, testMatch: /auth\.setup\.ts/ }, { name: chromium, use: { ...devices[Desktop Chrome], storageState: playwright/.auth/user.json, }, dependencies: [setup], }, ],这样配置之后所有 chromium 项目下的用例都会自动带上登录状态不需要再走登录流程。实测下来一个包含 50 个用例的测试套件认证复用能节省 30% 以上的执行时间。4.4 并行执行与分片如何把测试时间从 20 分钟压到 5 分钟当用例数量上去之后串行执行的时间会变得不可接受。我的做法是开启并行执行并且根据 CI 环境做分片。并行执行只需要在配置里设置workers数量。但要注意并行执行的前提是用例之间没有数据依赖。如果你的用例共享了测试数据并行就会出问题。所以我在 3.4 节里强调的“每个用例创建自己的数据”是并行执行的前提。分片是指把用例分成多个组在不同的 CI 机器上同时跑。Playwright 支持--shard参数npx playwright test --shard1/3 npx playwright test --shard2/3 npx playwright test --shard3/3这三条命令可以同时在三个 CI job 里执行每个 job 只跑三分之一用例。最后把报告合并即可。我实测过一个 200 用例的套件单机串行需要 20 分钟分成 4 个 shard 并行跑总时间压到了 5 分钟左右。5. 常见问题与排查技巧实录5.1 用例不稳定Flaky Test的根因分析与解决Flaky test 是 e2e 测试的头号敌人。同一个用例跑十次挂三次你都不知道该不该信它。我排查过大量 flaky 用例根因基本集中在以下几类问题类型典型表现排查方法解决方案等待不足偶发元素找不到看 trace 里失败时刻的截图用自动等待或断言重试替代 sleep数据竞争并行时偶发失败单独跑通过并行跑失败每个用例隔离测试数据网络抖动偶发超时看网络请求耗时增加重试次数优化后端性能动画干扰点击无效看元素是否在动画中禁用动画或等待动画结束视口差异本地通过 CI 失败对比本地和 CI 的视口大小统一视口配置我的经验是遇到 flaky 用例第一件事是看 trace。Playwright 的 trace viewer 会记录每一步操作的截图和 DOM 快照你能清楚地看到失败那一刻页面长什么样。大部分时候看一眼截图就知道问题在哪了。5.2 选择器失效的三种场景与应对策略选择器失效是另一个高频问题。我总结下来主要有三种场景第一种是前端改了类名或结构。这种最常見解决方案就是前面说的优先用 role 和 text关键元素加>