企业官网建设流程全解析

端到端测试又红了。凌晨两点，群里弹出一条消息：“e2e 挂了，谁看下？”我见过太多次这种场面。单测全绿，接口测试也全绿，但线上还是出了问题——原因往往是服务与服务之间的对接、前端与后端之间的联调，在某个边界处悄悄断了。这个时候，e2e 就是那个能替你提前踩中雷的哨兵。

很多团队对 e2e 的情绪很复杂：一边承认它最接近真实用户，一边又被它的脆弱性折磨得头疼。跑一次半小时，偶尔因为一个弹窗时机不对就挂给你看，稳定性差的时候没人敢信它。但我始终觉得，e2e 的问题从来不是“要不要做”，而是“怎么做才能不脆”。今天我围绕 e2e 这个主题，把我在多个项目里沉淀下来的设计思路、踩坑记录和实操骨架一次讲清楚，尤其想聊聊“e2e profile1”这个实践——也就是从第一套主流程场景档案开始，如何把端到端测试做得既快又稳。这篇文章适合正在搭 e2e 体系、或者已经被 e2e 稳定性折腾到怀疑人生的测试开发、全栈工程师和前端同学。

1. 先搞明白 e2e 到底在测什么

1.1 从一次“全绿但线上炸了”的复盘说起

几年前我在一个电商类项目里经历过一件特别典型的事。单测覆盖了核心工具函数，接口测试覆盖了所有 REST API，CI 全线飘绿，大家信心满满地发了版本。结果上线当晚，用户在下单时发现购物车里的商品突然消失。查到最后，问题出在前端调用购物车接口时传错了用户维度参数，后端接口本身是正常的，单元测试测的也是后端逻辑，接口测试用的又是固定参数，所以整条链路上的这个问题根本没被测出来。

那次复盘让我彻底想明白一件事：测试金字塔里那些低层的测试，验证的是“零件质量”，但用户不关心零件，用户关心的是“整台机器能不能干活”。e2e 端到端测试，就是站在用户视角，从打开页面、点击按钮、填写表单，到数据落库、页面跳转、返回结果，完完整整走一遍真实业务路径。它能发现的不只是某个函数写错了，而是“模块之间配合错了”“环节之间衔接错了”——这类问题恰恰是线上故障最高发的区域。

1.2 拆开 e2e 两个字母，背后其实是三层闭环

很多人以为“端到端”就是把前端流程点一遍，其实不够。真正有意义的 e2e，至少要做到三层闭环。

第一层是用户流闭环。测试必须模拟一个真实用户的完整操作，从入口开始，经过若干中间步骤，最后到达业务终点。比如一个注册流程，不是打开注册页截个图就完事，而是要填手机号、收验证码、设置密码、提交、看到成功页，再从登录页走一遍登录。中间少一个环节，这个用例的价值就打折了一半。

第二层是环境闭环。你的浏览器操作要能打通真实部署的前端服务、后端服务、数据库乃至第三方依赖。如果前端调的是 mock 接口，那测的其实还是前端自己的逻辑，算不上真正意义上的端到端。很多团队 e2e 稳定性差，根因在于环境封闭性不够，测试环境里套着 mock、套着桩，跑起来是绿的，但那个绿和真实链路没什么关系。

第三层是数据闭环。业务状态会在链路里发生变化：下单后库存减少，支付后订单状态流转，这些状态变化应当被后续步骤感知到。一个合格的 e2e 用例，断言的通常不是“页面显示了什么”，而是“业务数据变成了什么”——页面 UI 只是表现，数据状态才是业务真相。

这就像验收一套新装的厨房。只看单块瓷砖贴得平不平、水龙头出不出水，都不算数；你得真做一顿饭，开火、倒油、洗菜、排水，全流程走一遍，才知道台面高度顺不顺手、动线合不合理。e2e 就是这顿“真饭”。

1.3 为什么每个团队对它又爱又恨

先说爱的部分。e2e 是反馈速度最接近用户感受的自动化手段，一旦它通过，你基本可以拍着胸脯说“这条业务路径是通的”。它还是很好的回归防线，重构代码时，低层测试可能全过了，但页面结构变了、交互时序变了，只有 e2e 能兜住这些“隐性破坏”。

恨的部分也很具体。第一是慢，一条完整链路动辄几十秒，几十条用例跑下来就是半小时起步。第二是脆，前端场景里充满了异步渲染、动画延迟、接口抖动，任何一点时序波动都可能把用例击穿。第三是烦，测试数据管理、账号登录态、环境隔离这些杂活会消耗大量精力。

这三点如果不解决，e2e 最终会沦为 CI 里的一个摆设。我见过不少项目，e2e 测试跑得稀烂，大家慢慢地就不再关注它的结果，出现了所谓的“红着红着就习惯了”的恶性循环。要跳出这个循环，关键不在增加用例数量，而在把每一套用例当成一个有设计的“场景档案”来经营。这也是后面要重点讲的 profile 思路的出发点。

2. e2e 不是堆脚本，是设计一套“场景档案”

2.1 为什么“脚本思维”会让 e2e 越来越难维护

早期我自己也犯过这个毛病：把 e2e 当成录脚本的活，录完回放，断言一加就算完事。等到页面改版，脚本全军覆没，修到怀疑人生。

后来我意识到，e2e 的测试对象不是一个线性操作序列，而是一个带着角色、目标、数据、环境约束的“业务场景”。同样一个下单功能，新用户和黑名单用户走的是完全不同的路径，移动端和桌面端的布局也不同。如果只是机械地录操作，脚本会写成一大坨 if else，根本无法维护。

所以后来我养成了一个习惯：把每一套 e2e 测试组织成一个 profile，也就是一份完整的“场景档案”。它不只包含操作步骤，还包含用户角色、业务目标、前置数据、环境配置、通过标准。这个概念不是某个工具里的专有名词，而是我自己在做测试架构时的一种组织方式，类似测试分层里的“测试计划”落地版。每份 profile 都像一张业务场景的画像，跑它的时候，你是在验证“某一个具体角色，在某个具体状态下，能否达成某个业务目标”。

2.2 第一份档案 profile1 应该怎么设计

“e2e profile1”值得单独拿出来说。我的建议很明确：第一份档案，只覆盖一条黄金路径，别贪多。

选黄金路径有一条原则：找业务里最核心、最常用、一旦挂了影响最大的那条主链路。拿内容社区举例，就是注册 → 登录 → 发一篇文章 → 在列表页看到它 → 编辑 → 再发布。拿电商举例，就是搜索商品 → 加入购物车 → 结算 → 支付 → 在我的订单里看到订单。这条链路不需要覆盖所有分支，它只需要代表“绝大多数用户最依赖的那条路”。

选好路径之后，给 profile1 定义四件事：

• 角色：这个场景里的用户是谁。建议从“新用户”开始，因为新用户没有历史包袱，前置数据最容易构造。
• 数据状态：跑这个场景之前，系统里应该有什么。比如已注册账号、一张可用的支付卡、一个默认收货地址。数据尽量用种子数据或者 API 直接造，不要依赖 UI 操作去造。
• 环境配置：被测环境地址、账号权限、是否需要特殊开关。
• 通过标准：业务终点是什么。例如“订单状态变为 PAID”，而不是“页面弹出了支付成功弹窗”。

把 profile1 做成一个可复用的配置对象，是我比较推荐的做法。它会变成一个“模板”，后续的 profile2、profile3 可以基于它扩展。原因很简单：先让最核心的链路稳定跑起来，你才能建立对这套设施的信任，然后才有资格谈横向铺开。这个顺序反了，后面全是坑。

2.3 从 profile1 到 profileN：别用数量代替质量

等 profile1 稳定运行一段时间后，再开始扩展其他档案。常见的扩展维度有三个。

一个是角色维度。新用户、老用户、未登录用户、管理员、被封禁用户，不同角色的权限边界和可见内容完全不同，每个角色都应该有一条代表性路径。一个是业务分支维度。比如下单时库存不足、支付超时、优惠券过期，这些分支在真实世界里经常发生，比主路径更容易出隐蔽问题。还有一个是异常维度。弱网下的重试、服务超时的兜底提示、接口 500 时的友好降级，这些往往是被团队遗忘的角落。

我见过有人一上来就建了五十个场景档案，结果每个都跑得摇摇晃晃，最后全被禁用了。我的经验是：档案数量宁少勿滥，每新增一个 profile，必须有明确的业务价值，并且要有人为它的稳定性负责。e2e 是资产还是负债，分界线就在这里。

3. 实操：搭一套能长期复用的 e2e 骨架

3.1 工具选型：选对组合比选对单个工具更重要

聊 e2e 实操，绕不开工具选型。我用了几年下来，最大的感受是：没有银弹，但确实有更接近主流实践的组合。

早期 Selenium 统治地位很强，WebDriver 协议兼容性广，但它的缺点是慢、依赖重、对现代前端框架的异步渲染支持不够顺滑，写出来的代码也很啰嗦。后来 Cypress 火过一阵，开发者体验确实好，架构上跑在浏览器里，调试很直观，但它对多标签页、跨域场景的支持一直比较别扭。这两年 Playwright 越来越主流，它的核心优势有三个：一是通过 CDP 直接和浏览器通信，快；二是自动等待机制做得好，默认会等元素可操作，能消灭大量隐性时序问题；三是自带 trace 录制和重试机制，排查问题非常方便。

我自己的建议是，新项目优先考虑 Playwright，老项目上 Selenium 实在迁移成本太高，也不强求。选好浏览器自动化框架之后，还要搭配一个测试运行器（Playwright 自带 Test Runner，也就够了）和一套断言库。不要自己造轮子去管理浏览器实例和重试逻辑，这些基础设施交给成熟工具，你的精力应该花在场景设计上。

3.2 项目结构与 profile1 的代码落地

下面这份结构是我在实际项目中比较顺手的一种组织方式，供参考：

e2e/ ├── profiles/ │ ├── profile1.main-flow.ts │ └── profile2.admin-flow.ts ├── fixtures/ │ └── auth.ts ├── pages/ │ ├── login.page.ts │ └── checkout.page.ts ├── helpers/ │ ├── db.ts │ └── api.ts └── tests/ ├── main-flow.spec.ts └── admin-flow.spec.ts

profiles 目录放场景档案配置，pages 目录按页面对象组织 UI 交互逻辑，helpers 放数据准备和接口调用，tests 只放具体用例。其中 profiles 是最容易被忽略但最值得先写的部分。

以 profile1 为例，我会把它定义成一份纯配置对象：

// profiles/profile1.main-flow.ts export const profile1 = { name: "main-flow", role: "new-user", baseURL: process.env.E2E_BASE_URL ?? "https://staging.example.com", user: { phone: "13800138000", password: "Test@123456", nickname: "e2e_newbie", }, seed: { defaultAddress: "上海市浦东新区XX路100号", defaultCard: "bankcard_test_01", }, businessGoal: "new user finish first order", passCriteria: { orderStatus: "PAID", orderVisibleInList: true, }, };

这里每个字段都有讲究。baseURL 必须从环境变量读取，避免本地和 CI 配置漂移。user 建议用独立的测试账号，不要动生产或共享账号。seed 数据用固定种子值，保证可重复。passCriteria 写的不是 UI 文案，而是业务状态。这样配置的好处是，当页面改版导致用例崩了，你第一反应是去查 page 对象而不是改业务定义——配置与实现的分离，能大幅降低维护成本。

登录态的处理是我特别想强调的一点。如果每个用例都从登录页开始走一遍，时间成本和失败概率都会成倍上升。主流框架都支持会话复用，Playwright 里叫 storageState。我的做法是单独跑一次“登录并保存认证状态”的 setup，然后把状态文件注入用例：

// tests/main-flow.spec.ts import { test, expect } from "@playwright/test"; import { profile1 } from "../profiles/profile1.main-flow"; test("profile1: 新用户完成首单支付", async ({ page }) => { // 前置：已在 setup 中登录并复用会话 await page.goto("/home"); // 1. 搜索商品 await page.getByPlaceholder("搜索商品").fill("无线机械键盘"); await page.getByRole("button", { name: "搜索" }).click(); // 2. 选择第一个商品，加入购物车 await page.locator(".product-card").first().click(); await page.getByRole("button", { name: "加入购物车" }).click(); // 3. 进入结算页 await page.getByRole("link", { name: "去结算" }).click(); await page.getByRole("button", { name: "提交订单" }).click(); // 4. 使用默认卡支付 await page.getByRole("button", { name: "确认支付" }).click(); // 5. 断言业务状态而非纯 UI 文案 await expect(page).toHaveURL(/\/order\/result$/); await expect(page.getByText("支付成功")).toBeVisible(); });

注意用例整体的节奏：尽量用角色语义化的选择器（getByRole、getByPlaceholder），少用#app > div > .btn这种脆弱的 CSS 路径。断言要多一层业务校验，如果后端提供了订单查询接口，建议在 UI 断言之外再调一次接口确认订单状态是 PAID，这种“UI + 接口双重断言”的做法，能防住那种页面正常但数据没落库的诡异问题。

3.3 稳定 e2e 用例的“四层设计观”

我总结过一个四层设计观，每层都可能成为 e2e 成败的分水岭。

第一层是前置稳定。用例必须能独立运行，不依赖其他用例的执行顺序，也不依赖前置用例留下的状态。跑 e2e 最忌讳的就是用例之间有隐形依赖，A 用例创建了订单，B 用例拿这个订单来断言，A 一挂 B 必挂，排查时还要一个个往前翻。

第二层是动作真实。点击、输入、滚动这些操作要尽量贴近真实用户，不要为了“稳定”去直接改 DOM 状态或者调内部函数。改 DOM 会让用例跑得快，但它测的已经不是用户路径了，一旦重构，这类用例第一时间失效。

第三层是等待可解释。e2e 里绝大多数的偶发失败都出在等待策略上。我的原则是：能自动等待就不要手写 sleep，能用断言轮询就不要固定等待。Playwright 的 locator 自带自动等待，如果你发现一个操作偶尔失败，大概率是它等待的条件不够精确。比如要等一个元素“不可见”，和等它“被移除”，是两种不同的条件，写错了就会偶发红。

第四层是断言有业务意义。断言 UI 文案是最低级的，文案说改就改；断言元素可见性稍好一点，但也不够。真正有效的断言是业务状态断言：订单状态、数据库记录、接口响应体、URL 路由。页面只是业务的投影，你断言的是投影，还是投影背后的实体，决定了这条用例的生命周期。

3.4 数据隔离与环境治理：e2e 稳定性的隐形地基

数据问题是我在 e2e 上花时间最多的地方。共享数据是这个领域最大的毒性来源，两个用例同时用同一个测试账号操作同一种商品，互相污染起来，你能看到的失败信息往往毫无关联。

我现在的基本盘是三条。第一，每个 profile 使用独立的数据命名空间，比如账号前缀固定为e2e_，再加随机后缀；商品、订单号都带上用例标识。第二，造数和清理都走 API 或直连数据库，不走 UI。让 UI 去填一个几十字段的表单来造数据，慢不说，还很脆。比如建一个测试数据助手，专门负责执行 SQL 清理和调用内部接口初始化数据。第三，对数据库里的种子数据做“只读假设”。凡是可能被写操作改动的数据，每条用例跑完及时还原，或者用事务回滚的思路，避免脏数据累积。

环境治理方面，e2e 必须跑在独立环境上，和开发自测环境隔开。否则别人一部署，你的测试就挂，这种“环境抖动”会把 e2e 的信任感消耗殆尽。用容器化方案把被测应用、数据库、依赖服务一键拉起来，是目前最省心的一种做法。

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

4.1 我踩过且反复出现的六个坑

这些年我在 e2e 稳定性上踩过的坑，大多集中在下面六个场景，整理成一张速查表，遇到类似问题可以直接对照：

第一个坑值得多说两句。固定 sleep 是 e2e 新手最容易掉进去的陷阱。点击一个按钮后，不知道异步请求什么时候回来，干脆waitForTimeout(3000)，短了偶发失败，长了浪费时间。正确做法是等待“业务条件出现”，比如等待那个“提交订单”按钮变为可点击、等待某个网络请求完成、等待订单状态从 PENDING 变成 PAID。让等待条件直接反映业务结果，而不是用时间轴去猜。

4.2 定位一次 e2e 失败的黄金三步

就算设计再完善，用例该挂还是得挂。关键是怎么快速定位，不让一个失败吞掉一下午。

我的排查顺序基本固定。第一步看 trace 回放。打开录制到的操作录像，看失败前最后几步发生了什么：元素有没有渲染出来，请求返回了什么状态码，页面上是不是冒出了意料之外的弹窗。这一步能解决大概一半的问题。

第二步对比网络请求。把失败用例和上一次成功用例的请求日志放在一起，看多出了哪个请求、哪个响应超时了、哪个接口返回了 500。很多 e2e 失败的本质都是后端不稳定或者接口契约变了，只是通过 UI 表现出来了而已。

第三步查当时的测试数据状态。去数据库里看看这条用例涉及的订单、账号、商品记录到底处于什么状态。经常有这种情况：断言没查到订单，不是代码有 bug，而是上一条用例把这条订单消费掉了。数据问题在失败根因里的占比，远比很多人想象的高。

4.3 把 e2e 跑进 CI 的“止损机制”

e2e 一旦进入 CI，就会面临一个新的问题：它负担太重，以至于团队不敢把它作为合并的强制门禁。我的建议是搭配止损机制，而不是一刀切。

第一，分层运行。把用例分成两层：冒烟层和全量层。冒烟层只跑 profile1 这类核心链路，控制在几分钟内，作为合并主分支前的强制门禁。全量层跑所有场景档案，放夜间定时任务里执行，第二天早上出报告。这样既保证了核心链路的实时防护，又不会因为一个边缘用例拖慢所有人的发布节奏。

第二，重试但对结果分类。像 Playwright 自带重试机制，我会倾向于“失败后重试一次，但重试之后仍失败才算真失败”。同时要把失败原因简单分类：如果失败发生在全局的 beforeAll 阶段，说明是环境或数据准备问题，这种失败要单独报警，因为它大概率是设施故障而不是业务 bug。如果失败发生断言阶段，才需要人工介入看业务逻辑。

第三，失败通知要精准。不要一封邮件发给全组，大家都看麻了就没人在意了。我习惯按 instrumented 路由通知：哪个 profile 挂了，就邮件/群消息发给这个 profile 的责任人，附带 trace 链接和失败截图。责任到人，修复速度会快很多。

我这几年的一个固执心得

做 e2e 这件事，我观察到一个规律：身边凡是觉得 e2e 没用的团队，几乎都是从堆用例开始的；而觉得 e2e 真香的团队，几乎都是从 profile1 这条路一步一步走出来的。我自己现在接手新项目，第一条规矩就是从主链路搭一个最小但完整的端到端用例，它像一面照妖镜，能把环境、数据、权限、接口各种问题在第一时间照出来。

另外分享一个我私藏的小操作：给 profile1 的用例特意设置一个很短的跑动预算，比如必须控制在 60 秒内。这个限制会倒逼你做三件事——登录态复用、数据前置准备、等待条件收敛。把第一条黄金路径的时间压下来，后面扩展 profile2、profile3 时你就有了水平基准。速度不是 e2e 的结果，速度快起来，e2e 的稳定性自然就容易守住了。