企业官网建设流程全解析

我知道很多人一听到 e2e（End-to-End，端到端）测试，第一反应就是“那玩意儿跑一次要半天，还动不动就挂”。这话说对了一半，我做了五六年测试基础设施，自己维护过的端到端用例少说也有上千条，见过太多团队把 e2e 当成“上线前的玄学仪式”——跑过了就松口气，挂了就点重试。但如果你真的把 e2e 这层测试用对地方，它能给你省下的时间，绝对比你花在维护它上面的时间多一个数量级。

这篇文章我不想跟你掰扯教科书上的定义，我只讲我在实际项目里怎么设计、怎么落地、怎么把 e2e 跑稳的。从边界划分、工程选型、profile 配置，到 flaky 用例的完整排查链路，全是我自己摔过跟头之后总结的东西。不管你是刚接触测试的新人，还是正在被一堆不稳定的 e2e 用例折磨的测试开发，都应该能从里面找到点能直接抄作业的东西。

1. e2e 测试的边界：它到底在验证什么，不该验证什么

1.1 为什么系统里必须有这层“模拟用户”的测试

很多团队其实搞不清楚一件事：单测、接口测试、e2e 测试，到底边界在哪。单测验证的是“我这个函数输入 A 是不是返回 B”，接口测试验证的是“我这个接口在给定参数下响应正不正确”。这两层都很有价值，但它们有一个共同的盲区——它们都不关心用户真正是怎么用这个系统的。

用户不会按函数来操作，也不会直接拿 Postman 去调你的接口。用户是打开页面，点按钮，填表单，等反馈，这一连串动作涉及前端、后端、数据库、第三方服务，任何一个环节出现问题，用户感知到的就是“这东西坏了”。

e2e 测试的价值就在于，它在最接近真实用户的位置上，把整条链路完整地走一遍。它能发现你接口测试永远发现不了的问题，比如：前端把后端返回的字段拼错了、某个接口联调时参数名对不上、权限控制在界面上压根没生效、异步渲染导致按钮还没出现就被点了。

我这里有个实际例子。之前有个订单系统，单测覆盖率很高，接口测试也全绿，结果每次上线后都会收到用户反馈说“下单后看不到订单记录”。后来我写了条 e2e 用例，模拟用户从选商品到提交订单再到查看订单列表的全流程，第一次跑就红了——前端在提交订单后跳转详情页时，把后端返回的orderId和order_id两个字段搞混了，详情页一直拿不到数据。这种问题，单测和接口测试就算测一万遍也测不出来。

1.2 什么该进 e2e，什么不该进 e2e

但 e2e 不是万能的，更不是越大越好。我见过最离谱的团队，把报表导出这种要跑 2 分多钟的用例也塞进 e2e 回归集里，理由是“用户确实会这么操作”。用户确实会，但你的 CI 扛不住，稍微有点网络抖动整个流水线就黄了。

根据我自己的经验，放进 e2e 的用例必须满足两个条件：一是路径价值高，要么是核心业务流程，要么是高频用户路径，要么是发生过线上事故的路径；二是结果可以明确断言，用户能看到某种状态变化，能验证业务结果，而不是“操作完没报错就行”。

而这几类东西，我劝你别往 e2e 里塞：

• 纯样式问题：颜色、间距、字体大小，这是视觉回归测试的活，e2e 管不了也管不好。
• 可以低成本用接口测试覆盖的场景：比如某个纯后端逻辑的校验规则，调用接口测比从 UI 点进去快得多，也稳得多。
• 低频且耗时的管理端操作：比如导出全年报表、批量导入几万条数据。这类操作往往涉及大数据量和长任务，放在 e2e 里只会让你的流水线又慢又脆。
• 需要外部真实服务参与的完整流程：比如真实支付、真实短信发送。这种场景应该用 mock 或者测试桩替代，否则早晚会被外部依赖坑死。

还有一条很重要的原则：e2e 用例要尽量端到端，但断言要尽量前置。意思是流程可以走得很长，但你的每个中间步骤都要有明确的断言，而不是等最后一步才去验证。这样用例挂了你一眼就能看出来是哪个环节出了问题。

1.3 换个角度看测试金字塔：贴近用户，而不是堆数量

传统的测试金字塔告诉你：底层单测要多，中间接口测试次之，顶层 UI 测试要少。这个比例的初衷是为了控制成本，但它容易让团队误以为“e2e 用例越少越好”。我自己的看法是，e2e 用例的数量不是取决于你认为它“应该有多少”，而是取决于你的核心业务流程有多少条。

我习惯在项目里做这么一件事：先画一张业务全景图，把用户会在系统里做的所有有价值的事情列出来，然后标出哪些是核心链路、哪些是高频操作、哪些历史上出过事故。这些加在一起就是你的 e2e 基线，每条链路至少对应一条正向用例。至于那些边缘逻辑、异常分支、兼容性场景，该放接口测试就放接口测试，该放单测就放单测，别贪多。

说白了，e2e 这层测试的价值定位从来不是“覆盖率”，而是“安全感”——你用它来兜住那些最容易影响用户的核心路径，用它来守住每次发版“用户最常用的功能没坏”这条底线。

2. 一套能落地的 e2e 工程长什么样：选型、结构与 profile 设计

2.1 工具选型别只看人气：我为什么最终选了 Playwright

每次有人问我 e2e 用什么工具，我都说：先看你们团队的编程语言偏好，再看项目复杂度，最后才看工具的生态。三大主流工具我都用过，说下最真实的感受：

• Selenium：老牌工具，生态成熟，但它把太多的底层细节暴露给你，等待策略、浏览器驱动、元素定位全要自己处理，写出来的用例又长又脆。除非你的团队有很强的封装能力，否则我不推荐新项目从它起步。
• Cypress：对前端开发者非常友好，调试体验好，自动等待也做得很省心。但它的架构决定了它只能在浏览器进程里跑，跨域场景和多浏览器支持上有些限制，而且它不支持多标签页的真实场景。
• Playwright：这是我现在的主力工具。它对现代 Web 的适配做得最到位，默认的自动等待逻辑非常智能，能自动等待元素可交互、网络空闲、页面加载完成，还内置了 Trace Viewer、自动截图、视频录制、跨浏览器支持，最关键的是它支持多上下文并发测试，跑起来速度是真的快。

我这不是在给你种草，工具这东西没有绝对的好坏，只有合不合适。如果你们的业务大量依赖 iframe 或跨域，Cypress 用起来会想哭；如果你们需要覆盖真实的多浏览器环境，Playwright 是比另外两个省事得多的选择。我自己选 Playwright，就是看中了它对“真实用户路径”的还原能力，以及它把过筛、重试、追踪这些烦心事都内置了。

2.2 目录与命名：把测试用例当项目文档来写

一套 e2e 工程能不能长期让人愿意维护，目录结构起着决定性作用。废话不多说，我放一个我平时比较推荐的目录结构：

e2e/ ├── config/ # 配置文件和解耦的静态数据 │ ├── profiles/ # 各类 profile 的配置（profile1、profile2...） │ ├── base.config.ts # 基础配置，如超时时间、重试次数、并行分片 │ └── constants.ts # 全局常量，如默认账号、公共测试数据 ├── fixtures/ # 测试固件，比如登录态、数据准备、mock 规则 ├── pages/ # Page Object 层，封装页面元素和操作 │ ├── login.page.ts │ ├── order.page.ts │ └── ... ├── tests/ # 测试用例层 │ ├── auth/ │ ├── order/ │ └── payment/ ├── utils/ # 工具函数，如随机数据生成、时间处理、浏览器诊断 ├── reports/ # 测试报告和垃圾数据清理脚本 └── global-setup.ts # 全局前置与后置处理

这套结构的核心思路是把“测试用例”和“测试实现”拆开。pages/目录里是你对页面操作的封装，tests/目录里才是真正描述业务场景的用例。这样当你写一条新用例的时候，大部分工作是在组合已有的页面操作，而不是重新去定位一堆元素。

命名约定上我也有一条规矩：用例的名字必须是一个完整的业务描述，而不是一个功能名称。比如，不要写“订单-列表-正常”，要写“用户登录后，可以从订单列表进入详情页并看到支付倒计时”。这样即使某条用例挂了很多天没人修，别人看一眼名字就能猜到它在测什么，而不是点进去猜代码。

2.3 profile 设计：一套测试代码，跑通所有环境

这就是和你提供的热词最相关的一个点了——e2e profile1。我在实际工程里，“e2e profile1”是我非常常用的一个概念：profile 就是一组预置的配置参数，定义了测试要在什么环境、用什么账号、以什么业务身份、开哪些特性开关去运行。简单说，就是用同一个测试代码库，通过不同的 profile 切到不同的运行场景。

我举个例子。我的项目里有三套环境，本地开发环境、预发布环境、生产环境，它们的域名、数据库、权限策略都不一样。如果我在代码里写死baseURL和账号密码，那么换一套环境跑就得改一次代码，改错了就出乱子。而 profile 的解决方式是这样：

// config/profiles/profile1.config.ts export const profile1 = { name: "profile1", env: "staging", baseURL: "https://staging.example.com", testUsers: { admin: { username: "e2e_admin", password: "xxxx" }, customer: { username: "e2e_customer", password: "xxxx" }, }, features: { orderTracking: true, newPaymentGateway: false, }, viewport: { width: 1440, height: 900 }, locale: "zh-CN", };

然后你可以在运行命令里指定用哪个 profile：

# 预发布环境回归 npx playwright test --config=playwright.profile1.config.ts # 生产环境冒烟 npx playwright test --config=playwright.profile2.config.ts

你不要小看这个设计，它解决的不只是环境切换的问题，它还在解决多角色权限验证的问题。我的 profile 里通常会带好几组内置账号，管理员、普通用户、只读用户、无权限用户，每组账号对应一组不同的预期行为。比如 profile1 是“普通用户视角 + 开启订单追踪 + 未支付订单保护”，profile2 是“管理后台视角 + 关闭促销弹窗”。测试代码只需要关心业务行为，不需要关系账号绑定，profile 已经帮你把上下文准备好了。

我一直觉得，一个 e2e 工程如果没做好 profile 分层，那它一定会在某个阶段面临“一份代码改来改去就是为了适配不同环境”的痛苦。提前把这个抽象做好，后面接 CI、接生产巡检，你都会轻松很多。

2.4 第一条原生 e2e 用例：不止是点一遍

我下面用 Playwright 写一条最典型的登录后下单用例，你可以看到我在判断“用例到底该怎么写”时的思路。这里不是给你贴语法，而是展示断言怎么设计、等待怎么处理、失败怎么保留现场。

import { test, expect } from "@playwright/test"; import { LoginPage } from "../pages/login.page"; import { ProductPage } from "../pages/product.page"; test.describe("下单主流程", () => { test.use({ storageState: "fixtures/admin-state.json" }); // 复用登录态，避免每条用例都走登录 test("profile1 场景：用户将商品加入购物车并完成下单", async ({ page }) => { const productPage = new ProductPage(page); await productPage.goto("/product/1001"); await expect(productPage.addToCartButton).toBeEnabled(); await productPage.addToCart(); await productPage.gotoCart(); await expect(productPage.cartItem).toContainText("无线耳机"); await productPage.checkout(); await expect(page).toHaveURL(/\/order\/confirm/); await productPage.submitOrder(); await expect(page.getByText("订单提交成功")).toBeVisible(); await expect(page).toHaveURL(/\/order\/\d+\/detail/); }); });

这个用例有几个设计细节值得说。第一，登录态通过storageState复用，不跑真实登录流程，稳定性和速度都大幅提升。第二，断言是分布式的，加购后验证购物车内容，提交后验证成功提示和 URL 变化。第三，URL 用正则去匹配动态的订单号，而不是死等一个固定值。

不过我这里要提醒一点：e2e 的 UI 断言不应该只断言“元素出现了”，而应该尽量断言“业务状态变了”。比如刚才“订单提交成功”这个提示，它只能说明前端反馈正常，不代表后端真的创建了订单。严谨一点的做法是等请求返回后，再通过接口或者数据库直接验证订单号存在。当然，这类验证会导致用例耦合后端细节，你需要根据项目情况去平衡。

3. 稳定压倒一切：flaky 用例的根因分析和完整排查链路

3.1 一夜跑挂三个用例，我最常看见的是这几类原因

说实话，一个 e2e 工程活得久不久，看的不是用例多不多，而是动不动机器“黄”。我见过上百条用例可以连续几周全绿的团队，也见过十几条用例天天随机挂一条的团队，两者最大差别就是对待稳定性问题的态度。

根据我的经验，e2e 用例 flaky（不稳定）通常逃不出这几类原因：

1. 等待策略有问题：这是最常见的一种。前端渲染是异步的，你点完按钮以为请求已经发出去，实际上浏览器才刚开始执行回调。如果你代码里的等待方式是睡死等几个sleep(3000)，那状态一波动就挂。
2. 测试数据互相污染：两条用例用了同一个账号、同一个手机号、同一张优惠券，先跑的那条已经把数据状态改了，后跑的那条摔得莫名其妙。
3. 接口响应时序不确定：前端发了好几个请求，他们的返回顺序是不确定的。如果用例断言“某个元素已经变成 A”，但此时另一个请求回来又把界面刷成了 B，用例就会随机失败。
4. 外部服务和环境不稳定：依赖了真实的第三方登录、真实短信、真实支付回调。这些服务一抖动，你的用例就跟着挂。

3.2 一次真实的 flaky 排查过程：别急着加 retry

有一次我们的 CI 上有一条“用户上传头像并修改昵称”的用例，一周至少挂三次，而且挂的时间完全随缘。一开始大家的反应是先加个 retry 机制，挂三次就自动重试。retry 是止痛药，能让你暂时不疼，但病根还在那儿，而且它还掩盖了问题的严重性。

我没有急着改，而是做了一次完整的排查。我先去看这条用例挂的时候 Playwright 自动截的截图和录屏。从截图里可以看到，页面停留在上传成功后的弹窗上，但原本应该出现在右上角昵称栏里的新昵称没有更新。随后我打开 Playwright 的 Trace Viewer，把那次失败前后的网络请求全部看了一遍，发现了一个很关键的细节：前端在用户上传头像后，发出了两个并发的请求，一个是POST /upload/avatar，一个是PUT /user/profile。正常情况下这两个请求都能成功，但偶尔PUT /user/profile返回的时间会晚于页面重新渲染的时间，也就是界面先根据本地缓存把昵称渲染出来了，然后接口请求才完成，导致前端又把这个昵称刷回了旧值。

这个问题的根子其实在前端代码的竞态条件，不是 e2e 用例写错了。但站在测试角度，我需要的是“让这个用例稳定地发现这个问题”，而不是“让用例绕开这个问题”。当时的处理是：减少用例对不可控的接口时序的依赖，在断言前先等待PUT /user/profile的网络响应完成，再去断言昵称。代码里可以这样处理：

// 等待关键请求完成，再断言 UI 状态 const [response] = await Promise.all([ page.waitForResponse((resp) => resp.url().includes("/user/profile")), page.getByRole("button", { name: "保存" }).click(), ]); expect(response.status()).toBe(200); await expect(page.getByText("新昵称")).toBeVisible();

用waitForResponse去等待你关心的请求完成，比sleep或者单纯等元素出现要可靠得多。因为这个用例要验证的真正业务点是“修改资料成功”，而不是“点击保存按钮后有反应”。

3.3 让用例天生稳定的几条工程手段

除了排查单个用例，我们还可以在写用例和搭框架时就注入稳定性。以下几件事是我在新建 e2e 工程时一定会做的：

• 数据隔离：每个用例必须用自己能控制的数据，不要用全局共享的账号。我的做法是给每个测试用例随机生成用户标识，跑完后再通过接口清理数据。垃圾数据清理脚本必须和用例一起维护，否则你的测试环境很快就变成一团乱麻。
• 幂等设计：用例尽量设计成可以重复执行且结果一致。比如“创建订单”这类操作，如果创建时不能保证唯一性，就不要在断言里写死订单编号。
• 尽量少的共享状态：用同一个 test user 没关系，但要确保它在用例执行期间不被修改。跨用例的数据依赖是 flaky 的头号来源，我宁愿牺牲一点速度，也要保证每一条用例的可独立运行性。
• 不要依赖定时任务：如果某个功能依赖一个跑在深夜的批处理任务，那么你在白天跑 e2e 时很可能因为数据没准备好而挂。这种情况你该做的是提供测试数据的预置入口，而不是等真实任务跑完。

还有一条我要特别强调：retry 机制可以保留，但必须配合失败现场的完整保留。Playwright 默认会给失败的用例生成截图、录像和 trace，我在全局配置里会把这些全开，并且把 trace 保存策略设为“retain-on-failure”。这样即使某条用例挂了，我也能在 CI 上直接把当时的浏览器操作轨迹完整回放。这比一个人对着一条报错输出猜半天要高效得多。

4. 接进 CI/CD：e2e 的运行节奏和成本控制

4.1 触发策略怎么定：别让全量回归成为每次提交的标配

我见过很多团队的做法是“把 e2e 挂在流水线上，每次有人提交代码就全量跑一遍”，然后无一例外地走向两个结局：要么流水线慢到成了团队效率瓶颈，要么用例挂太多直接被大家无视。

合理的触发策略我建议按三个级别来分：

1. 冒烟集：核心十几条用例，在每次 PR 创建或者代码合并到主干时跑。它们的体量小、速度快，主要用来快速发现“我这次改动是不是把主链路搞坏了”。注意冒烟集不能是随机抽的，它必须是你们线上事故率最高的那几条路径。
2. 回归集：几百条用例的完整回归，建议在合并到可发布分支、或者每次预发布打包时定时跑。它的耗时会长一些，但不要因为长就跳过，这里的用例覆盖的都是核心业务流程。
3. 夜间全量：把所有环境、所有 profile、所有浏览器组合都跑一遍，放在夜间任务里。即使是夜间跑挂了，第二天早上看一眼报告也能及时修掉。

我自己的做法是在主干推送后触发冒烟集，然后预发布环境部署完成后触发全量回归，生产环境则每个月做一次全链路巡检。这样做的好处是不把成本压到每次提交上，又能保证每个阶段的 e2e 风险被及时暴露。

4.2 并行分片：从“跑一次 40 分钟”到“跑一次 8 分钟”

e2e 用例跑得慢是另一个劝退点。很多团队几十条用例串行跑，等半天出结果，这种体验确实不友好。其实并行化并不难，核心思路就是分片（shard）。

Playwright 原生支持--shard参数，可以将测试用例平均分配到多个并发 runner 上。GitHub Actions 或者 Jenkins 里开五个并行 job，每条 job 跑 1/5 的用例，总耗时就缩减到了原来的五分之一。示例配置：

strategy: matrix: shardIndex: [1, 2, 3, 4, 5] shardTotal: [5] steps: - name: Run Playwright tests run: npx playwright test --shard=${{ matrix.shardIndex }}/${{ matrix.shardTotal }}

这里有个前提，你的用例之间不能有共享数据的冲突。如果两条用例同时用同一个账号操作同一个订单，并行后会出现“数据被抢”的随机挂。所以我在前一节反复强调的数据隔离，在这里就体现出了价值——并行化的可行性和测试数据的独立性是强绑定的。

另外说一个容易被忽略的点：跑 e2e 的机器环境必须干净可控。我碰到过本地一直通过、CI 一直挂的情况，后来发现是 CI 上装的浏览器缺了系统依赖，有些页面字体和动画表现和本地不一致。所以我在 CI 里放弃了系统自带的 Chrome，改用 Playwright 自己捆绑的 Chromium，并且固定版本，这样前后端环境完全一致，问题一下少了很多。

4.3 反馈链路：失败用例要让人三分钟内定位到问题

e2e 测试失败后最怕的是一座沉默的黑箱。我要求团队搭这样一套反馈机制：

• 失败通知一定要自动发——推到即时通讯群里，带上用例名、失败摘要、日志链接。
• 失败现场要有溯源能力——使用 Playwright 的 HTML Report 和 Trace Viewer，让你能直接看到失败用例的录屏、网络瀑布流和控制台报错。
• 失败信息要按优先级排序——先展示核心链路的失败，再展示一般性失败，这样看报告的同事不会被无关信息淹没。

还有一个我自己的小习惯：把每次失败的截图和 trace 文件命名里带上时间戳和环境标记，这样事后想复盘某天的偶发问题时，直接按时间去找现场就行。这个习惯帮我复盘过好几次“昨晚看还是好的，今天怎么就挂了”的灵异事件。

5. 写在最后：关于 e2e 我留下的几条真话

说了这么多，其实我最想告诉你的是：e2e 测试不是一个工具、一套脚本，它是一套你对自己系统核心路径的保护机制。工具只解决了“怎么跑”，真正决定它是你的护城河还是你的累赘的，是你对用例边界的划分、对稳定性的执着和对反馈效率的追求。

我在实际维护 e2e 的过程中还有一条很小的经验：不要追求 100% 的用例通过率，而是追求“每次失败都有明确的原因记录”。如果你能把每次失败都归档成一个可复现、可解释的现象，那么你的 e2e 套件就是在真实地保护业务。反过来，如果几条用例已经挂了很久没人修，你又不舍得删，那它们只会成为团队的信任毒药——大家会默认“e2e 挂是正常的”，于是它连发现问题的能力都丢了。

好了，关于 e2e 我能想到要叮嘱的差不多就是这些。如果你手头也有一套动不动就挂的 e2e，我建议你先从 profile 分层和数据隔离开始改，把最容易引发随机的因素一个一个拔掉，再谈用例质量和覆盖面。等你把它跑稳了，你会发现自己是真的能松口气——至少发版前，不用再靠运气了。