企业官网建设流程全解析

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 install

npx playwright install会下载 Chromium、Firefox、WebKit 三个浏览器。如果你只需要跑 Chromium，可以加--with-deps chromium只装一个，节省时间。

接下来创建配置文件playwright.config.ts：

import { 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 --shard=1/3 npx playwright test --shard=2/3 npx playwright test --shard=3/3

这三条命令可以同时在三个 CI job 里执行，每个 job 只跑三分之一用例。最后把报告合并即可。我实测过一个 200 用例的套件，单机串行需要 20 分钟，分成 4 个 shard 并行跑，总时间压到了 5 分钟左右。

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

5.1 用例不稳定（Flaky Test）的根因分析与解决

Flaky test 是 e2e 测试的头号敌人。同一个用例，跑十次挂三次，你都不知道该不该信它。我排查过大量 flaky 用例，根因基本集中在以下几类：

我的经验是：遇到 flaky 用例，第一件事是看 trace。Playwright 的 trace viewer 会记录每一步操作的截图和 DOM 快照，你能清楚地看到失败那一刻页面长什么样。大部分时候，看一眼截图就知道问题在哪了。

5.2 选择器失效的三种场景与应对策略

选择器失效是另一个高频问题。我总结下来主要有三种场景：

第一种是前端改了类名或结构。这种最常見，解决方案就是前面说的，优先用 role 和 text，关键元素加>