e2e测试实战：从profile1配置到Playwright核心用例设计

1. 从“e2e”这个标题说起：它到底指什么

第一次看到“e2e”这个标题，很多人会愣一下。三个字母加一个数字，既不像一个完整的产品名，也不像一句能直接读懂的话。但如果你在软件测试、自动化工程或者质量保障这条线上待过一段时间，就会立刻反应过来——这是“end to end”的缩写，也就是端到端。而后面跟着的“profile1”，则大概率是某个测试配置文件的命名，或者某个测试套件的标识符。

我先把话说直白一点：e2e 测试，就是从用户真实使用路径的起点，一路验证到终点的自动化测试方式。它不关心某个函数内部怎么实现，也不关心某个接口返回的字段是不是符合预期，它只关心一件事——用户从打开页面、点击按钮、填写表单、提交数据，到最后看到结果，这一整条链路是不是通的、是不是对的。

那“profile1”又是什么？在实际工程里，e2e 测试通常不会只有一套配置。你可能需要针对不同环境跑不同的用例，比如本地开发环境、集成测试环境、预发布环境；也可能需要针对不同浏览器、不同设备、不同用户角色来分别执行。这时候，工程上就会用“profile”来区分这些配置组合。profile1 往往就是默认的那一套，或者是最先被定义出来的那一套。

这个标题背后真正要解决的问题，其实非常具体：当你的系统越来越复杂，模块越来越多，依赖越来越深的时候，怎么保证用户走完一整条路不会掉进坑里。单元测试能保证每个零件是好的，集成测试能保证零件之间接上了，但只有 e2e 测试能告诉你，用户真正走一遍会不会摔跤。

适合看这篇内容的人，我大致分三类。第一类是刚接触自动化测试的工程师，你可能写过一些单元测试，但对 e2e 还停留在“听说过”的阶段。第二类是已经有一堆 e2e 用例但跑得不太顺的团队，用例经常挂、排查成本高、维护起来很痛苦。第三类是对质量保障体系有整体规划需求的技术负责人，你需要知道 e2e 在整个测试金字塔里应该占什么位置、投多少资源、怎么和 CI/CD 串起来。

接下来我会围绕 e2e 测试的核心设计思路、关键细节、实操过程以及常见问题排查，把我自己踩过的坑和总结出来的经验完整展开。profile1 这个配置标识，我也会在实操部分具体说明它通常怎么组织、怎么切换、怎么避免配置混乱。

2. e2e 测试的整体设计与思路拆解

2.1 为什么单元测试和集成测试不够用

很多人一开始会觉得，我把单元测试覆盖率做到百分之八九十，集成测试也写了不少，应该够了吧。但实际项目里你会发现一个很尴尬的现象：单元测试全绿，集成测试也全绿，可用户一用就出问题。

原因不复杂。单元测试验证的是函数级别的逻辑，它把外部依赖全部 mock 掉了。集成测试验证的是模块之间的接口，它通常也只关注数据能不能传过去、格式对不对。但用户真实操作的时候，面对的是浏览器渲染、网络延迟、异步加载、第三方服务响应、权限校验、页面跳转、状态保持这一整套东西。任何一个环节出问题，用户看到的就是白屏、报错、按钮点不动、数据没保存。

我举个实际例子。之前有个项目，单元测试里计算逻辑完全正确，集成测试里接口返回也完全正确，但用户提交表单后就是看不到成功提示。查了半天发现，是前端在接口返回后需要先关闭弹窗、再刷新列表、再弹出提示，而关闭弹窗的动画还没结束就触发了刷新，导致提示被覆盖了。这种问题，单元测试和集成测试根本覆盖不到，只有 e2e 测试能抓住。

所以 e2e 测试的核心价值，不是替代单元测试和集成测试，而是补上“真实用户路径”这一层验证。它站在用户的角度，把整个系统当成一个黑盒，只关心输入和输出。

2.2 测试金字塔里 e2e 应该占多少

测试金字塔这个概念很多人都听过：底层是大量单元测试，中间是适量集成测试，顶层是少量 e2e 测试。但“少量”到底是多少，很多人没有概念。

我的经验是，e2e 测试的用例数量应该控制在总用例数的百分之五到百分之十之间。一个中等规模的系统，单元测试可能几千个，集成测试几百个，e2e 测试几十个到一百多个就差不多了。为什么不能多？因为 e2e 测试的运行成本太高了。它要启动浏览器、要连真实数据库、要等网络请求、要处理异步时序，跑一轮下来可能十几分钟甚至半小时。如果你有几百个 e2e 用例，每次提交代码都要跑一遍，开发效率会被拖垮。

那这百分之五到百分之十的 e2e 用例应该覆盖什么？我的原则是只覆盖核心业务路径和关键用户场景。比如电商系统里，下单支付这条链路必须有 e2e 测试；用户注册登录这条链路必须有；搜索商品并查看详情这条链路必须有。但像“修改头像后裁剪图片”这种边缘功能，就不一定需要 e2e 覆盖，用集成测试或者手动测试就够了。

profile1 这个配置，通常就是用来定义“默认跑哪些 e2e 用例”的。你可以把最核心的那几十个用例放在 profile1 里，每次 CI 都跑；把更全面的用例放在 profile2 或 profile3 里，每天定时跑一次或者发版前跑一次。这样既保证了核心路径的持续验证，又不会让日常开发被拖慢。

2.3 工具选型：为什么我最终选了 Playwright

e2e 测试的工具这些年变化挺大的。早期大家用 Selenium，后来 Puppeteer 火了一阵，再后来 Cypress 成了很多前端团队的首选。我自己这几个工具都用过，最后在新项目里稳定用 Playwright，原因有几个。

第一是自动等待机制。e2e 测试最头疼的问题之一就是“元素还没出现就去点它”。Selenium 需要你手动写 wait，Cypress 有重试机制但有时候重试逻辑不够透明。Playwright 的内置等待是我用过最顺手的，它会自动等待元素可操作、可点击、可见，大部分场景下你不需要写额外的等待代码。

第二是多浏览器支持。Playwright 原生支持 Chromium、Firefox 和 WebKit，而且 API 是一致的。你写一套用例，可以配置在不同浏览器上跑。profile1 里我可以指定只跑 Chromium，profile2 里跑全部三个浏览器，切换起来很方便。

第三是调试体验。Playwright 有 trace viewer，可以把整个测试过程录下来，每一步的 DOM 快照、网络请求、控制台日志都能回看。排查失败用例的时候，这个功能能省掉大量时间。

当然，Cypress 的开发者体验也很好，尤其是它的时间旅行调试。但 Cypress 在多标签页、多域名场景下限制比较多，而 Playwright 在这方面更灵活。如果你的项目涉及跨域跳转或者多窗口操作，Playwright 会更省心。

2.4 profile1 的配置设计思路

profile1 不是一个固定的标准，它完全取决于你的项目怎么组织。但我在多个项目里总结出一套比较通用的配置结构，你可以参考。

通常我会在项目根目录下建一个e2e文件夹，里面放几个东西：playwright.config.ts是主配置文件，profiles文件夹里放不同 profile 的覆盖配置，tests文件夹里放用例，fixtures文件夹里放测试数据和工具函数。

profile1 的配置一般包含这些内容：指定测试目录、指定浏览器类型、设置超时时间、配置重试次数、指定报告格式、配置 baseURL。如果是 CI 环境，还会配置并行执行的 worker 数量。

我习惯把 profile1 定义为“本地开发快速验证”用的配置。它的特点是：只跑 Chromium、只跑核心用例、超时时间设短一点、失败不重试、报告直接输出到控制台。这样开发人员在本地改完代码，跑一下 profile1，几十秒就能知道核心路径有没有被破坏。

而 CI 环境用的可能是 profile2，它会跑全部用例、跑多个浏览器、失败重试两次、生成 HTML 报告并上传。发版前用的可能是 profile3，它会在 profile2 的基础上加上性能指标采集和截图对比。

这种分层的配置方式，能让 e2e 测试在不同场景下发挥不同作用，而不是一套配置打天下。

3. 核心细节解析与实操要点

3.1 用例设计：怎么写出不容易挂的 e2e 测试

e2e 测试最让人崩溃的就是“昨天还跑得好好的，今天突然挂了”。很多时候不是代码有问题，而是用例本身写得太脆弱。我总结了几条原则，能大幅降低用例的维护成本。

第一条原则：用面向用户的定位器，不用面向实现的定位器。什么意思？比如你要点击一个登录按钮，不要用div > div:nth-child(3) > button这种基于 DOM 结构的定位器，也不要用.btn-primary这种基于样式的定位器。你应该用getByRole('button', { name: '登录' })或者getByText('登录')这种基于用户可见内容的定位器。这样即使前端重构了 DOM 结构、改了样式类名，只要按钮上的文字没变，用例就不会挂。

第二条原则：每个用例独立准备数据，不依赖其他用例的执行结果。我见过很多团队为了省事，让用例 A 创建数据，用例 B 使用数据，用例 C 删除数据。这种链式依赖一旦中间某个环节失败，后面全挂，而且排查起来非常痛苦。正确的做法是每个用例自己创建需要的数据，跑完之后自己清理。虽然会多花一点时间，但稳定性提升是值得的。

第三条原则：不要在用例里写死等待时间。sleep(3000)这种写法是 e2e 测试的毒药。网络快的时候浪费三秒，网络慢的时候三秒不够还是挂。应该用工具提供的等待机制，比如 Playwright 的waitForSelector、waitForResponse，或者直接依赖它的自动等待。

第四条原则：一个用例只验证一个核心场景。不要把十个步骤塞进一个用例里。步骤越多，失败的概率越大，排查的时候也越难定位是哪一步出的问题。拆成多个小用例，每个用例只走一条关键路径，跑起来清晰，维护起来也轻松。

3.2 测试数据管理：profile1 里怎么隔离数据

e2e 测试的数据管理是个大坑。如果你用真实数据库，测试数据和生产数据混在一起，轻则查询结果被污染，重则误删真实数据。如果你用 mock 数据，又失去了 e2e 测试的意义。

我的做法是：为 e2e 测试单独准备一套数据库或 schema，每次跑测试前重置。具体来说，在 profile1 的配置里，我会设置一个globalSetup脚本，它在所有测试开始前执行，负责清空测试库、插入基础数据、生成测试账号。然后每个用例内部再按需创建自己需要的数据。

如果项目用的是容器化部署，那就更简单了。每次跑 e2e 测试时启动一个独立的数据库容器，跑完就销毁。这样数据完全隔离，不会影响任何其他环境。

对于 profile1 这种本地快速验证的配置，我通常会用内存数据库或者 SQLite 来加速。因为本地开发时你不太关心数据库的兼容性，只关心逻辑通不通。而 CI 环境的 profile2 会切换到和线上一致的数据库类型，确保环境差异不会导致测试结果不一致。

还有一个细节：测试账号的权限要控制好。e2e 测试用的账号不要给管理员权限，除非你专门在测管理员功能。普通用户账号能覆盖大部分场景，而且更安全。如果确实需要测管理员功能，单独建一个管理员测试账号，并且限制它只能在测试环境使用。

3.3 选择器策略：让用例在 UI 改版后还能跑

选择器是 e2e 测试里最常出问题的地方。前端改个样式、调个布局，选择器就失效了。我见过一个团队，每次前端发版后都要花半天时间修 e2e 用例的选择器，效率极低。

解决这个问题的根本办法是：和前端团队约定一套测试专用的属性。比如在需要被 e2e 测试操作的元素上，加上>// e2e/profiles/profile1.config.ts import { defineConfig } from '@playwright/test'; import baseConfig from '../playwright.config'; export default defineConfig({ ...baseConfig, testDir: '../tests/core', timeout: 30000, retries: 0, workers: 2, use: { ...baseConfig.use, browserName: 'chromium', headless: true, baseURL: 'http://localhost:3000', trace: 'retain-on-failure', }, reporter: [['list']], });

这个配置的含义是：只跑tests/core目录下的核心用例，超时 30 秒，失败不重试，用两个并行 worker，只跑 Chromium，无头模式，失败时保留 trace 文件，报告直接输出到控制台。

第四步，在package.json里加脚本：

{ "scripts": { "e2e:profile1": "playwright test --config=e2e/profiles/profile1.config.ts", "e2e:profile2": "playwright test --config=e2e/profiles/profile2.config.ts", "e2e:profile3": "playwright test --config=e2e/profiles/profile3.config.ts" } }

这样开发人员在本地只需要跑npm run e2e:profile1，就能快速验证核心路径。

4.2 编写第一个核心用例：登录流程

登录是几乎所有系统都有的功能，也是 e2e 测试最典型的入门用例。我以登录为例，展示一个完整的用例怎么写。

// e2e/tests/core/login.spec.ts import { test, expect } from '@playwright/test'; test.describe('登录流程', () => { test.beforeEach(async ({ page }) => { await page.goto('/login'); }); test('使用正确的用户名和密码可以登录成功', async ({ page }) => { await page.getByLabel('用户名').fill('testuser'); await page.getByLabel('密码').fill('Test@123456'); await page.getByRole('button', { name: '登录' }).click(); await expect(page).toHaveURL('/dashboard'); await expect(page.getByText('欢迎回来')).toBeVisible(); }); test('使用错误的密码会提示错误信息', async ({ page }) => { await page.getByLabel('用户名').fill('testuser'); await page.getByLabel('密码').fill('wrongpassword'); await page.getByRole('button', { name: '登录' }).click(); await expect(page.getByText('用户名或密码错误')).toBeVisible(); await expect(page).toHaveURL('/login'); }); test('用户名为空时登录按钮不可用或提示必填', async ({ page }) => { await page.getByLabel('密码').fill('Test@123456'); await page.getByRole('button', { name: '登录' }).click(); await expect(page.getByText('请输入用户名')).toBeVisible(); }); });

这个用例里有几个细节值得说。第一，我用了getByLabel来定位输入框，这要求前端表单的 label 和 input 正确关联。如果前端没做关联，可以用getByPlaceholder或者getByTestId替代。第二，我用了toHaveURL来验证跳转，这比检查页面上有没有某个元素更可靠。第三，错误提示的断言用了toBeVisible，确保提示真的展示出来了，而不是仅仅存在于 DOM 里但被隐藏了。

4.3 处理异步和网络请求：等待策略详解

e2e 测试里最复杂的部分就是处理异步。页面加载、接口请求、动画过渡、数据渲染，这些都是异步的。如果等待策略不对，用例就会时好时坏。

Playwright 的自动等待能覆盖大部分场景，但有些情况还是需要手动处理。我举几个典型场景。

场景一：点击按钮后触发了一个接口请求，需要等请求完成后再断言。这时候可以用waitForResponse：

const responsePromise = page.waitForResponse( (response) => response.url().includes('/api/orders') && response.status() === 200 ); await page.getByRole('button', { name: '提交订单' }).click(); await responsePromise; await expect(page.getByText('订单提交成功')).toBeVisible();

注意这里先创建responsePromise，再执行点击，顺序不能反。如果先点击再等待，可能请求已经完成了，你就等不到了。

场景二：页面有多个异步加载的模块，需要等所有模块都加载完。可以用waitForLoadState：

await page.waitForLoadState('networkidle');

但networkidle不是万能的，如果页面有轮询请求或者 WebSocket 长连接，networkidle可能永远等不到。这时候应该用更具体的等待条件，比如等待某个关键元素出现。

场景三：元素存在但不可点击，比如被遮罩层挡住了。Playwright 的click会自动等待元素可点击，但如果遮罩层一直不消失，就会超时。这时候需要先处理遮罩层：

await page.getByRole('button', { name: '关闭弹窗' }).click(); await page.getByRole('button', { name: '提交' }).click();

如果遮罩层是自动消失的，可以用waitForSelector等它消失：

await page.waitForSelector('.loading-mask', { state: 'hidden' });

4.4 并行执行与重试：profile1 和 profile2 的差异

profile1 我通常设置workers: 2，retries: 0。因为本地开发时，你希望快速得到反馈，失败了就去看问题，不需要重试。而且本地机器资源有限，开太多 worker 反而会互相干扰。

profile2 用于 CI 环境，我会设置workers: 4或更高（取决于 CI 机器的配置），retries: 2。CI 环境通常比本地稳定，但偶尔也会有网络抖动或者资源竞争导致的偶发失败。重试两次能过滤掉大部分偶发问题，同时如果重试后还是失败，那就说明确实有 bug。

但重试有个副作用：它会让测试运行时间变长。如果一个用例本来跑 10 秒，失败后重试两次，就变成了 30 秒。所以重试次数不能设太多，两次足够了。而且我建议在报告里明确标记哪些用例是重试后才通过的，这样你能知道哪些用例不稳定，后续去优化它们。

并行执行也有坑。如果多个用例同时操作同一份数据，就会互相干扰。比如两个用例同时创建订单，订单号可能冲突。解决办法是每个用例用独立的数据，比如用时间戳或者随机字符串作为订单号的一部分。或者用test.describe.serial让同一组用例串行执行，但这样会降低速度，只适合确实有依赖关系的用例。

4.5 集成到 CI/CD：让 e2e 测试自动跑起来

e2e 测试如果不集成到 CI/CD 里，很容易被遗忘。我的做法是在代码提交和合并请求这两个环节都加上 e2e 测试。

提交环节跑 profile1，只跑核心用例，快速反馈。如果核心路径被破坏了，开发者立刻就能知道。合并请求环节跑 profile2，跑全部用例，确保没有遗漏。发版前跑 profile3，加上视觉对比和性能检查。

在 GitHub Actions 里，配置大概是这样：

name: E2E Tests on: push: branches: [main, develop] pull_request: branches: [main] jobs: e2e-profile1: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - uses: actions/setup-node@v4 with: node-version: 20 - run: npm ci - run: npx playwright install --with-deps chromium - run: npm run e2e:profile1 - uses: actions/upload-artifact@v4 if: failure() with: name: playwright-trace path: test-results/

几个关键点：npx playwright install --with-deps chromium只安装 Chromium，比安装全部浏览器快很多。if: failure()确保只在失败时上传 trace，节省存储空间。test-results目录里会有失败用例的截图、视频和 trace 文件，排查问题时非常有用。

如果 CI 环境访问不了测试环境，可以用webServer配置让 Playwright 自动启动本地服务：

webServer: { command: 'npm run start:test', port: 3000, reuseExistingServer: !process.env.CI, timeout: 120000, },

这样 Playwright 会先启动服务，等端口就绪后再跑测试，跑完自动关闭服务。

5. 常见问题与排查技巧实录

5.1 用例不稳定：偶发失败怎么查

e2e 测试最让人头疼的就是偶发失败。同一个用例，跑十次可能挂一次，而且每次挂的地方还不一样。这种问题排查起来非常耗时，但也不是没有章法。

第一步，收集足够的现场信息。Playwright 的 trace 功能是排查偶发失败的神器。在配置里设置trace: 'retain-on-failure'，失败时会把整个测试过程录下来。你用npx playwright show-trace test-results/xxx/trace.zip打开，可以看到每一步的 DOM 快照、网络请求、控制台日志。很多时候你一看 trace 就明白问题出在哪了。

第二步，检查等待逻辑。偶发失败十有八九是等待不够。比如点击按钮后，接口还没返回就去断言成功提示，网络快的时候能过，网络慢的时候就挂。解决办法是用waitForResponse或者waitForSelector替代固定等待。

第三步，检查数据隔离。如果多个用例并行执行，可能会互相干扰。比如两个用例同时用同一个账号登录，后登录的会把先登录的踢下线。解决办法是每个用例用独立账号，或者用test.describe.serial让它们串行。

第四步，检查环境差异。本地能过 CI 挂，可能是环境配置不同。比如本地用了 mock 数据，CI 连了真实数据库；本地时区是 UTC+8，CI 是 UTC。这些差异都可能导致用例行为不一致。

我整理了一个常见偶发失败的原因速查表：

5.2 选择器失效：UI 改版后怎么快速修复

UI 改版导致选择器失效，是 e2e 测试维护成本的主要来源。要减少这种痛苦，核心是和前端团队建立约定。

我在团队里推行的做法是：所有需要被 e2e 测试操作的元素，必须加>export const selectors = { login: { usernameInput: 'username-input', passwordInput: 'password-input', submitButton: 'login-submit', errorMessage: 'login-error', }, order: { createButton: 'order-create', submitButton: 'order-submit', successMessage: 'order-success', }, };

这样 UI 改版时，你只需要改selectors.ts一个文件，所有用例自动适配。

5.3 测试数据污染：怎么保证每次跑都是干净环境

测试数据污染是另一个常见问题。跑了几轮测试后，数据库里堆了一堆测试数据，查询结果被污染，用例开始随机失败。

我的解决方案是每次跑测试前重置测试数据库。在globalSetup里执行数据库清理和基础数据插入：

// e2e/global-setup.ts import { execSync } from 'child_process'; async function globalSetup() { execSync('npm run db:reset:test', { stdio: 'inherit' }); execSync('npm run db:seed:test', { stdio: 'inherit' }); } export default globalSetup;

db:reset:test负责清空测试库，db:seed:test负责插入基础数据（比如测试账号、基础配置）。这样每次跑测试都是从一个已知的干净状态开始。

如果项目用的是容器化数据库，那就更简单了。在 CI 配置里，每次跑 e2e 测试时启动一个新的数据库容器，跑完销毁。本地开发时可以用 Docker Compose 快速起一个测试数据库。

还有一个细节：测试数据的命名要有规律。比如所有测试账号都以e2e_开头，所有测试订单都以E2E-开头。这样即使清理不彻底，你也能通过命名规则识别出哪些是测试数据，手动清理时不会误删真实数据。

5.4 超时问题：怎么合理设置超时时间

超时设置太短，用例容易误报失败；超时设置太长，失败时等待时间太久，拖慢整体速度。我的经验是分层设置超时。

全局超时设置在配置文件里，我通常设 30 秒。这个时间足够大部分用例完成，又不会让失败用例等太久。对于特别复杂的用例，比如涉及多个页面跳转和大量数据加载的，可以在用例级别单独设置更长的超时：

test('复杂下单流程', async ({ page }) => { test.setTimeout(60000); // ... });

对于断言级别的超时，Playwright 默认是 5 秒。如果某个断言需要更长时间，可以单独设置：

await expect(page.getByText('处理完成')).toBeVisible({ timeout: 15000 });

但要注意，不要用超时来掩盖问题。如果一个用例经常超时，说明它本身有问题，要么是等待逻辑不对，要么是性能太差。应该去优化用例或者优化系统，而不是简单地把超时时间调大。

5.5 报告与日志：怎么快速定位失败原因

e2e 测试失败后，快速定位原因比什么都重要。我通常会在三个地方收集信息。

第一是控制台输出。Playwright 的 list reporter 会在控制台显示每个用例的执行结果和失败原因。如果失败原因是断言失败，它会显示期望值和实际值。

第二是HTML 报告。profile2 和 profile3 我会配置 HTML reporter，生成一个可视化的报告页面。报告里可以看到每个用例的执行时间、失败截图、错误堆栈。对于团队协作来说，HTML 报告比控制台输出更友好。

第三是trace 文件。前面说过，trace 是排查偶发失败的神器。我建议在 CI 环境里，失败时自动上传 trace 文件作为 artifact，方便后续下载分析。

另外，在用例里加日志也很有帮助。Playwright 的page.on('console')可以捕获浏览器控制台的日志，page.on('requestfailed')可以捕获失败的请求。把这些日志输出到测试报告里，排查问题时能省很多时间。

test.beforeEach(async ({ page }) => { page.on('console', (msg) => { if (msg.type() === 'error') { console.log(`浏览器错误: ${msg.text()}`); } }); page.on('requestfailed', (request) => { console.log(`请求失败: ${request.url()} - ${request.failure()?.errorText}`); }); });

这个配置能帮你抓住很多隐藏的问题，比如前端报错、接口 404、资源加载失败等。

6. 一些实操心得和避坑建议

6.1 不要追求百分之百的 e2e 覆盖率

我见过一些团队，试图用 e2e 测试覆盖所有功能，结果用例数量膨胀到几百个，跑一轮要一个小时，维护成本极高，最后大家都不愿意跑，e2e 测试形同虚设。

e2e 测试的定位是验证核心用户路径，不是替代单元测试和集成测试。把覆盖率控制在合理范围内，让 e2e 测试保持快速、稳定、可信，比追求覆盖率数字重要得多。

6.2 用例要能独立运行

每个 e2e 用例都应该能单独运行，不依赖其他用例的执行结果。这样你才能在调试时只跑一个用例，快速验证问题是否修复。如果用例之间有依赖，调试起来会非常痛苦。

实现独立运行的关键是数据自管理。每个用例在beforeEach里创建自己需要的数据，在afterEach里清理。虽然会多写一些代码，但换来的灵活性和稳定性是值得的。

6.3 定期清理和优化用例

e2e 用例不是写完就一劳永逸的。随着产品迭代，有些用例可能已经过时了，有些用例可能变得不稳定了。我建议每个月花一点时间 review 一下 e2e 用例，删掉过时的，修复不稳定的，优化运行慢的。

一个健康的 e2e 测试套件，应该是跑得快、挂得少、修得快。如果发现某个用例经常挂，要么修复它，要么删掉它。留着不稳定的用例，只会消耗团队对 e2e 测试的信任。

6.4 profile 配置要跟着项目走

profile1、profile2、profile3 不是固定的，你可以根据项目需要增减。比如小项目可能只需要 profile1 和 profile2，大项目可能需要 profile4 来跑跨浏览器兼容性测试，profile5 来跑移动端适配测试。

关键是让每个 profile 有明确的用途，不要为了配置而配置。profile 太多会导致维护成本上升，太少又无法覆盖不同场景。找到适合你团队的平衡点。

6.5 把 e2e 测试当成产品来维护

最后一条心得：e2e 测试代码也是代码，需要像产品代码一样维护。它需要良好的结构、清晰的命名、适当的抽象、定期的重构。如果你把 e2e 测试当成一次性脚本，随便写写，那它很快就会变成技术债。

我在团队里推行的一个做法是：e2e 测试代码和产品代码走同样的 code review 流程。新加的用例要 review，修改的用例也要 review。这样能保证用例质量，也能让团队成员互相学习。

这个内容后续还可以这样扩展：把 e2e 测试和性能监控结合起来，在核心路径上采集加载时间、接口响应时间等指标，建立性能基线，一旦性能退化就自动告警。这样 e2e 测试就不只是功能验证，还能成为性能保障的一部分。