企业官网建设流程全解析

各位做前后端的朋友，不知道你们有没有遇到过这种尴尬：单元测试跑了 100% 覆盖，接口测试绿得发亮，结果上线第二天用户反馈"下单按钮点了没反应"，你打开后台一看，接口返回数据正常，数据库也有记录，最后发现是前端拿到的用户 ID 字段名对不上。这就是典型的"局部都没问题，拼起来就出问题"，也是我在团队里坚持搞 E2E 测试（端到端测试）的根本原因。

这篇内容不是教科书式的概念科普，而是我自己从零搭起一套端到端测试体系的完整实战记录，包括为什么之前的自动化测试形同虚设、怎么选型、怎么写用例才能稳定不脆、以及 CI 上跑挂之后我是怎么一步步排查的。如果你正准备给项目引入 E2E，或者已经在写但总觉得用例三天两头挂、维护成本高得想删库跑路，那这篇应该能帮你少踩不少坑。

1. 先把"端到端"三个字掰开揉碎：E2E 到底在测什么

1.1 不是所有自动化测试都叫 E2E

很多人一听到"E2E"就以为是"用自动化脚本点点点"。这是个非常大的误解。我见过不少团队，用 Selenium 写了十几个 UI 脚本，能自动登录、能自动点按钮、能截图，就对外宣称"我们做了端到端测试"。但实际上，这些脚本测来测去都在同一个前端项目里打转，后端是 mock 的，数据库是内存库，测的根本不是真实链路。

真正的 E2E 测试，测的是"整个系统按照真实用户的使用路径完整走一遍之后，每个环节是否给出了正确反应"。这里的关键词是"完整走一遍"，而不是"走一部分"。

我习惯用一个例子和团队解释三层测试的差异：

单元测试好比检查发动机的每个零件是否合格，集成测试好比验证发动机和变速箱能否咬合，而 E2E 测试是整车通电之后，你坐进驾驶座，点火，挂挡，松离合，整个车能不能平稳地开出去。

1.2 为什么 E2E 必须存在：它验证的是"系统间的手协议"

我在上家公司遇到过一个非常典型的 bug，至今记忆犹新。订单服务下单成功后会往消息队列里推一条消息，库存服务消费这个消息去扣库存。两个服务各自的单元测试都过了，集成测试也 mock 了消息队列验证了收发逻辑，结果上线后库存一直不扣。查了一天一夜，最后发现是订单服务推的消息里，商品的 SKU 字段名是sku_code，而库存服务消费的时候取的字段名是skuId。两边都没错，各自的测试也都对，但连在一起就是不通。

这种问题，本质上是"接口约定"问题，而接口约定只有在真实链路里才能被验证。

所以我说 E2E 测试真正验证的是"服务之间的握手协议"。如果一条核心业务链路没有 E2E 覆盖，那么系统间只要有人改了字段名、改了参数类型、改了响应结构，你的 CI 是绿的，但你心里是虚的。

1.3 一个 E2E 用例该长什么样

我理解中的 E2E 不是"打开页面-点两下-看有没有报错"这种冒烟脚本，而是"以业务结果为导向"的验证。一条合格的核心链路用例，至少应该包含这几个阶段：

1. 前置准备：准备好测试数据和用户态
2. 执行路径：按照真实用户的操作路径走完流程
3. 跨环节验证：每一步不仅断言页面表现，更要验证背后的数据落库情况
4. 清理回收：无论成功失败，测试数据要清理干净，不能污染下一次运行

举个例子，一条"用户下单"的 E2E 用例，它应该是这样跑的：真实用户注册/登录，进入商品页浏览，加购，去结算，填收货地址，选支付方式，提交订单，跳转支付，支付成功，然后回到订单列表，看到这笔订单状态变成"已支付"，最后还要去数据库里查一下这笔订单的支付流水号和金额是否正确。整个过程里任何一个环节的字段映射错了、接口超时了、状态流转断了，用例都会红。

这就是 E2E 的价值：它把一个业务链路当成一个整体来验收，而不是拆碎了各自为战。

2. 搭建一套可维护的 E2E 骨架：从选型到工程化设计

E2E 测试落地最大的障碍不是写不出来，而是写出来之后活不过三个月。这其中选型和工程架构是决定生死的两步。

2.1 技术栈选择的三个硬标准：为什么是 Playwright

我这里先亮个态度：Playwright 是我目前最推荐的 E2E 框架，但这不是因为它"最潮"，而是它在几个关键痛点上确实解决了问题。我当时选型时有三个硬标准：

标准一：等待机制必须是智能的，而不是 sleep 堆出来的。

Selenium 时代写 E2E 最痛苦的就是等待。元素还没渲染出来，脚本先执行了，然后NoSuchElementException，你只能加time.sleep(1)，加少了偶发失败，加多了用例慢如蜗牛。Playwright 的自动等待机制是内置的，它会自动重试直到元素可操作、网络请求稳定、页面负载完成。这直接省掉了我过去维护waitForElement()工具类的一大半精力。

标准二：多浏览器覆盖能力和移动端模拟必须内置。

我们项目面向的用户既有桌面 Chrome 又有 Safari，还有不少用手机浏览器访问的。Playwright 官方维护的 WebKit 支持是 Firefox/Safari 内核的，这在 Chromium 一统天下的开源框架里是稀缺品。

标准三：调试体验必须能救我的命。

E2E 跑挂之后，如果只有一段 terminal 报错日志，那排查成本极高。Playwright 自带 trace 录制，可以回放整个测试过程的页面快照、网络请求、控制台日志，还能查看每个操作时刻的 DOM 状态。这东西的排查效率和传统截图工具完全不是一个量级。

选型对比我也放出来，给还在犹豫的朋友一个参考：

2.2 工程结构：让用例像积木一样可复用

选完框架只是第一步，真正的挑战在工程化。我第一版 E2E 项目就是所有用例平铺在一个文件夹里，公共操作复制粘贴，结果一个页面结构调整，20 个用例跟着改，改完又坏了 5 个。后来我彻底重构，采用了分层结构，这里直接贴出我现在的项目骨架：

e2e/ ├── config/ │ └── playwright.config.ts # 全局配置：环境、截图、trace ├── fixtures/ │ ├── auth.ts # 登录态 fixture │ └── order.ts # 下单相关数据 fixture ├── pages/ │ ├── login.page.ts # 登录页对象 │ ├── product.page.ts # 商品页对象 │ ├── cart.page.ts # 购物车页对象 │ └── order.page.ts # 订单页对象 ├── data/ │ ├── users.json # 测试账号 │ └── products.json # 测试商品 ├── utils/ │ ├── db.ts # 数据库查询工具 │ └── request.ts # API 请求工具 ├── tests/ │ ├── e2e/ │ │ ├── order-flow.spec.ts # 下单主链路 │ │ ├── payment-flow.spec.ts # 支付链路 │ │ ├── refund-flow.spec.ts # 退款链路 │ │ └── ... │ └── smoke/ │ ├── login.spec.ts │ └── home.spec.ts └── outputs/ # 测试报告、截图、trace

这个结构里最核心的一层是pages/，也就是我们常说的 Page Object 模式。它的核心思想：把"页面上某个按钮怎么定位、点击之后发生什么"这类细节，全部封装进页面对象里，测试用例只描述"业务动作"，而不关心"怎么定位到那个按钮"。

比如登录页面对象长这样：

// pages/login.page.ts export class LoginPage { constructor(private page: Page) {} async goto() { await this.page.goto('/login'); } async login(username: string, password: string) { await this.page.getByLabel('用户名').fill(username); await this.page.getByLabel('密码').fill(password); await this.page.getByRole('button', { name: '登 录' }).click(); await this.page.waitForURL('**/home'); } }

对应的测试用例是这样：

// tests/e2e/order-flow.spec.ts test('user can place an order successfully', async ({ page, auth }) => { const loginPage = new LoginPage(page); await loginPage.goto(); await loginPage.login(auth.username, auth.password); // 后续步骤只需要调用业务动作 ... });

好处是明显的：将来登录页加了图形验证码、改了按钮文案、调整了 URL，我只需要改一个login.page.ts，而不是满项目去找所有写了登录操作的用例。

2.3 fixture 与 profile 机制：一套用例跑遍所有环境

E2E 测试最尴尬的问题之一，就是"本地能过，测试环境挂了""测试环境过了，预发又挂了"。环境差异是 E2E 维护成本的大头。

我的解法是把"环境差异"从用例里彻底剥离出去，存到一个环境配置文件里，通过BASE_URL、API_BASE这类变量注入。Playwright 的 project 机制正好支持我定义不同的"运行 profile"。

比如playwright.config.ts里：

// config/playwright.config.ts import { defineConfig } from '@playwright/test'; export default defineConfig({ projects: [ { name: 'staging-chromium', use: { baseURL: process.env.STAGING_URL || 'https://staging.example.com', viewport: { width: 1280, height: 720 }, }, }, { name: 'production-smoke', use: { baseURL: process.env.PROD_URL || 'https://www.example.com', viewport: { width: 390, height: 844 }, }, }, ], });

然后给项目配几套 npm scripts：

# 跑测试环境回归 npm run test:e2e:staging # 跑线上冒烟（低频率人工触发） npm run test:smoke:prod

这里有个很关键的经验：同一套用例，跑的环境不同，允许的严格度也不同。测试环境可以做全量回归、可以验证数据库落库；生产环境做冒烟巡检时，就不能去查生产数据库（权限和安全性都不允许），断言也以核心结果的 UI 呈现和 API 返回为准。

这个"profile"的设计思路，实际就是把"用例逻辑"和"运行环境"解耦。你现在可能觉得不就是多传个参数吗，但等你真正跑起来之后会发现，没有这层设计，用例会变成一次性用品——换个环境跑，全是红，改又不敢改，删又不舍得删。

3. 手写三条核心链路：从登录到支付的真实用例拆解

选了框架、搭了骨架，接下来就是最硬核的部分：写用例。这一节我用三条我实际写过的链路来拆解，重点不是说代码怎么敲，而是分享我在设计这些用例时的判断逻辑。

第一条：登录。第二条：下单支付。第三条：跨服务数据流转。三条链路覆盖了 E2E 最典型的三种验证模式。

3.1 登录态：动态获取，而不是硬编码

很多团队的 E2E 用例里登录这一步是这么写的：直接拼一个 URL，后面带上固定的 token 参数，或者从一个写死的 session 文件里读 cookie。这样看起来省事，但埋了两个雷：

一是 token 会过期。测试环境一般 2 小时 token 就失效了，第二天 CI 一跑，发现全线飘红，但你根本不知道是代码坏了还是 token 过期了。

二是绕过了"登录"这个业务链路本身。如果登录功能真的坏了，你的用例根本发现不了，因为压根没走登录。

我的做法是：用 API 去动态获取登录态，然后注入到浏览器上下文里。这样既不用每次 UI 都走一遍登录（省时），又能确保登录链路由单独的用例去覆盖（不漏测）。

// fixtures/auth.ts import { test as base, expect } from '@playwright/test'; export const test = base.extend({ auth: async ({ request }, use) => { // 先调接口拿真实 token const res = await request.post(`${process.env.API_BASE}/auth/login`, { data: { username: process.env.TEST_USER, password: process.env.TEST_PASS, }, }); expect(res.ok()).toBeTruthy(); const { token } = await res.json(); await use({ token, username: process.env.TEST_USER }); }, });

然后在用例里，把这个 token 注入到page的context：

test('order flow: full path', async ({ browser, auth }) => { const context = await browser.newContext({ storageState: { cookies: [{ name: 'session_token', value: auth.token, domain: new URL(process.env.BASE_URL).hostname, path: '/', httpOnly: true, }], }, }); const page = await context.newPage(); await page.goto('/home'); // 此时已经是登录态，继续走后续流程 });

这里有个细节容易出现：某些项目里把会话信息放在 localStorage 而不是 cookie。如果你遇到的是这种情况，用addInitScript注入即可，原理一样，都是动态获取、动态注入，别写死。

3.2 下单支付链路：断言落在"数据结果"而不是"界面元素"

这是我踩过最深的一个坑，也是我认为 E2E 用例设计最核心的一条原则：断言要落在业务结果上，而不是界面元素上。

举个例子，用户下单成功后，页面会跳转到"订单详情"，并显示一行字"支付成功"。很多人的断言就是expect(page.getByText('支付成功')).toBeVisible()。这有问题吗？表面上没问题，但如果前端因为某个 bug 导致"支付成功"这四个字被错误地展示出来（比如后端返回了一个错误的 status），这个断言照样通过。

真正可靠的断言应该在支付成功后，去检索订单接口或者数据库，验证订单状态真的变成了"paid"、支付渠道流水号真的匹配、支付金额真的对得上。前端文案可能骗人，数据状态不会。

我写这条用例时的具体流程：

test('full order and payment flow', async ({ page, auth }) => { // 注入登录态，进入商品页 await page.goto('/product/1001'); await page.getByRole('button', { name: '加入购物车' }).click(); await page.getByRole('button', { name: '去结算' }).click(); // 勾选默认地址，选择在线支付 await page.locator('.address-card').first().click(); await page.getByText('在线支付').click(); await page.getByRole('button', { name: '提交订单' }).click(); // 进入收银台，模拟支付成功回调 await page.getByRole('button', { name: '立即支付' }).click(); await page.waitForURL('**/order/result**'); // 从 URL 中取订单号 const orderId = new URL(page.url()).searchParams.get('order_no'); expect(orderId).toBeTruthy(); // 关键：通过 API 拿订单状态，验证真实数据 const orderRes = await page.request.get(`/api/order/${orderId}`); const orderData = await orderRes.json(); expect(orderData.data.status).toBe('paid'); expect(orderData.data.pay_amount).toBe(99.00); // 再回到订单列表页确认 UI 同步 await page.goto('/order/list'); await expect(page.locator(`text=${orderId}`)).toBeVisible(); await expect(page.locator(`[data-status="paid"]`)).toBeVisible(); });

你仔细品一下这个用例和"纯 UI 脚本"的区别：每一步 UI 操作之后，我都想办法用 API 或数据库做二次确认。UI 负责触发，数据层负责验证。这样前端样式烂了、文案错了都不影响核心功能判断，而核心数据错了，前端的任何假象都骗不过用例。

3.3 跨服务数据流转：E2E 最强的用武之地

有些链路不是一步两步能走完的，而是跨了好几个服务、好几张表，甚至隔了几分钟才完成。这种场景下，E2E 的价值是其他任何测试手段都替代不了的。

我举一个"优惠券发放-使用-核销"的链路：用户在活动页领了一张满减券，下单时勾选使用，支付成功后，优惠券状态要变成"已使用"；如果用户退款，优惠券要回到"未使用"状态。

这个链路的每一步都涉及不同的服务和数据库表。我的做法是在用例的合适位置插入数据库校验：

// utils/db.ts import { Pool } from 'pg'; const pool = new Pool({ connectionString: process.env.DB_URL }); export async function queryCouponStatus(couponId: string) { const result = await pool.query( 'SELECT status FROM coupon WHERE id = $1', [couponId] ); return result.rows[0]?.status; }

然后在用例里的断言就是：

test('coupon full lifecycle', async ({ page, auth }) => { // ... 领券、下单、使用优惠券、支付 // 支付完成后，去数据库验证优惠券已核销 expect(await queryCouponStatus(couponId)).toBe('used'); // 发起退款 // ... // 退款完成后，验证优惠券被退回 expect(await queryCouponStatus(couponId)).toBe('unused'); });

这个用例的价值已经不只是发现 bug 了，它是给整个公司的优惠券体系建立了一条"安全绳"。任何一个人改了优惠券的状态机、改了字段、改了核销逻辑，只要这条用例还跑着，违规改动就会在 CI 阶段被拦下来。

4. 稳定性是第一生产力：E2E 为何总在 CI 上翻车

我相信每个写过 E2E 的人都经历过那个崩溃时刻：本地跑得好好的，推到 CI 上就红，你盯着日志看了半天，发现是"等待元素超时"。然后把超时时间从 5 秒改成 15 秒，推上去，还是偶发红。最后只要你一天不处理，它就一天红着，CI 开始习惯性飘红，然后大家对这个测试逐渐失去信任，最终沦落到"失败就重跑，再失败就跳过"。

这一节我想好好聊聊 E2E 不稳定问题的根源和我的治理方案，因为这才是 E2E 工程能走多远的分水岭。

4.1 "假失败"的根源：不是测试写错了，而是环境没隔离好

先说一个反直觉的结论：CI 上 E2E 的偶发失败，大部分不是测试代码的问题，是环境干扰造成的。主要干扰源有三类：

第一类是数据干扰。上一个用例建了订单，没清理干净，下一个用例在查询列表时看到了多余数据，断言失败。或者两个用例同时用同一个账号下单，并发导致库存数据互相影响。这类问题会在并行执行时成倍放大。

第二类是网络时序干扰。前端快请求进来了，后端还在处理上一个请求；或者前端已经切了页面，但旧页面的回调还在执行，把新页面的状态给覆盖了。

第三类是资源性能干扰。CI 机器不固定，有时候负载高，页面渲染慢，默认的 5 秒等待就是不够。不是代码坏了，纯粹是机器卡了。

我当时的排查链路是这样的，全流程写出来给各位参考：

第一步：看失败截图和 trace，判断是"卡在哪一步"。如果每次都卡在同一个步骤，大概率是真实 bug 或等待策略问题；如果每次卡的位置不固定，大概率是环境数据或性能问题。

第二步：看失败发生时的 API 响应。我习惯在 trace 里把失败前 30 秒内的接口请求全部拉出来，重点看有没有 500/502，或者响应时间超过 2 秒的请求。

第三步：复跑一次，判断是否"偶发"。如果复跑通过，基本可以确认是稳定性问题。我建立了一个规则：同一个用例连续跑三次，只要有两次通过，就视为"环境问题"，进入稳定化治理流程，而不是直接改代码。

4.2 用"可重试的断言"替代 fixed sleep

治理环境干扰最有效的第一步，是把断言全部改成"自动等待"模式。我见过太多人在代码里写page.waitForTimeout(2000)，这几乎是稳定性的头号杀手。sleep 的问题在于：你等 2 秒，可能只需要 300ms，白白浪费 1.7 秒；但遇到机器负载高的时候，2 秒又不够，该失败还是失败。

正确的做法是断言"事件"而不是"时间"。Playwright 内置的expect(locator).toBeVisible()和expect(locator).toHaveText()会自动重试等待，这是我从 Selenium 迁移到 Playwright 后感受到的最大质变。

// 不要这样做 await page.waitForTimeout(3000); expect(await page.locator('.success-tip').isVisible()).toBeTruthy(); // 要这样做 await expect(page.locator('.success-tip')).toBeVisible({ timeout: 10000 });

两者差别巨大：前者是"死等 3 秒再看一眼"，后者是"每 100ms 检查一次，最长等 10 秒"。不仅稳定性提升，执行速度反而更快——因为通常 300ms 就通过断言了，根本不用等 3 秒。

对于状态流转类断言，也有一个进阶技巧：不用 UI 元素去等，而是等"业务结果"出现。比如等订单状态变成 "paid"，与其等页面元素，不如轮询接口：

async function waitForOrderStatus(orderId: string, status: string, timeout = 15000) { const start = Date.now(); while (Date.now() - start < timeout) { const res = await fetch(`/api/order/${orderId}`); const data = await res.json(); if (data.status === status) return true; await new Promise(r => setTimeout(r, 500)); } return false; } expect(await waitForOrderStatus(orderId, 'paid')).toBeTruthy();

这里等的不再是"界面上出现什么"，而是"系统真实状态变成什么"，稳定性会大幅提升。

4.3 测试数据隔离与清理的三板斧

E2E 用例跑多了以后，数据库就是一个大染缸。用户名重复、手机号重复、优惠券被重复领取、SKU 库存一个用例用完没了——这些都是数据不隔离的锅。我治理数据问题的三板斧：

第一板斧：每个用例独享数据前缀。我在data/users.json里规定所有测试账号的邮箱都要带上用例特征，比如order_flow_auth_001@test.com。数据库唯一索引不会冲突，就算并发跑也不会互相抢账号。

第二板斧：API 方式创建前置数据，而不是 UI 一步步点出来。很多用例在前面准备阶段就用了大量时间：注册用户、创建收货地址、申请优惠券。这些操作如果用 UI 来完成，一方面耗时，另一方面把简单问题复杂化。我更推荐通过 API 快速创建前置数据，UI 留出时间专注验证核心链路。

// 前置：直接调 API 创建测试用户和默认地址 const userRes = await request.post('/api/test/user', { data: { email: 'order_flow_auth_001@test.com', address: '北京市朝阳区xx路1号' } }); const userId = (await userRes.json()).data.user_id;

这里可能有人会问：那不是绕过了 UI 吗？没错，但我这测试的是"下单链路"，用户注册和地址管理另有专门的用例去覆盖，不是省掉了，而是分工了。

第三板斧：afterEach 清理，必要时直接 SQL 删除。每个用例跑完，无论通过与否，都执行清理逻辑，把创建过的用户、订单、优惠券删掉。注意这里有一个 order：必须先清理子表，再清理主表，否则外键约束会阻止删除。实际执行顺序我一般先删订单明细，再删订单，再删用户地址，最后删用户。

test.afterEach(async ({ request }) => { await request.delete(`/api/test/user/${userId}`); // 后端只删非核心业务数据 await db.query('DELETE FROM order_item WHERE order_id IN (SELECT id FROM `order` WHERE user_id = $1)', [userId]); await db.query('DELETE FROM `order` WHERE user_id = $1', [userId]); await db.query('DELETE FROM user_address WHERE user_id = $1', [userId]); await db.query('DELETE FROM user WHERE id = $1', [userId]); });

4.4 一次真实排查：偶发抖动的根因是"共用测试账号"

最后分享一次我印象特别深的排查过程，这正是验证上面这套方法论价值的关键案例。

那段时间 CI 上有一个用例"优惠券全场满减下单"每周总会红一两次，红得毫无规律。一开始我按照老办法加了重试，重试后通过率恢复到 99%，我也就没深究。直到有一天连续红了三次，重试也救不回来，我才飞进 trace 里去查。

trace 显示：下单页点击"选择优惠券"后，弹窗里出现的优惠券列表里，有一张"满 100 减 20"的券，但点击选中的时候提示"优惠券已被使用"。我第一反应是后端 bug：券状态和领取状态不一致？于是去查数据库，发现这张券的status确实是used，但领取记录里只有一个用户。

然后我顺手查了所有领取了这张券的用例数据，终于发现了：测试账号coupon_user_shared@test.com被两个不同的 spec 文件共用了。一个用例是"领券后立即下单"，另一个是"领券后取消订单再重新下单"。两个用例并发执行的时候，后一个用例刚领完券还没下单，前一个用例就把它领取的那张券给用掉了，等到后一个用例去下单，券已经没了。

根因不是代码 bug，也不是测试框架的问题，而是我偷懒复用了测试账号。修复方案也简单：给两个用例分别建专属账号，保证优惠券数据源完全隔离。从那之后，这个用例再也没红过。

这个教训让我养成一个习惯：任何一个 E2E 用例，账号独立、数据独立、清理彻底，是稳定性的底线，没有商量的余地。

5. 并行提速与诊断：从半小时压到 8 分钟的实战提效

E2E 测试一直被诟病的一个点就是慢。以前我们全量回归要跑一个多小时，开发等得没耐心，CI 排队排到天荒地老。后来我花了两周做了几件提速的事，把全量跑完的时间压到了 8 分钟左右。这里把核心思路分享出来。

5.1 并行执行：多 worker 跑起来之后的数据隔离

Playwright 本身就支持多 worker 并发执行，默认就会用满 CPU 核心。但有一个前提条件：用例之间不能共享可变状态。如果两个用例共用一个测试账号，或者共用一张优惠券，并发起来就是一个灾难现场。

我上面提到的"每个用例独立账号、独立数据"的做法，正是为并行执行打的基础。当我保证数据完全隔离之后，直接把workers从 1 调到 4，执行时间几乎线性下降。

// config/playwright.config.ts export default defineConfig({ fullyParallel: true, workers: process.env.CI ? 4 : 2, ... });

给两个具体的建议：

• 把"冒烟用例"和"全量回归用例"分开跑。冒烟用例控制在 10 条以内，覆盖登录、首页、核心提交按钮即可，每次代码合并前跑冒烟，5 分钟内出结果；每天凌晨再跑全量回归。
• 按链路分组配置不同的重试策略。冒烟用例不重试，因为你要的是快速反馈；全量回归允许重试 1 次，用来对抗偶发环境问题。

5.2 trace 与视频回放：让失败用例"自带作案录像"

提速之后，新的挑战来了：用例跑得快了，失败排查压力反而更大了。8 分钟跑完 200 条用例，如果其中 10 条失败，你要快速定位每一条的失败原因是环境问题还是真实 bug。

Playwright 的 trace 功能在这里帮了大忙。我配置了"失败时自动录制 trace"，只要用例挂了，trace 文件都会自动保留；没有挂的用例，trace 直接丢弃，不占存储。

export default defineConfig({ use: { trace: { mode: 'retain-on-failure', }, video: 'retain-on-failure', screenshot: 'only-on-failure', }, });

排查失败用例时，我的标准流程是：

1. 打开 trace 查看器，找到失败步骤之前用户的完整操作路径
2. 对比"预期操作"和"实际操作"的差异，判断是环境跳变还是代码改动
3. 查看网络请求面板，看失败前最后几个 API 的状态码和响应体
4. 如果 API 正常，再打开数据库查询对应的业务数据

这个流程基本上把 E2E 失败排查时间从平均每人 40 分钟压缩到了 10 分钟以内。开发人员也不再对着报错日志干瞪眼，直接丢一个 trace 文件链接过来，什么问题一目了然。

5.3 提速还少不了的部分：测试环境的性能基准

提效的最后一步，是给测试环境定一个"性能门禁"。为什么？

E2E 测试的稳定性高度依赖环境性能。如果测试环境的数据库突然变慢，或者自动化测试跑的时候恰好有开发同学在压测，用例超时失败的假象就会满天飞。我建了一个简单的"环境健康检查"脚本，每次跑 E2E 之前先跑一遍：

test('environment health check', async ({ request }) => { const healthRes = await request.get('/api/health'); expect(healthRes.ok()).toBeTruthy(); // 简单测一下关键接口的响应时间 const perfRes = await request.get('/api/ping'); const duration = await perfRes.timing(); expect(duration).toBeLessThan(1000); // 超过 1s 就报警 });

这看起来多了一步多余的检查，实际上排队等着跑 E2E 的时候，环境健康和不健康的体验天差地别。环境不健康时，E2E 全面飘红，你根本不知道是应用坏了还是基建崩了，浪费的时间远大于这 2 秒钟。

6. 从回归测试走向线上巡检：E2E 的使用边界与扩展玩法

E2E 测试做到后期，有一个问题一定会出现：测试环境全绿，但线上出了事故。于是我开始思考一个问题：能不能让 E2E 用例直接跑在生产环境，做线上巡检？

6.1 核心链路巡检：让 E2E 变成 7x24 的哨兵

这个思路现在已经在我们团队落地了。做法是挑出最核心的 5 条链路——登录、首页渲染、搜索、商品详情、提交订单（不支付），每 15 分钟在生产环境跑一遍。

和生产环境跑 E2E 有三个地方必须特别注意：

第一，绝对不能用真实用户数据。巡检用例全部使用独立的测试账号，这些账号在线上创建的时候就会被特殊标记，不会进入正常的用户分析统计，也就不会污染业务数据。订单类巡检统一在"提交订单"前中止，不产生真实支付。

第二，数据库校验在生产上不可行。生产库一般没有权限放开给测试框架。所以线上巡检的断言以"API 响应"和"页面结果展示"为准。比如订单提交成功，就断言接口返回order_no且页面出现"订单提交成功"的提示。

第三，要设置独立的报警渠道。线上巡检发现的失败不等同于 CI 上的坏代码，它很多时候是线上故障的"哨兵"。我把线上巡检失败的消息单独接入告警群，失败后按照 P1 故障处理流程去响应。

落地这个方案之后，我们团队连续抓到过两次线上问题：一次是数据库连接池被打满，巡检用例登录超时，比监控告警提前 15 分钟发现；另一次是 CDN 配置错误导致静态资源大面积加载失败，巡检用例在首页渲染阶段就红了。

6.2 什么时候该砍掉 E2E 用例

讲完怎么加，我也想讲讲怎么减。E2E 不是越多越好，我现在对用例的留存有非常明确的评判标准，只要满足以下任意一条，就果断删掉：

• 三个月内从未失败的用例：说明它覆盖的链路极其稳定，稳定到已经失去了"验证"的意义。当然，三个月没失败也可能是因为链路没被改动过，这种情况我会把它降级为"定期巡检用例"，而不是在 CI 里每次都跑。
• 失败的根因 80% 都是环境问题：说明这条用例的断言方式有缺陷，它的失败不能反映功能问题。与其反复重试浪费时间，不如重新设计断言逻辑。
• 和另一条用例重复度超过 70%：两条用例只有细微的交互差异，覆盖的底层数据流几乎一样。保留一条"主链路最全"的，另外的删掉。
• 维护成本远高于能发现的缺陷数量：这是我比较"现实"的一条判断标准。E2E 是手段不是目的，如果一条用例每天都要修一次等待问题，而它真正拦截过的线上故障为零，那它就是在消耗团队效率，应该被优化而不是被供奉。

这里我想强调一个观念：E2E 测试的价值不是用例数量，而是"风险覆盖率"。一条覆盖登录到支付全链路的用例，顶得上 20 条只看页面上某个按钮是否显示的"伪 E2E"。

最后再分享一点离开团队之后我还在坚持的实践。我始终把 E2E 测试视为"系统的神经系统"，它不只是为了抓 bug，更是在强迫你以用户视角审视自己做的系统。每次写用例的时候我都会自问：如果我是第一次用这个产品的用户，我接下来会点什么？这个问题常常把我自己问住，也让一条简单的自动化测试变成了一次深度的产品复盘。

写 E2E 终究是在写"对产品最核心体验的守护清单"。你花在这一条用例上的每一分钟，都会在某个深夜线上故障时以倍数回报给你。