聊到 e2e可能一千个测试工程师心里有一千种看法。有人觉得它不过是把用户最长的旅程在浏览器里跑一遍有人觉得它是自动化测试里最容易崩盘的部分。最近我在整理测试工程时看到一份命名为 e2e profile1 的配置里面写着环境地址、账号信息、浏览器矩阵和一整套测试标记。这让我想起很多团队对 e2e 的态度想上又不敢上。这篇文章就结合我的实际经历聊聊 e2e 测试到底怎么搭、怎么配、怎么跑尤其想拆一下这种基于 profile 的配置方式看看一份看似简单的配置背后藏着哪些关键决策。如果你是刚接手公司自动化测试体系、或者正在纠结 Playwright 和 Cypress 怎么选这篇应该能给你一些可复用的思路。1. 先想清楚e2e到底要解决什么问题1.1 端到端测试和单测、接口测差在哪很多人刚接触 e2e 时会把它理解为“在页面上点一圈”。其实它本质上是把整个业务闭环拉起来验证用户从浏览器页面发起操作经过前端路由、接口调用、后端服务、数据库读写最后回到页面展示任何一个环节出错这条链路都会断。单元测试验证的最小单元往往是函数或组件它只关心“输入 A 能不能得到输出 B”接口测试关心的是“请求 X 能不能拿到正确返回的 Y”。这两层测试能挡住很多低级错误但挡不住模块之间的协作问题。我举一个真实例子接口层返回的数据格式是对的但前端在某个浏览器版本里解析 Date 对象时出现了时区偏移导致用户在界面上看到的日期比实际少了一天。单测跑的是模拟数据接口测跑的是真实接口但只有 e2e 会真的用 Chromium、Firefox 各跑一遍完整页面流程把这类问题暴露出来。但 e2e 也是最容易“翻车”的测试。它依赖的东西太多测试环境是不是干净、账号数据是不是隔离、第三方服务是不是稳定、浏览器进程会不会被系统杀掉。稍有风吹草动用例就红给你看。所以团队里对 e2e 的常见评价是“投入大、产出不稳定”但换个角度想如果做到稳定它带来的价值同样也是其他层级测试给不了的你可以在发版前一个小时用一条命令确认核心业务还能跑。1.2 “e2e profile1”这个命名背后藏了哪些信息我看到的这个 e2e profile1并不是某个工具的强制要求而是团队的一种配置约定。你可以把它理解成“一套完整的端到端测试场景快照”。它一般包含环境信息、登录账号、测试数据、要跑的浏览器、以及重试策略等。为什么要用 profile 这个概念因为它解决的是多环境、多场景并存的问题。同一个 e2e 工程你不可能只在测试环境跑还得跑预发环境、生产冒烟环境也不可能只有一套账号有时需要普通用户有时需要管理员有时需要新注册用户。如果把这些硬编码到测试用例里每换一个环境就要改一遍代码维护成本非常高。配置驱动的思路是把“跑什么环境、用哪个账号、测哪些浏览器”这些变量从代码里抽出来放到 profile 文件里。当你执行E2E_PROFILEprofile1 npx playwright test时测试工程会自动加载对应的配置。这样一来测试用例代码不需要感知具体的环境地址和账号密码它们只需要拿到一个 baseURL 和一组登录态即可。profile1 如果对应的是“冒烟场景”那么里面可能配置了 fastest 的环境地址、核心账号、Chromium 单浏览器、失败重试 2 次、只跑带 smoke 标记的用例。profile2 如果对应的是“全量回归”则可能换成完整浏览器矩阵、多个账号、更长超时时间。这种用配置区分场景的方式特别适合维护一套代码跑多种场景省掉重复造轮子。2. 核心细节测试工程的关键组成与配置设计2.1 框架选型为什么我最后选了 Playwright先聊工具。E2E 框架这这几年变化很大Selenium 属于老牌选手Cypress 靠开发体验火过一阵Playwright 则是后起之秀。我三个都实际用过说下自己的体感。Selenium 足够灵活支持 Java、Python、JS 等各种语言但它的 WebDriver 架构决定了你写定位、等待、跨浏览器兼容需要大量额外努力。尤其是隐式等待和显式等待混在一起时那种“测试时好时坏、没人敢改”的痛踩过的都懂。Cypress 的调试体验确实惊艳可以在时间轴上回放每一步但早期它对多标签页、iframe、多浏览器的支持有限当时我在一个需要操作两个页签的业务场景里被卡了很久。Playwright 解决了这些问题自动等待让“sleep(3 秒)”这种临时方案几乎可以绝迹每个测试用例独立开浏览器上下文隔离性做得很好一次 API 调用就能拿到 Chromium、Firefox、WebKit 三套浏览器。当然工具没有绝对好坏得看团队现有技术栈。如果团队已经有一套 Cypress 用例跑得不错没必要为了追新而迁移。但从零搭建一个新工程我更愿意推荐 Playwright。它提供了 codegen 录脚本、trace 查看器、UI 模式调试这些能直接提升效率的能力最重要的是它对“并行执行”和“失败重试”的支持很成熟这恰恰是 E2E 稳定性的关键。2.2 profile配置到底在配什么一份配置拆给你看我之前用过的 profile 文件结构并不复杂但每一项背后都有原因。你可以把 profile 想象成一份“点单配置”测试工具是厨师profile 就是告诉厨师今天在哪个厨房、用哪套餐具、做几道菜。config/ profile1.js profile2.js base.jsbase.js 存放公共部分比如测试目录、通用超时、报告格式profile1.js 只写差异部分。拿 profile1 举个例子module.exports { baseURL: https://staging.example.com, testMatch: /.*smoke.*/, browser: [chromium], viewport: { width: 1280, height: 720 }, use: { storageState: ./data/profile1-login-state.json, screenshot: only-on-failure, trace: retain-on-failure, }, retries: 2, workers: 2, };baseURL 我不会在用例里写死而是从配置读取。这样 profile1 指向 stagingprofile2 指向预发环境用例代码一行都不用改。storageState是 Playwright 的“已登录状态”先把登录后的 cookie 和 localStorage 保存成文件测试用例直接从登录态开始跑能少写大量登录逻辑。testMatch用来控制跑哪些用例冒烟 profile 只跑标记为 smoke 的文件全量回归 profile 则跑全部文件。很多时候配置写得不清楚不是工具的问题而是没有想清楚“到底哪些东西会变”。一旦变量很多配置也要跟着调整。我的建议是把“环境地址、账号状态、浏览器、并发数、重试策略、报告形式”这六类罗列出来作为 profile 的最小字段集其他高级选项按需再加。2.3 这些参数不调好你的e2e一开始就在裸奔配置里的每一项参数都不是凭空存在的。我见过很多团队在 playwright.config 里保留了默认值结果跑起来全是不稳定的超时和误报。下面几个参数是我每次写配置文件都会重点盯的。参数推荐值为什么这样调timeout30_000单个用例的全局超时30 秒足够覆盖大部分用户操作又不至于让失败等太久expect.timeout5_000断言等待超时。点击后页面要跳转、要渲染给它 5 秒如果 5 秒内断言仍不满足基本是业务真的出了问题retriesCI 上 2本地 0本地希望快速反馈失败就立刻看CI 上给两次重试机会过滤偶发网络抖动headless本地 falseCI true本地要看到浏览器在做什么CI 无人值守必须隐藏界面workersCI 上按 CPU 核数的一半并发开太多容易被系统资源拖垮尤其是容器环境里经常因此失败traceretain-on-failure用例失败时自动保存完整操作轨迹点开就能看到每一步的截图和网络请求排错效率高很多这里面expect.timeout是最容易被忽略的。很多人只看总的 timeout但真正的等待瓶颈其实在断言。比如一个按钮点击后要等列表接口返回如果expect只等 1 秒那不稳定的概率极高如果给到 5 秒配合自动重试稳定性会明显提升。还有一个要提醒的不要无脑使用waitForTimeout固定等待。前端渲染快的项目可能 500ms 就好慢的时候要 3 秒写死sleep(2000)只会让测试要么慢要么飘。现代框架的自动等待机制能帮你等元素可交互、等请求返回这些机制比任何固定时间都可靠。3. 实操过程从零搭建一套e2e跑起来3.1 目录结构搭一个不会越用越乱的骨架我见过不少团队的 e2e 项目所有文件堆在根目录spec、截图、临时脚本混在一起两星期后就没人敢动。宁可前期多花十分钟把目录搭清晰也不要后面在混乱里挣扎。用一个常见的 Playwright 工程举例e2e/ config/ base.js profile1.js profile2.js tests/ smoke/ login.spec.js purchase.spec.js full/ user.spec.js fixtures/ test-data.json utils/ request-helper.js playwright.config.js package.json初始化命令同样简单npm init -y npm i -D playwright/test npx playwright installplaywright/test里已经包含了测试运行器、断言库和报告器不需要额外再装一堆依赖。npx playwright install会下载 Chromium、Firefox、WebKit 三个浏览器的二进制文件这一步在公司内网环境里可能比较慢建议提前下载好或配置镜像源。package.json 的 scripts 我会写成这样{ scripts: { test:e2e:smoke: cross-env E2E_PROFILEprofile1 playwright test --projectprofile1, test:e2e:full: cross-env E2E_PROFILEprofile2 playwright test --projectprofile2 } }用cross-env是为了兼容 Windows 和 macOS/Linux 的环境变量写法很多坑都是因为命令行里直接写E2E_PROFILExxx在 Windows 下不生效导致的。3.2 第一条用例从登录到完成关键业务写第一条用例时别急着覆盖所有功能先把“核心闭环”跑通。比如一个后台管理系统最关键的就是登录后创建一个资源并看到它在列表里出现。用 Playwright 的写法大致是这样const { test, expect } require(playwright/test); test(用户登录后能创建项目, async ({ page }) { // 使用 profile 里存储的登录态直接进入首页 await page.goto(/projects); // 点击新建按钮 await page.getByRole(button, { name: 新建项目 }).click(); await page.getByLabel(项目名称).fill(e2e-demo); await page.getByRole(button, { name: 保存 }).click(); // 等待列表出现新项目 await expect(page.getByText(e2e-demo)).toBeVisible(); });为什么我要用getByRole和getByLabel而不是一上来就page.locator(xpath//div[classel-button])因为端到端测试模拟的是真实用户的感知方式用户看得见的是按钮上的文字、输入框的标签而不是一眼看不到的 DOM 层级。用面向用户的定位器写出的用例即使前端组件库从 Element UI 换成 Ant Design只要文案和语义不变用例也能继续跑。如果页面里没有合适的语义标签再退而求其次加>const base require(./config/base); const profile require(./config/${process.env.E2E_PROFILE || profile1}); module.exports { ...base, ...profile, use: { ...base.use, ...profile.use, }, };这样执行下面的命令时cross-env E2E_PROFILEprofile1 npx playwright test --projectprofile1测试运行器会读取 profile1 里的配置只跑smoke目录下的用例用 Chromium、并发 2、失败重试 2 次并且失败时保留 trace 和截图。跑完之后控制台会输出每一条用例的耗时和状态同时生成 HTML 报告。如果出现失败样例打开 trace 文件后你会看到每一步操作对应的页面截图、DOM 快照和网络请求甚至还能直接查看浏览器控制台报错。这个能力帮我定位过很多“明明看到按钮了却点不上”的问题最终发现是某个遮罩层阻挡了点击事件这类问题看 trace 一眼就能确认。4. 常见问题与排查技巧实录4.1 三座大山慢、乱、不稳定第一座山是“慢”。E2E 天然比单元测试慢但慢得离谱就不正常了。常见原因包括用例不加标记导致全量跑、缓存策略没配好、并发数太小、环境没有预热。我的做法是把用例分成冒烟和全量两级profile1 专跑冒烟控制在 1-3 分钟内夜间再跑全量。而不是所有场景都堆在一个 profile 里跑一小时。第二座山是“乱”。这里主要指测试代码和配置混乱。定位器乱七八糟、页面对象模型随意扩张、配置里藏着大段注释掉的代码最后没人愿意维护。解决办法是定规矩定位器必须用 getByRole/getByLabel 优先必要时用>outputDir: test-results/${process.env.E2E_PROFILE || profile1},这样 profile1 和 profile2 失败时生成的截图、trace 就不会混在一起了。4.3 稳定上线的几个“土办法”技术层面之外我真正想强调的是“流程”和“习惯”。E2E 不是写完脚本就结束的它是需要长期喂养的系统。我会在项目里做三件事。第一失败用例必须做“失败归因”。每次跑完看报告如果是因为环境没有部署导致失败不能简单地点 re-run要标记为环境问题并通知运维。如果是因为测试数据被改动导致失败就要找测试数据的管理人。分清楚“测试代码问题”“测试环境问题”“业务代码问题”这三个类别才能避免所有红灯都被当成“测试不稳定”而忽略。第二给每个失败的用例设置“重试上限”。本地跑的时候我不开重试因为这会影响调试速度但 CI 上我会开两次重试并且要求重试成功后用例仍然要保留失败现场的截图否则你永远不知道它曾经为什么失败。很多不稳定问题就是靠重试现场的 trace 才被确认的。第三设立一个“明天必须修”的清单。如果某天冒烟用例还有红色我会在第二天上午第一件事去处理绝不拖到周末。E2E 用例一旦变红后面所有人都会对它失去信任最后变成“反正它会红出了问题再说”这样测试系统就废了。真正开始有价值的判断标准最后说一个我踩了好几次坑才养成的习惯不管团队多忙我都会在本地跑一遍 profile1 对应的那几条冒烟用例再去提代码合并。不是不相信 CI而是 e2e 出问题时本地能直接启动 UI 模式一步步看比在远程环境里翻日志高效得多。如果你也刚开始搭建 e2e我建议不要一上来就追求把全部功能都做成端到端先挑一个最核心的用户旅程用 profile1 这种最小的配置跑通每天坚持跑一周。只有当这组用例可以连续一周每次命中、没有人需要手动点“重新跑”这套 e2e 才算是真正有价值了。