企业官网建设流程全解析

聊到 e2e，很多人的第一反应是：慢、脆、维护成本高。这个印象不算冤枉，但我做了几年测试基础设施之后，想说的是——e2e 测试往往是被错误使用和错误设计害的，不是 e2e 本身的问题。今天借一个具体的 e2e 工程配置（我习惯叫它 profile1），把这件事讲清楚。

所谓 profile1，是第一个端到端测试配置档位：只跑核心业务链路、只覆盖高价值场景、固定浏览器基线、固定账号和固定数据。它解决的不是“测得多”，而是“测得准”。这个思路直接决定了 e2e 项目能不能活下去。无论是刚入行的测试新人，还是被 e2e 用例折磨的研发同学，这套东西都可以直接抄作业。

1. 先把 e2e 讲透：它到底是什么样的测试

1.1 e2e 和单元测试、集成测试的实际分工

聊 e2e 之前，必须先弄清楚它在测试体系里的位置。单元测试测的是一个函数、一个组件；集成测试测的是模块之间的接口；而端到端测试（即 e2e）是从用户视角出发，模拟真实用户在真实浏览器里点击、输入、跳转、提交，验证整个系统串起来之后到底能不能完成任务。

我用一个点外卖的类比来解释：单元测试是验证“锅能不能烧热”，集成测试是验证“灶台和燃气管道有没有接好”，e2e 则是真的点一份外卖，确认送到你手里还能吃。

所以 e2e 的核心价值不是替代前两类测试，而是补上它们的盲区。单元测试和集成测试都默认“上下游是对的”，但实际系统中，前端路由变了、后端接口字段改了、权限配置错了、第三方依赖超时了，这些组合起来的问题只有在真实链路里才能暴露。e2e 就是最后一道闸门。

1.2 为什么很多团队谈“e2e”色变

大多数团队对 e2e 的负面印象，来自于三个具体的失控点。

第一个失控点是用例太多。一套系统跑下来，几百个 e2e 用例是常态，每个用例从准备数据到页面断言，快则十几秒，慢则一分钟。全量跑完一小时打底，CI 流程被拖到没法忍受，于是大家开始跳过 e2e。

第二个失控点是太脆。今天页面样式调一下、文案改一个字、某个接口响应慢了 200 毫秒，e2e 就红了。没有人愿意整天维护这种“和自己没关系”的失败用例，时间一长，红着红着就没人看了。

第三个失控点是数据污染。大家共用一套测试环境，A 的用例改了订单状态，B 的用例就挂了。负责人每天都在“清数据”的路上。

这三个问题的根源，其实都不是 e2e 这个技术，而是没有设计好测试策略。而 profile1 这个配置档位，就是针对这三个失控点做的第一层收敛。

1.3 e2e 的正确打开方式：核心链路优先

我在多个项目里得到一个规律：一个业务系统里真正决定用户能不能用起来的链路，通常不会超过五条。比如电商系统就是登录→搜索→加购→下单→支付；内容平台就是登录→浏览→发文→审核→展示。

把这些链路维护好，e2e 的价值就已经体现了。其他边角场景、异常分支，让单元测试去覆盖，性价比高得多。

这里补充一个关键认知：e2e 是为“可靠”服务的，不是为“数量”服务的。跑 200 个没人在意的用例，不如跑 10 个关键时刻能救命的用例。profile1 的第一原则，就是“只测高价值链路，不做全量覆盖”。

2. 方案选型：用哪套工具链做端到端测试

2.1 工具选型的三个候选

既然要做 e2e，第一件事就是选工具。当前主流的三条路线是 Selenium、Cypress 和 Playwright。

Selenium 是老牌选手，支持语言多、生态全，但最大的问题在于它只是“浏览器自动化协议”，并没有在测试体验层面做太多设计。你用 Selenium 写用例，要自己管理等待、自己处理 iframe、自己拼断言，写起来像在写基础设施，不像在写测试。

Cypress 的体验是好很多，它有超棒的调试体验、自动等待和实时重载，但它的架构决定它只能在 Node.js 进程里跑，不支持多标签页，也不支持原生移动端手势。

Playwright 是微软开源的方案，最吸引我的三点：一是自动等待机制非常稳，几乎不用手动写 sleep；二是支持多上下文，可以模拟多个用户同时操作，这对并发类场景是降维打击；三是内置了网络拦截、移动端模拟和文件下载处理，几乎把 e2e 工程化的坑都填平了。

2.2 我为什么最终用 Playwright 写 profile1

我的 profile1 配置是基于 Playwright 搭的，原因很简单：它能让我在同一个配置文件里，用最少的代码获得最稳的执行结果。

我这里说的 profile1，不是 Playwright 官方配置里那个 profile 概念，而是我们自己内部定义的“第一套端到端基线档位”：Chromium 桌面版、一套固定测试账号、一套固定测试数据、串行执行、失败自动截图保留现场。这套配置解决的核心问题，就是前面说的“脆”和“数据污染”。

Playwright 给这套设计提供了很好的底座。它的 runner 原生支持按测试文件串行/并行配置、自动重试、trace 录制和视频回放。这些能力如果靠 Selenium 自己攒，工程量非常大。

选型时还有一个小考量：团队里后端同事也要参与 e2e 用例维护，Playwright 支持 JavaScript 和 TypeScript，前后端同学都能快速上手，降低了协作门槛。

2.3 工具选型中我踩过的两个坑

第一个坑是盲目追求“全浏览器覆盖”。早年我为了漂亮，配了 Chrome、Firefox、WebKit、移动端模拟，结果每轮 CI 跑下来，光是环境初始化就浪费大量时间。后来自我反思了一下，95% 的用户用的是 Chromium 系浏览器，Firefox 和 WebKit 回归没必要天天跑。所以 profile1 默认只跑 Chromium，其他浏览器单独配置成 nightly 手工触发，不占主干流程。

第二个坑是“测试环境完美主义”。有些人总想等测试环境稳定了再跑 e2e，但现实里测试环境永远不可能稳定。与其等环境，不如在用例里主动造数据、隔离数据和恢复现场。这一步把稳定性从“靠运气”变成“靠设计”。

3. profile1 配置拆解：一份可复制的 e2e 工程模板

3.1 基础配置：playwright.config.ts 骨架

整个 profile1 的核心，是一个配置文件。下面这个是经过多个项目验证的骨架，可以直接抄走用：

// playwright.config.ts import { defineConfig } from '@playwright/test'; export default defineConfig({ // 测试文件目录 testDir: './e2e/specs', // 失败重试策略：第一次失败后重试1次 retries: process.env.CI ? 1 : 0, // 并发策略：profile1 采用串行执行，避免数据相互影响 fullyParallel: false, workers: 1, // 全局超时：单条用例最长 30s timeout: 30_000, expect: { // 断言超时：自动等待最多 5s timeout: 5_000, }, // 测试数据隔离：每个用例独立临时目录 use: { baseURL: process.env.E2E_BASE_URL || 'https://staging.example.com', headless: true, viewport: { width: 1280, height: 720 }, ignoreHTTPSErrors: true, screenshot: 'only-on-failure', trace: 'retain-on-failure', video: 'off', }, projects: [ { name: 'profile1-chromium', use: { browserName: 'chromium', // 固定语言区域，避免文案断言因环境差异失败 locale: 'zh-CN', timezoneId: 'Asia/Shanghai', }, }, ], });

几个容易忽略的点我要单独说明。

第一是fullyParallel: false和workers: 1。很多人一上来就把 e2e 并行度拉满，觉得“跑得快就是好”。但 profile1 的设计初衷是稳定优先，同一条核心链路的用例如果并行跑，订单数据会互相抢，谁先拿到谁有理，跑出来的结果没有参考价值。所以 profile1 只串行，后面要扩并发，再单独拆项目跑。

第二是trace: 'retain-on-failure'。Playwright 的 trace 会在用例失败时记录整个页面的操作轨迹，包括网络请求、控制台日志、DOM 快照。排查问题的时候，点开 trace 就能看到失败前最后几步发生了什么，比看截图高效得多。

第三是固定locale和timezoneId。如果不锁这两个值，比如一个打开页面时间是中午十二点的用例，在英国时区跑出来是凌晨四点，日期文案和排序行为都会变。锁定了才能保证断言结果可复现。

3.2 测试隔离设计：让用例互不打架

profile1 最关键的设计不是技术栈，而是数据隔离策略。这里分享我总结的三层隔离方法。

第一层：每个用例使用独立账号。测试环境里预先准备一组账号池，比如alice_01到alice_50，每个用例通过参数取一个未使用的账号。这样即使 A 用例把账号的数据弄脏了，B 用例的下一次运行也能拿到干净账号。

第二层：每个用例在开始时清理前置数据。比如测试下单流程，第一步先调用后端 API 取消该账号下的历史订单，而不是假设环境里没有脏数据。这一步虽然多花几百毫秒，但能避免大量“偶发失败”。

第三层：关键数据用随机后缀。比如测试创建商品，商品名称用E2E_PROD_时间戳_随机数来命名。这样即使某次用例失败导致数据残留，也不会影响其他用例的查询结果。

这三层做完，测试环境的脏数据问题基本可控。说个题外话：依赖测试环境运维手工清库的做法，本质上是用人肉成本弥补设计缺陷，早晚会出问题。

3.3 数据准备与恢复自动化的细节

隔离策略听着简单，但在实操里有一个很容易被忽视的细节：数据准备工作必须通过 API 或数据库直连，不要通过 UI 去准备。

有些同事图省事，直接在用例里先点一遍“创建订单”的 UI，再开始测“订单审批”。这样做最大的问题，是 UI 一旦变更，连数据准备步骤都挂了，真正的被测链路反而没跑到。正确做法是调用后端接口，快速造数据：

// e2e/helpers/factory.ts import { apiRequest } from './apiClient'; // 直接调用后端 API 创建测试订单 export async function createOrder(token: string, itemId: string) { const response = await apiRequest('/api/orders', { method: 'POST', token, data: { itemId, quantity: 1, remark: `E2E_${Date.now()}` }, }); return response.json(); }

这样数据准备步骤稳定、快速、与 UI 解耦。用例本身只需要关注真正的业务操作。

4. 从零到一：把 e2e 用例跑起来的完整过程

4.1 安装与初始化

我用一个全新仓库来演示完整过程。首先初始化项目：

mkdir e2e-demo && cd e2e-demo npm init -y npm install -D @playwright/test @types/node npx playwright install chromium

这里重点提示：npx playwright install chromium一定要执行，它是下载浏览器二进制文件的关键步骤。很多新手卡在“安装完跑不起来”，多半是遗漏了这一步。

然后按 3.1 的配置创建playwright.config.ts，再建对应的目录结构：

e2e/ ├── config/ # 测试环境配置 ├── helpers/ # 数据工厂、API 客户端 ├── specs/ # 用例目录 └── fixtures/ # 固定测试账号与测试文件

目录结构这件事看着小，但早期不规划的话，后患无穷。我见过一个项目把用例直接堆在根目录，结果 80 个文件混在一起，维护的人根本分不清哪个是哪个。代码分层和目录规划也是为可维护性服务的。

4.2 编写第一个能跑的核心链路用例

下面这条用例是 profile1 里典型的“登录→搜索→加购→结算”链路，我拿它当例子讲细节。

// e2e/specs/purchase.spec.ts import { test, expect } from '@playwright/test'; import { loginAs } from '../helpers/auth'; import { createProduct } from '../helpers/factory'; test('用户可以完成核心购买流程', async ({ page }) => { // 数据准备阶段：通过 API 创建测试商品 const product = await createProduct({ name: `E2E_PROD_${Date.now()}`, price: 199, stock: 100, }); // 登录阶段：直接设置登录态，不走 UI 登录 const token = await loginAs('alice_01'); await page.context().addCookies([{ name: 'session', value: token, url: testInfo.baseURL }]); // 业务操作 await page.goto('/'); await page.getByPlaceholder('搜索商品').fill(product.name); await page.getByRole('button', { name: '搜索' }).click(); await page.getByText(product.name).click(); await page.getByRole('button', { name: '加入购物车' }).click(); await page.getByRole('button', { name: '去结算' }).click(); // 断言 await expect(page.getByText('订单提交成功')).toBeVisible(); });

这段代码里藏着三个 Playwright 的重要技巧。

第一个技巧是“登录不走 UI”。有些测试工程师习惯一上来就输入用户名密码，但这样做的问题是：登录过程本身也是一个不稳定的环节（比如验证码、短信）。在 profile1 里，我们通过 API 拿 token，然后直接注入 cookie，把登录态准备好。登录链路的 UI 单独一条用例去测就行，不需要每条用例都重复测一遍登录。

第二个技巧是定位器用的getByRole、getByText、getByPlaceholder。Playwright 强烈不建议用 XPath 和 CSS 定位，因为这类定位器对 DOM 结构变化非常敏感。语义化定位器模拟的是“用户怎么找到这个元素”，页面结构调整时，角色和文本不会变，用例的稳定性会大大提升。

第三个技巧是 UI 操作之后“必须有一个明确的断言”。上面代码最后一行await expect(page.getByText('订单提交成功')).toBeVisible()，是整条用例的灵魂。没有断言，操作完就结束，根本不知道这个链路是否真的成功。断言的toBeVisible()底层带自动等待，会在 5 秒内重试，而不是立即返回失败。

4.3 跑通用例和查看报告

配置和用例都写好后，运行整个 profile1：

npx playwright test

跑完后 Playwright 会生成一个 HTML 报告，默认在playwright-report/index.html。用浏览器打开，可以看到每条用例的状态、执行时间、失败时自动截的图和 trace。

我第一次用这个报告时还是挺惊艳的——失败用例可以直接在报告里看时间轴、看每一步的 DOM 快照，甚至可以看到操作每一步时页面的实际截图。定位问题基本不用再对着日志猜。

这里分享我的排查习惯：看到失败，不急着改代码，先看 trace 里“页面最后变成什么样了”。80% 的问题在这一步就能定位，剩下 20% 再去看网络请求和控制台日志。

4.4 接入 CI：让 profile1 每晚自动执行

本地能跑通了，接下来就要把它接入到持续集成流程里。我在 GitHub Actions 里的配置非常简单：

name: e2e-profile1 on: schedule: - cron: '0 2 * * *' # 每天凌晨 2 点执行 workflow_dispatch: # 支持手工触发 jobs: e2e: 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 chromium --with-deps - run: npx playwright test - uses: actions/upload-artifact@v4 if: failure() with: name: playwright-report path: playwright-report/

两个细节值得说明。第一是--with-deps，它会自动安装浏览器运行所需的系统依赖库，不要省掉，否则很多 Linux 环境会报缺库。第二是upload-artifact只在失败时上传报告，这样既不影响正常流程，出了问题也能拿到完整现场。

接入 CI 之后，凌晨跑一次全量 profile1，早上到公司先看报告，有红就开 trace 定位，效率和观感都很好。

5. 避坑实录：我踩过的 6 个 e2e 典型问题

5.1 常见问题速查表

这五年多踩过的坑非常多，我把最高频的六类整理成表：

这个表里的每一条，都是真实项目里反复出现的。前端改了个 CSS 导致按钮被一个浮层盖住，click 没生效；同样的用例换到不同时区，时间文案就不匹配了。这些问题想靠“细心”规避是不现实的，要靠设计模式。

5.2 独家排查技巧：先看 trace 再看日志

排查 e2e 失败时，我的固定顺序是：trace → 截图 → 网络请求 → 控制台日志 → 代码逻辑。

很多时候，一个人直接在失败日志的大海捞针里找问题是很累的，但 trace 可以直接回放失败前的操作序列。看到哪一步页面变成异常状态，问题就在那一步的上文。

举一个真实案例：某次“创建订单”用例偶发失败，截图看起来一切正常，页面停在订单确认页，按钮也可见。但 trace 里显示，点击“提交订单”后，接口返回了 500，页面弹出错误提示。再追网络请求，发现后端某个依赖服务超时了。这根本不是前端问题，也不是用例问题，而是服务端某个第三方接口不稳定。如果只盯着日志猜，可能要调好久。

5.3 定时用例的“垃圾数据自动清理”方案

profile1 跑久了，测试环境里的残留数据会越来越多。虽然我们有独立账号、随机后缀，数据表还是会膨胀。我后来加了一个“测试数据回收”脚本，核心逻辑是删除 createdAt 超过 24 小时且名称带有E2E_前缀的数据。每天在 CI 执行用例之前跑一遍。

脚本本身很简单，但收益很大：数据库不会无限膨胀，用例之间也不会因为历史脏数据产生偶发性失败。这一步强烈建议纳入 profile1 标配，否则跑三个月后再回头清理，成本会高得多。

6. 从 profile1 出发：后续测试能力怎么扩展

6.1 什么时候该加 profile2、profile3

profile1 稳定运行一个月后，自然会想扩展覆盖范围。我建议按“核心链路 → 关键分支 → 全量回归”的顺序分阶段扩展。

profile2 可以加“异常流程与权限场景”，比如未登录访问受保护页面、超管以外的角色提交审核、库存不足时的下单逻辑。这些场景不常见，但出问题就是大事，值得每天跑。

profile3 可以加“多浏览器基线”，把 WebKit 和 Firefox 加进去，每周跑一次。移动端专项可以单独再开一个 profile，用 Playwright 的设备描述符模拟移动视口。

扩展的时候要守住一个原则：每个 profile 都是独立可运行的配置，名称清晰、职责单一。这样即使某天某个 profile 跑挂了，也不会拖垮其他 profile。

6.2 覆盖率不是目的，断言质量才是

很多团队拿到 e2e 工具后，先问“能覆盖多少功能”，然后拼命堆用例。但我见过太多“50 条用例全绿但核心功能照样坏”的项目——原因是用例全是顺着页面点一遍，没有任何有效断言。

有效的 e2e 断言应该验证“业务结果确实发生了”，而不只是“页面没报错”。比如下单成功，要断言“订单号生成且状态为待支付”“库存扣减了”“用户中心出现了这条订单”。只有断言指向业务结果，e2e 才有实际价值。

profile1 里的每条用例，我都会要求自己用一句话描述它的业务价值。如果描述不出来，这条用例就不该进 profile1。

6.3 团队协作：让 e2e 用例像代码一样被评审

最后分享一个管理层面的经验：e2e 用例必须有 code review，而且要有变更记录。我见过太多“坏掉一个月没人发现”的 e2e 用例，问题根源就是用例没有人负责、没有评审、没有责任归属。

在 profile1 里，我把e2e/specs目录的 code owner 设给测试负责人和前端负责人，任何增删改都必须通过 PR 合入。用例开始变绿之后，下一步就要把关键链路的质量指标交给团队负责人盯住。e2e 用例的健康度，反射的是整个系统核心链路的健康度，这件事值得认真对待。

我个人在实际操作中的体会是：e2e 最难的一步从来不是写代码，而是建立一套“不会自己崩掉”的测试秩序。profile1 的所有设计——固定浏览器、固定账号、数据隔离、独立命名、自动清理——都是在为这个秩序服务。如果你正准备在团队里落地端到端测试，别急着堆用例，先把这套秩序打牢。