端到端测试实战：从e2e profile 1到Playwright稳定落地

1. 项目概述与核心思路拆解

1.1 从“e2e”这个标题能挖出什么

“e2e”全称是 end-to-end，对应中文就是“端到端”。如果你在搜索引擎里直接敲这三个字母，跳出来的多半是三类东西：一类是软件测试领域的端到端测试框架和教程，一类是 AI 大模型里的端到端训练方案，还有一类是自动驾驶里的端到端感知决策架构。

结合我这些年在一线摸爬滚打的经验，绝大多数人搜“e2e”，要解决的核心问题就一个——“我写完接口测试和单元测试之后，怎么才能保证整个系统真正跑通？”说白了，端到端测试是软件质量保障体系里离用户最近、也最“残酷”的一环：它不关心你的某个函数返回了什么，也不在意你的某个接口响应是否合规，它只关注一件事：用户从头到尾走完一条真实业务链路，系统能不能给出正确结果。

这就像你装修房子，单元测试是检查每块瓷砖贴得牢不牢，接口测试是检查水管接头不漏水，而端到端测试则是你拎着行李箱走进这套房子，按照日常生活动线完整走一遍——进门换鞋、开灯、烧水、上厕所、洗澡，走到哪个环节卡住了，哪个环节体验是灾难，立刻见分晓。没有这一步，前两层测得再漂亮，用户一进门照样可能栽跟头。

1.2 端到端测试到底解决的是哪一类痛点

我自己见过太多“测试环境一片绿，生产环境一团乱”的案例。为什么会这样？因为单元测试和接口测试天然存在一个盲区：它们默认各个模块之间的协作是符合预期的。但真实系统里，前端 A 调用网关 B，网关 B 转发给服务 C，服务 C 再去查数据库 D，中间任何一环的字段定义、超时设置、鉴权逻辑、网络抖动，都可能让整条链路断裂。端到端测试的做法是绕过这些内部细节，直接从用户入口发起真实请求，沿着整条链路打到终点，验证最终结果。

所以，如果你正准备搭建 e2e 测试体系，或者已经在维护一条或几条 e2e 用例但总觉得不够系统，这篇内容就是按我实际踩坑和落地的经验来写的。我会把“e2e profile 1”这个概念也揉进来——它本质上是说一套端到端测试的完整执行配置档案，你只需要把“profile 1”理解成你要维护的第一套可复用的测试场景组合就可以。下文我会用一个真实项目案例，把从设计到落地再到排查的完整链路拆开讲清楚。

2. e2e 测试的技术选型与架构设计

2.1 主流的端到端测试工具，到底怎么选

聊 e2e 之前，绕不开的问题一定是工具选型。我在不同项目里试过 Cypress、Playwright、Selenium，也见过不少人纠结这三者选哪个。先摆一个结论：新项目能选 Playwright 就选 Playwright，别在 Selenium 上耗时间；老项目已经在 Cypress 上沉淀了大量用例的，没必要强行迁移。

Selenium 是端到端自动化领域的“老大哥”，2004 年就出现了，支持的语言多，生态老，社区问答资源丰富。但它的缺点也很致命：架构是基于 WebDriver 的，每次操作都要经过浏览器驱动和客户端之间的网络通信，执行慢；等待策略基本靠 sleep 和显式等待，写起来啰嗦，跑起来不稳定。用一个不太恰当的比喻，Selenium 就像一台老式手动挡汽车，能开，能把你带到目的地，但每一步都得你自己挂挡、踩离合，乘客体验还一般。

Cypress 的特点是“快，而且对前端开发者友好”。它跑在浏览器进程内部，执行速度比 Selenium 快不少，而且自带时间旅行调试，出错之后可以直接回放每一步的界面状态。缺点同样明显——它不支持多标签页，不支持多浏览器上下文，跨域场景经常要写额外配置。如果你的系统是纯单页应用，Cypress 很合适；但只要涉及到跳转外部系统、多开窗口、或者需要操作 iframe 做第三方登录，Cypress 就会开始折磨你。

Playwright 是微软开源的项目，核心优势有三点：第一，底层协议比 WebDriver 先进，走的是 Chrome DevTools Protocol，启动速度和控制精度都更好；第二，自带 auto-waiting，大部分操作不需要你手动写等待逻辑，它能自动等到元素可交互；第三，原生支持多页面、多浏览器、多上下文，做复杂的跨系统测试非常顺手。我最近一年新写的 e2e 用例全部基于 Playwright，实测下来稳定性和开发效率都比 Selenium 上了一个台阶。

2.2 e2e profile 1 的含义：从“跑通一次”到“跑得有意义”

“e2e profile 1”这个说法，在中文互联网的搜索结果里其实并不算一个标准术语，它更像是某个测试平台或 CI 流水线里用来命名一组测试执行配置的约定。但在实际落地中，我强烈建议你把 e2e 测试用例做“档案化”管理——不要把几十条用例挂在同一个配置文件里一把梭跑，而是要拆成多个 profile，每个 profile 对应一种明确的目标。

我给你一个我实际用过的拆分方案：

Profile 名称	执行范围	触发时机	目标
profile 1: smoke	核心主流程（登录、下单、支付回调）	每次代码合并前	花费最短时间确认系统没有“彻底坏掉”
profile 2: regression	全部 e2e 回归用例	每晚定时 + 发布前	尽量多地覆盖历史功能，防回归
profile 3: 性能辅助	关键链路的耗时采集	每周一次	感知核心链路的响应劣化趋势

你可以看到，profile 1 讲究的是“快和准”：可能整个执行集合只有 10~20 条用例，但每条都命中用户最核心的利益诉求。这些用例如果通过，说明系统整体没有被炸掉；如果失败，开发团队立刻中止合并或者回滚。而 profile 2 讲究的是“宽和全”，跑一次两小时也认了，只要能兜住回归风险。

这个思路的核心价值在于：你用同一套代码库，管理了“快检查”和“深检查”两档需求。而不是像很多团队一样，把几百条用例全丢在一个目录里，跑一次两小时，开发等不起，到最后根本没人跑，e2e 沦为了摆设。

2.3 端到端测试的架构设计：从“点状用例”到“链状场景”

很多初学者写 e2e 会犯一个毛病——把一个端到端用例写成了“接口用例的浏览器版”。比如打开页面，等一个按钮出现，点了一下，断言某个 toast 弹出来，结束。这根本没有端到端的意思，最多叫“UI 冒烟用例”。

真正的端到端用例，灵魂在于业务的连续性和状态的传递。以我最近在做一个电商后台的 e2e 项目为例，我设计了一条“用户下单全流程”的主干用例，链路是这个样子的：

1. 清空购物车（前置状态准备）
2. 通过商品搜索接口或者 UI 搜索框找到指定商品
3. 加入购物车，断言购物车徽标数字 +1
4. 进入购物车，修改购买数量，断言价格实时更新
5. 点击结算，走到订单确认页
6. 填写收货地址（注意：这里有联动逻辑，选择省份后城市下拉框必填）
7. 选择支付方式为“在线支付”，跳转收银台
8. 用测试账号完成模拟支付，等待支付回调
9. 断言订单状态从“待支付”变为“已支付”
10. 进入“我的订单”列表，断言该订单出现在第一行，金额正确

这条链路的每一步之间都有前置依赖，第 4 步的结果可能被第 5 步消费，第 6 步的联动逻辑又依赖第 5 步选中的订单数据。每条用例都是一次有状态的旅行，而不仅仅是一个独立动作。

从架构维度看，我建议你在项目里为每条 e2e 用例增加“状态准备层”的概念。

关键提醒：e2e 用例的独立性非常重要。如果用例 A 依赖用例 B 先执行完（比如 B 创建了一笔订单数据，A 再去做确认收货），那么这条依赖链就是一颗定时炸弹。因为一旦 B 挂掉，A 必挂，排查问题的时候你根本不知道根源是谁。正确的做法是：每条用例都通过 API 或数据库直接准备前置数据，让用例之间互不依赖。

基于这个思路，我把 e2e 的代码结构抽象成三层：状态准备层（setup）→ 业务执行层（action）→ 断言校验层（assert）。setup 承担数据创造，action 负责模拟用户操作，assert 负责对结果进行真实用户视角的验证。这个结构看着简单，但随着用例数量增加，它带来的维护收益是几何级的。

3. 端到端测试的实战落地：从零开始写一个 profile

3.1 用 Playwright 搭建 e2e 项目骨架

既然前面说了推荐 Playwright，那这里就以它的实际工程为例，讲清楚怎么搭起一套可用的端到端测试体系。假设项目名称叫e2e-demo（名字随意，不重要），我会用 TypeScript 作为语言，因为类型定义对维护长链路用例非常友好。

第一步，初始化工程并安装依赖：

mkdir e2e-demo cd e2e-demo npm init -y npm install -D @playwright/test typescript npx playwright install

npx playwright install这一步是很多新手容易漏掉的。它的作用是下载对应浏览器的二进制文件（Chromium、Firefox、WebKit），如果这一步不做，后边跑用例直接会报browserType.launch: Executable doesn't exist的错误。

第二步，创建 Playwright 配置文件playwright.config.ts。如果你需要“profile 1”这种按场景集拆分执行的思路，在这里就能体现出来：

import { defineConfig } from '@playwright/test'; export default defineConfig({ testDir: './tests', timeout: 120_000, retries: 2, workers: 4, use: { baseURL: 'https://staging.example.com', headless: true, screenshot: 'only-on-failure', trace: 'retain-on-failure', video: 'retain-on-failure', }, projects: [ { name: 'profile1-smoke', testMatch: /smoke\/.*\.spec\.ts/ }, { name: 'profile2-regression', testMatch: /regression\/.*\.spec\.ts/ }, ], });

这段配置里有几个细节值得说明。

• retries: 2表示用例失败会自动重试两次。e2e 测试最怕的是“偶发失败”，比如网络抖动导致某个断言超时。直接开重试，能显著降低误报率，但要控制重试次数，不然真正的问题会被无谓的重试掩盖。
• trace: 'retain-on-failure'是 Playwright 的利器。用例失败后会自动生成一份 trace 文件，里面记录了每一步操作前后的 DOM 快照、网络请求、控制台日志。排查问题时，你几乎不需要让开发复现，直接把 trace 文件拖到 trace viewer 里就能看到现场。
• projects数组就是 profile 的执行入口。我用 file 路径区分了 profile1 和 profile2，分别对应 smoke 和 regression 两类场景集。

第三步，写第一个真正意义上的端到端用例。这里我用“登录 → 创建订单 → 验证订单列表”作为示例：

import { test, expect } from '@playwright/test'; test.describe('核心下单链路 (profile1)', () => { test('用户完成下单并在列表页看到订单', async ({ page }) => { // 状态准备：通过接口快速造数，避免 UI 注册流程拖慢用例 const user = await page.request.post('/api/auth/register', { data: { username: `e2e_${Date.now()}`, password: 'Test@123' }, }); expect(user.ok()).toBeTruthy(); const { token } = await user.json(); // 业务执行：带着 token 直接登录进入首页 await page.goto('/login'); await page.context().addCookies([ { name: 'session_id', value: token, url: 'https://staging.example.com' }, ]); await page.goto('/'); // 找到某个商品并加入购物车 await page.locator('.product-card', { hasText: '测试商品A' }).click(); await page.getByRole('button', { name: '加入购物车' }).click(); await expect(page.locator('.cart-badge')).toHaveText('1'); // 结算下单 await page.goto('/cart'); await page.getByRole('button', { name: '去结算' }).click(); await page.locator('#receiver_name').fill('张三'); await page.locator('#receiver_phone').fill('13800000000'); await page.locator('#province_select').selectOption('浙江省'); await page.locator('#city_select').selectOption('杭州市'); await page.getByRole('button', { name: '提交订单' }).click(); await expect(page).toHaveURL(/\/payment/); // 模拟支付成功，回到订单列表 await page.getByRole('button', { name: '模拟支付成功' }).click(); await page.goto('/orders'); await expect(page.locator('.order-item').first()).toBeVisible(); await expect(page.locator('.order-item .status')).toHaveText('已支付'); }); });

这段用例看起来简单，但里面藏着几个关键的测试思想，展开说说。

状态准备为什么要用接口而不是 UI？因为注册流程如果走 UI，每次都要填表单、等验证码、跳转，耗时 10 秒以上；而走接口只需要 1 秒。e2e 用例的执行时间是非常宝贵的资源，能把“前置条件准备”剥离出 UI 的，就绝对不要用 UI 操作来完成。这是 e2e 工程里优化执行时长的最有效手段。

为什么断言的是“UI 可见状态”而不是“接口返回值”？因为端到端测试的视角就是用户视角。用户在订单列表里看到“已支付”三个字，就代表这条链路的终点正确。你如果在这里断言数据库状态，反而引入了一层不必要的技术耦合，数据库字段改了，用例就挂了，但用户体验其实没变。要控制 e2e 的维护成本，就要严格守住“用户看得见、摸得着”的断言边界。

3.2 profile 1 的场景拆分与执行效率控制

前面在配置里我把 profile1 定位为 smoke，它的执行时间必须控制在 5 分钟以内。在实际项目里，profile1 的场景我建议拆成四类，每类覆盖一条主干链路：

1. 登录链路：验证系统入口是通的，包括账号密码登录、验证码校验、登录态持久化。
2. 交易链路：验证核心商业闭环，从商品浏览到下单支付到订单确认。
3. 内容消费链路：验证内容列表、详情页、收藏/点赞等操作能正常流转。
4. 账号管理链路：验证个人资料修改、密码修改、地址维护等基础能力。

不是所有页面都要放进 profile1。像用户协议页、帮助中心、低频管理后台，这些功能虽然重要，但变更频率低、影响半径小，放到 profile2 的回归集里更划算。

执行效率上还有几个实实在在的控制手段。

• 并行执行：Playwright 的workers参数可以控制并发运行环境数；如果你有 4 个 CPU 核心，配 4 个 workers，理论上执行时间能压缩到原来的一半。但要注意，被测试系统的数据库如果承受不了并发写入，可能会把系统压出问题，这个需要和开发确认。
• 标签选择运行：在命令行指定--grep @smoke这样的标签，可以随时只跑某一部分用例，不用每次都全量执行。
• 用例级超时设置：test.setTimeout(30_000)可以覆盖全局 120 秒的超时，针对那些简单的冒烟链路可以缩短等待时间，避免一个页面卡住拖 2 分钟才报错。

3.3 测试数据的管理策略：造数、隔离与清理

写 e2e 测试，最让人头疼的问题之一就是测试数据。如果每条用例都产生新订单、新用户，数据库没几天就堆满了垃圾数据；如果不造数据，多条用例复用同样的账号，就会出现相互干扰。我的建议是三条原则：

第一条，每条用例必须拥有独立的测试数据。用时间戳或者 UUID 作为用户名后缀，是成本最低的隔离方案。比如e2e_20250208_143501这种命名，一眼就能看出创建时间。这样即使上一条用例挂掉了，留下了脏数据，下一条用例也不会被它影响。

第二条，优先通过 API 清理数据，而不是数据库直删。你可以在用例的 teardown 阶段调用系统的清理接口，只删除这条用例产生的数据。直接操作数据库会造成数据和系统缓存不一致，比如 Redis 里还有用户 session，页面却显示用户不存在，反而引发更多问题。

第三条，给生产环境单独准备一套“只读型”测试账号。如果你需要跑生产环境的冒烟验证，不要用线上的真实用户数据。准备几个固定账号专门用于 e2e，且只允许执行只读操作（查询列表、浏览详情），涉及写入的用例一律在 staging 环境跑。

注意：测试数据的意义不只是“让用例能通过”，而是“让用例外网可观测”。我见过有人把测试数据全部清理得干干净净，结果排查线上问题时想要复现一个订单状态，反而找不到数据。所以建议你在 staging 环境保留一段窗口内的测试数据，方便回溯。

4. 端到端测试的调试、稳定性提升与团队协作

4.1 从“用例失败”到“定位根因”的排查路线

e2e 用例报红了，第一反应千万别是“这用例是不是写错了”。我见过太多人因为前端页面改了个文案，导致用例断言失败，然后花半天时间改用例，结果第二天开发又改回去了，如此反复。这种把“真 Bug”当“假阳性”忽略掉的做法，是 e2e 体系崩溃的开始。

当一个用例失败，我建议先走一套固定排查路线：

1. 打开 trace 文件或失败截图，确认失败发生时的页面状态。如果页面显示的是 500 错误页，那就是系统崩溃，不要改用例；如果页面显示的是空数据，那可能是测试数据没造好或者被清理了；如果页面显示的元素存在但文字对不上，再考虑是不是断言文案改版了。
2. 查看该段时间的接口日志。e2e 用例执行时，前端发起的每一个请求都会记录在 trace 的 network 面板里。定位到断言失败前最近的一个请求，看它的响应码是不是 4xx/5xx，基本就能判断问题是前端页面还是后端接口。
3. 确认环境差异。同一个用例在不同环境（staging 和测试环境）的表现可能不一样。检查当前的baseURL是否指向正确环境，检查该环境下是否存在依赖的第三方 mock 服务。

我自己遇到过的一个典型场景是：用例跑在 staging 环境，前一步骤创建了一个订单，但是 staging 环境配置了定时任务，每 10 分钟自动取消“未支付订单”，结果步骤 8 断言订单状态为“待支付”时，恰好撞上定时任务把订单取消掉了。这类问题不是用例的问题，也不是系统逻辑的问题，而是环境本身的动态行为搅乱了测试的稳定预期。解决办法是在用例设计阶段就避开这类定时窗口，或者把断言条件放宽到“待支付或已取消均接受”这种业务容忍状态。

4.2 稳定性提升的四个实用技巧

e2e 测试行业里有一句老话叫“Flaky Test 是团队的毒药”。用例今天绿明天红，过几天又绿，这种不稳定感会让团队对自动化体系失去信任，最后没人看报告，也没人维护。要把稳定性做上去，除了前面提到的 retries 配置，还有四个技巧非常有效。

技巧一：等待策略统一用 Web 断言，不要用“裸 sleep”。我在代码审查时经常看到有人写await page.waitForTimeout(3000)，这种硬等待极其脆弱——网络快的时候浪费 3 秒，网络慢的时候 3 秒又不够。Playwright 的expect(locator).toBeVisible()和toHaveText()内部都有轮询机制，既能等元素出现，又能自动在超时前快速返回，这才是推荐的等待方式。

技巧二：操作前先“锚定”控件，避免动态内容干扰。很多单页应用在异步渲染完成后会重新挂载 DOM 元素，如果你locator定位的是一个模糊路径（比如page.locator('button')或者.container > div > button），点击时很容易因为元素被替换掉而报element is detached错误。推荐给元素加上稳定标识，最理想的是>