1. 先从到底要不要上E2E说起端到端测试的定位与成本入行这些年我见过太多团队对 e2e端到端测试的态度在两个极端之间摇摆要么觉得它就是银弹一口气把整个业务线全部自动化结果一个月后维护成本爆炸要么被它的脆弱性折磨到怀疑人生最后所有用例全部注释掉留下一堆没人敢碰的代码。说句实话e2e 这门手艺难的不是写用例而是搞清楚它到底该在质量体系里站哪个位置。很多人把 e2e 理解成模拟用户点鼠标的工具这个理解不算错但太浅了。端到端测试的本质是站在真实用户的位置上用真实的浏览器、真实的网络、真实的数据完整走一遍用户会走的路径验证整个系统从下到上、从数据库到前端渲染是否协调一致。它不关心某个函数返回值对不对也不关心某个接口响应是否 200它关心的是一个用户打开网页之后能不能顺利注册、登录、下单、支付中途不会因为任何一环失灵而卡住。1.1 E2E 在测试金字塔里的真实位置经典的测试金字塔模型里底层是大量的单元测试中间是集成测试塔尖才是 e2e。为什么是金字塔而不是个桶因为越往下测试成本越低、运行速度越快、稳定性越高越往上覆盖范围越广但速度越来越慢、维护成本越来越高、失败时定位问题也越来越难。所以 e2e 从来不应该追求数量多而应该追求位置准。我的习惯是单元测试覆盖 70% 的纯逻辑集成测试覆盖 20% 的模块交互e2e 覆盖剩下的 10% 关键用户旅程。如果你反过来做把几千条用例全压在 e2e 上那就等着 CI 跑两小时、每天都有一堆随机失败等着你修吧。1.2 什么时候不该上 E2E这个反直觉的结论先说在前头不是所有项目都适合 e2e。我见过最荒唐的案例是有人给一个只有三个静态页面的官网写了二十多条 e2e 用例每次改个文案都得跟着改断言后来广告文案一天改三次测试就一天红三次最后全被删了。以下几种场景我建议你先别急着写 e2e产品还在原型验证阶段页面结构三天两头推倒重来业务逻辑极其简单没有跨模块的数据流转团队只有一两个人连 CI 都没有又或者是那种临时性的活动页活不过一个月。E2E 是重资产它的产出是长期回归信心如果项目本身生命周期很短或者页面还在剧烈变化这笔买卖是亏的。反过来如果你的系统里存在一条真正的核心用户路径——比如电商的逛、加购、下单、支付比如 SaaS 的注册、建工作区、邀请成员、发第一条消息——而且这条路一旦挂掉就等于业务中断那这时候 e2e 不是选项而是必需品。项目规模越大、人越多、发布越频繁越需要它来兜底。2. 选型不是选最好是选最不折腾Cypress 与 Playwright 的取舍笔记工具选型这事我踩过的坑比写用例踩的还多。从最早的 Selenium到后来一度很火的 Cypress再到现在的 Playwright每个工具都有自己的脾气关键是搞清楚你的团队在意什么、痛点是什么。没有最好的框架只有跟你团队免疫力最匹配的框架。2.1 Selenium能跑但折磨人Selenium WebDriver 是元老级方案它把浏览器操纵暴露成标准协议理论上什么语言、什么浏览器都能支持。很多大公司遗留的测试框架都是 Selenium。但它的问题也很典型各种隐式等待、显式等待写得让人精神分裂对弹窗、下载、文件上传这类场景的支持比较原始报告和调试体验基本靠外部插件拼凑分布式跑用例还要自己搭 Grid。除非公司已经有成熟的 Selenium 基础设施否则我不太推荐新项目从它起步。还有一个隐藏的坑Selenium 只管操作浏览器断言、等待、重试、报告全都要自己集成。如果你的团队是测试团队主导、有专门的基础设施工程师Selenium 是可控的但如果你只是几个前端工程师想快速把回归跑起来用它就是给自己找罪受。2.2 Cypress前端开发的利器但有天花板Cypress 当年火起来不是没道理的。它最大的特点是把测试跑在浏览器进程内能感知应用内部的一切所以调试体验极其顺滑——失败的时候你可以像看录像一样回放每一步操作还能打开 devtools 直接查当时页面上的状态。对前端工程师来说写 Cypress 用例的体验跟写业务代码几乎一样爽这也是它当年横扫社区口碑的原因。但 Cypress 的天花板也很明显。它默认只能在它自己的 Runner 里跑多标签页支持一直很别扭如果你想做移动端真机测试、或者要跑到 Safari 上那就更麻烦了。跨域导航上的限制让很多涉及第三方登录、嵌多个 iframe 的场景写得非常难受。我项目里有个单点登录流程所有 iframe 里的断言在 Cypress 里都要靠变通手段维护起来疼得厉害。2.3 Playwright综合成本最低的选项后来我整体迁移到了 Playwright现在已经成了我的默认答案。它由微软团队维护最核心的几个设计非常对路内置自动等待不用再写那些让人崩溃的sleep(3000)浏览器支持极好Chromium、Firefox、WebKit 一网打尽也就是说你可以在 CI 里顺手把 Safari 内核也覆盖了网络拦截能力非常强mock 接口、模拟弱网、伪造请求失败都特别方便。Playwright 还有一个杀手锏它把一键录制用例做得很实用。录出来的代码虽然不能直接用但可以快速帮你生成定位器和操作骨架省掉大量的查文档时间。再加上 trace viewer 能看到每一步前后的页面快照和网络请求排查问题的时候舒服得多。下面这张表是我当年做选型对比时整理的可以直接抄维度SeleniumCypressPlaywright浏览器覆盖全但需自己管理驱动主流跨域场景受限Chromium/Firefox/WebKit 全支持等待策略手动为主自动重试 手动混合内置自动等待心智负担最低调试体验一般时间旅行回放非常强trace 回放 分步截图很强网络 mock依赖第三方库支持但有跨域限制原生支持拦截/伪造/模拟弱网都很顺多标签/弹窗支持较原始支持弱原生支持API 很顺手录制生成代码不如后两者智能有但骨架粗糙智能录制可直接改造成 POM 结构维护成本高中中低我个人的推荐度存量项目才考虑纯前端小团队可用默认选项2.4 选型的底层逻辑谁在维护、多久改一次、跑在哪选型从来不看官网 PPT要看三个现实问题第一这个测试代码多数时候是前端工程师写还是专职 QA 写如果是前端写开发体验和调试体验的权重就要提到最高第二项目里有没有那些很特殊的场景——多个 iframe、跨域、下载文件、桌面通知这些场景一旦存在塞进 Cypress 里可能让你生不如死第三CI 环境是什么如果你们的 CI 是 Docker 化的那 Playwright 的官方镜像就能让你少掉一多半头发。我当时的迁移过程还挺顺利的。先把一条最核心的支付路径用 Playwright 重写跑通以后对比原来的 Cypress 用例发现代码量少了差不多三分之一等待相关的 flaky 问题也明显减少。后面我就把新用例全部写在 Playwright 里老用例用兼容模式慢慢迁。这里提醒一句别想着一次大迁移E2E 是罗盘不是螺丝刀动一点就要稳一点小步快跑才是正道。3. 从零搭建一套能跑的 E2E 工程目录、配置与第一批用例不管你选哪个框架怎么把第一个用例稳定跑起来永远是第一步。这个环节最大的坑不是语法而是工程感——目录怎么分、配置文件怎么写、用例间数据怎么隔离一开始没想清楚后面越写越乱。3.1 初始化与目录设计我以 Playwright 为例初始化可以说简单到令人发指npm init playwrightlatest它会问你几个问题包括是否安装浏览器、是否生成 GitHub Actions 的 CI 配置、是否生成示例测试。我建议第一次就先留着示例跑一遍看看目录结构再说。初始化的工程默认长这样e2e/ ├── tests/ │ ├── example.spec.ts │ └── login.spec.ts ├── pages/ │ ├── login.page.ts │ └── checkout.page.ts ├── fixtures/ │ └── test.fixture.ts ├── data/ │ ├── users.json │ └── seed.sql └── playwright.config.ts目录的核心思想是把用例和实现细节分离tests里只写场景比如用户能用正确账号登录pages里封装页面元素定位和操作这样页面改版时只需要改一处fixtures是扩展测试基座的地方用来注入自定义装置data单独放测试数据的种子和生产方案的快照。3.2 配置文件的那些细节playwright.config.ts是整个工程的心脏我列出几个必须认真对待的配置项import { defineConfig, devices } from playwright/test; export default defineConfig({ testDir: ./tests, fullyParallel: true, retries: process.env.CI ? 2 : 0, workers: process.env.CI ? 4 : undefined, reporter: [[html], [list]], use: { baseURL: process.env.E2E_BASE_URL || http://localhost:5173, trace: on-first-retry, screenshot: only-on-failure, video: retain-on-failure, locale: zh-CN, }, projects: [ { name: chromium, use: { ...devices[Desktop Chrome] }, }, ], });几个容易被忽略的地方baseURL用环境变量覆盖而不是写死保证同一套用例能跑 dev、staging 和 prodtrace建议设成on-first-retry既有现场可查又不会让报告撑爆video和screenshot只在失败时留档节省 CI 磁盘空间。fullyParallel和workers是性能和稳定性之间的平衡键parallel 开太大会让测试互相踩数据开太小又跑太久这个在后面稳定性的章节细讲。3.3 写第一个跟业务有关的用例登录与断言初始化之后不要急着写业务用例先用一条真实场景的登录用例练手。下面这段就是最标准的 POMPage Object Model写法的例子import { test, expect } from playwright/test; import { LoginPage } from ../pages/login.page; import { testUser } from ../data/users.json; test.describe(登录模块, () { test(用户能用正确账号登录并跳转工作台, async ({ page }) { const loginPage new LoginPage(page); await loginPage.goto(); await loginPage.login(testUser.username, testUser.password); await expect(page).toHaveURL(/\/dashboard/); await expect(page.getByRole(heading, { name: 工作台 })).toBeVisible(); }); });对应的LoginPage封装export class LoginPage { constructor(private readonly 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(); } }这套写法的价值在于等哪天登录按钮从登录改成了立即进入你只需要改LoginPage里的那一个 locator所有调用的用例都不用动。断言层用expect的自动轮询机制它会等到元素出现或 URL 变化不要自己写waitForTimeout——固定 sleep 是 E2E 世界里第一号不稳定因子。3.4 跑起来以后立刻要做的三件事第一个用例能稳定跑三次以上以后别急着欢呼先把这三件事做了第一把 trace 打开跑一个故意失败的用例看回放确保失败现场是可查的第二在 CI 里跑一遍试试很多本地通过的用例进了 CI 就开始随机挂了早发现早处理第三把录制的能力交给团队成员试用让大家先写出几个冒烟路径培养手感。这个阶段最容易犯的毛病是过度设计。我见过有人在第一个用例里就引入了几十个抽象类和各种泛型工具函数结果用例还没跑通框架先写了一堆 bug。E2E 的工程结构是长出来的不是设计出来的。一开始保持朴素等出现真实的重复再抽页面对象也不迟。4. profile 档案机制把一套用例跑多个环境从口号变成现实前阵子在一个项目维护群里看到有人抛出 e2e profile1 这个词其实说的就是在 e2e 工程里用 profile配置档案来区分不同的测试场景和运行环境。这个概念非常值得展开。很多人把测试环境只理解成换个 baseURL但真正落地的时候你会发现环境切换牵扯的远远不止一个 URL测试数据不同、用户权限不同、超时时间不同、要不要 mock 外部服务也不同。4.1 先搞清楚 profile 到底管理什么我理解的 profile是把用例运行时的上下文打包成一只开箱即用的盒子。它至少包含四个维度的内容第一是环境信息比如域名、接口网关、CDN 版本第二是数据信息比如一组可用的测试账号、数据库种子数据、mock 开关第三是行为信息比如超时阈值、是否需要跳过某类用例第四是角色权限也就是用游客身份跑还是用管理员、普通会员、被封禁账号来跑。我习惯的命名规则非常简单粗暴profile1就是最基础的那套档案——默认环境加默认测试账号不做任何 mockprofile2开始接入角色的变化比如管理员操作相关用例profile3引入 mock 数据用于不稳定外网依赖的测试。如果后续还有profile4、profile5一定是档案之间出现了一个新的重要维度差异而不是因为无聊。4.2 用 Playwright 的 project 机制实现多 profilePlaywright 里最妙的设计就是projects它相当于把整个测试套件按 profile 拆成群组。每个 profile 可以有自己的testMatch、use配置和依赖关系。下面是我的一套简化配置import { defineConfig, devices } from playwright/test; export default defineConfig({ projects: [ { // profile1默认游客态覆盖冒烟路径 name: profile1-smoke, testMatch: /smoke?.*\.spec\.ts/, use: { ...devices[Desktop Chrome], baseURL: process.env.PROFILE1_BASE_URL || https://staging.example.com, storageState: state/guest.json, viewport: { width: 1280, height: 720 }, }, }, { // profile2管理员后台覆盖权限类路径 name: profile2-admin, testMatch: /admin?.*\.spec\.ts/, dependencies: [setup:admin], use: { ...devices[Desktop Chrome], storageState: state/admin.json, }, }, { // profile3mock 网络覆盖失败兜底类场景 name: profile3-mocked, testMatch: /mock?.*\.spec\.ts/, use: { ...devices[Desktop Chrome], serviceWorkers: block, }, }, ], });storageState是最容易被低估的能力。它允许你把登录后的 cookie 和 localStorage 状态导出成一个 JSON 文件跑用例的时候直接载入这样就省去了每个用例都重新登录的耗时。配合setup类型的 project你可以在跑测试之前先自动登录一次把 token 存进状态文件然后所有用例共享这个状态一石二鸟地解决了登录慢和登录态隔离两个问题。4.3 用环境变量和 dotenv 组合出真实的 profile只靠一个配置文件不叫档案管理真正落地还得接上环境变量。我用的是很传统的方案根目录建一组.env.profile1、.env.profile2之类的文件每个文件存该档案下的所有变量# .env.profile1 E2E_BASE_URLhttps://staging.example.com E2E_USERNAMEplaywright_guest E2E_PASSWORDtestpass123 E2E_USE_MOCKfalse E2E_TIMEOUT30000运行的时候用dotenv-cli指定加载哪个文件比如npx dotenv -e .env.profile1 playwright test好处是配置跟代码分离非工程师的同事也能直接改档案文件不用碰代码。这里有一个我踩过的坑环境变量一定要做成强校验。曾经因为某个人在 profile 文件里多加了一个空格整个 CI 里所有的 mock 开关都失效测试在本地过、在 CI 上随机挂折腾了两天才找到问题。后来我在加载配置的地方加了一个 schema 校验工具任何多余或缺失的变量都会直接报错从那以后这类问题彻底消失。4.4 profile 机制下的用例组织建议档案建好之后用例的组织方式也要跟着调整。我的原则是tests目录下按功能模块建子目录每个模块里的用例文件名都要带上它属于哪个 profile 的标记比如login.spec.profile1.ts、invoice.spec.profile3.ts。这样可以一眼看出这个场景用的是哪套配置排查问题时不用来回翻。另一个重要的点是每个 profile 里都必须有完整的最小冒烟集。也就是说就算profile2是针对管理员的它也应该包含从登录到打开管理后台这条最小路径而不是只跑到管理员特有的功能。因为你换了一个 profile 之后用户角色和权限变了很多基础功能其实是被隐式影响的不跑一遍根本不知道。5. 稳定运行的最后一公里等待策略、数据隔离与 CI 接入的实战坑E2E 最劝退人的地方就是不稳定昨天还好好的今天没改任何代码莫名其妙就红了。我花在这上面的时间比写用例的时间多得多。下面这些都是我拿无数次深夜修用例换来的教训希望能让你少挨几顿折磨。5.1 告别 sleep学会正确的等待姿势新手写 E2E 最常见的问题就是一遇到元素没出现就sleep(2000)这大概是 E2E 里最糟糕的写法。因为它无论元素出没出现都会等够 2 秒用例跑得又慢又不稳定而且一旦网络慢一点2 秒等不到还是照样失败。Playwright 的自动等待其实已经内置了最优解执行点击、填写、断言之前它会自动等待元素稳定、可见、可操作。你要做的不是再补一层等待而是管好自己写进去的等待。很多随机失败其实是气场不对——比如你等了某个按钮但这个按钮是 disabled 的等再久也不会让你点又比如你等了某个 loader 消失但实际上 loader 超时了。正确做法是尽量用expect的轮询断言去等状态而不是等时间// 错误示范 await page.waitForTimeout(3000); expect(await page.getByText(加载完成).count()).toBeGreaterThan(0); // 正确示范 await expect(page.getByText(加载完成)).toBeVisible();第二个版本里的expect会自动重试直到超时元素一旦出现立即通过快的时候几十毫秒就完事。这才是真正稳定的等待。5.2 数据隔离让每条用例活在自己的世界E2E 反模式排行榜第一名就是测试之间共享数据。举个例子注册用例里创建了一个用户叫test01下一条用例恰好依赖这个用户的数据如果注册用例因为网络问题慢了几秒下一条用例就跟着失败。这种级联失败会让人崩溃而且极其难定位。我的解法是每个用例必须拥有独立的数据不依赖执行顺序。具体做法有三个层次第一凡是能通过 API 直接创建的测试数据就在用例开头用 request 接口建好而不是通过 UI 去操作第二给测试数据加上随机后缀或者时间戳比如user_1678293841避免撞车第三复杂数据依赖用前置装置fixture注入比如在 fixture 里造好订单和库存再进入用例。这里还有一个细节很多人不注意玩过测试数据库的都知道千万不能让用例依赖数据库里已经存在的历史数据。数据越少测试越稳定。最好的状态是每条用例启动之前自己的数据从一张白纸开始。5.3 CI 上跑的跟本地完全不是一回事你一定遇到过这种情况本地怎么跑怎么过一上 CI 就随机红。原因其实不玄学——CI 环境是全新的没有你那台电脑里的各种缓存和历史状态CI 机器资源更少页面加载更慢渲染时间更长CI 上跑的是 headless 浏览器有些依赖 GPU 或者特殊字体渲染的页面会表现异常另外 CI 大概率开启了并行 worker多个用例同时跑点数派发和数据隔离一旦没做好就很容易互相干扰。我的实战经验是把下面几条写进硬性规范CI 里workers不要拉满给个 3 到 4 就行并行太快是随机失败的头号温床retries设成 1 到 2 次允许偶发网络抖动但超过两次还失败就说明真有问题了CI 机器的时区、语言、字体全部固定用一个统一的docker镜像跑我在镜像里甚至把中文字体都预装好了就为了截图的时候不出现方块字。还有一条非常实际的建议跑完 CI 以后务必要在报告里保留完整 trace 和截图。没有现场证据的失败报告等于没有报告你会被迫一次又一次地无脑重跑浪费时间。trace 里的网络瀑布图和页面快照能直接指向问题所在。5.4 headless 模式下的那些小怪异headless 模式下最容易踩到的坑是页面动画不会正常结束或者某些元素在 headless 里不可见。有个项目页面上的 loading 效果用的是 WebGL在 headless 环境下渲染不出来导致expect(loader).toBeHidden()一直失败。最后只能在配置里对特定用例禁用 WebGL 特性或者用--disable-gpu参数统一处理。另一个常见问题是布局影响点击坐标。Playwright 默认用元素中心点点击如果页面在 headless 下因为字体差异导致了布局偏移有些元素会被遮挡住点击就会失效。解决办法只有一个定位器尽量用语义化定位器getByRole、getByLabel不要用坐标偏移操作。依赖坐标的用例几乎等于一颗定时炸弹页面任何布局调整都会炸到你头上。6. E2E 用例的精力管理哪些值得自动化哪些写了就是负资产最后这部分我想聊聊很多技术文章不太会明说的话题E2E 用例不是越多越好。一个团队每天的维护精力就那么多如果这个精力被大量低价值用例吃掉真正该保住的业务核心反而会失守。6.1 高价值用例的清单核心旅程优先我内部有个简单的判断标准一条用例值不值得写取决于三个问题的答案。第一这条路断了用户会不会直接骂娘第二这条路跨了几个模块单测能否覆盖到第三这条路径是不是每周都在变如果三个问题里至少有两个是肯定的那它值得写。如果三个都是否定的我建议你把它从计划表里划掉。在我的项目里高价值清单永远是这几类注册和登录全流程、支付全流程包括支付失败、取消支付、核心链路的状态流转比如订单从待支付到已发货的所有状态、权限边界比如非会员访问会员专享页面必须被拦、数据导入导出类功能。这五类只要没有严重回归问题业务就基本不会崩。6.2 低价值用例的黑名单写它就是害自己反过来下面这几类我强烈建议不要写文案和视觉细节的断言比如说某个按钮文案必须是立即下单——这种断言每次营销改词都会红没有任何回归价值一次性活动页面的用例活动下线后用例就成了尸体跟外部第三方系统深度耦合的流程除非你能稳定 mock 第三方否则你每次都在赌对方的系统不出问题高频变化的 UI 组件库内部的样式级改动那是组件库自己单测的事不是 E2E 的事。还有个特别容易被忽视的坑给错误状态写用例时别把异常路径的边界拉得太宽。比如验证某个表单要写同一个字段的几十种非法输入这是单元测试该干的事。E2E 只需要验证最典型的错误提示能出现就够了剩下的交给下面两层不然测试套件会膨胀到没人敢改代码。6.3 给用例定期体检失败率、维护频率和丢弃机制E2E 套件跟人一样要定期体检。我每两周会看一眼所有用例的统计整体运行时长是多少、失败率前五名是谁、最近有没有用例被高频修改。如果一条用例连续一个月都出现在失败率前五而且每次失败原因都是定位器选择器变了那大概率不是用例的问题而是它本来就不该存在。我习惯给每条用例打一个健康分权重是运行时长占 30%最近一个月的失败次数占 40%被修改的次数占 30%。低于某个分数的用例我不会急着删除而是先在项目里标注为skip一周。如果一周内没有业务方跑来找它就说明它已经死了直接删除不需要留恋。这招看起来很粗暴却能有效阻止 E2E 套件在无人关注的情况下一路膨胀到没法维护。6.4 长期维护的节奏感还有一个心法层面的东西想分享E2E 不是一次性投入它更像是整个团队对质量底线的集体习惯。你不需要每周都加一堆新用例但每周都应该花一点时间看它绿不绿、有没有随机失败、有没有新功能产生了新的核心路径。测试代码和业务代码一样需要 code review需要重构需要有主人。没有主人的 E2E 项目早晚会烂尾。我个人现在的节奏是功能开发时决不写 E2E等这个功能上线稳定两周确认不会被回炉重造再回来补核心路径。很多团队把 E2E 当成开发的最后一步催着同事功能写完顺便把用例写了结果功能还在改用例就得跟着改越改越乱最后直接放弃。让 E2E 晚半拍进场看起来是慢实际上是最快的路径。7. 最后再分享一点我的真实体会如果让我总结做 e2e 这几年最重要的领悟大概就是端到端测试不是工具问题也不是技术问题它首先是取舍问题。你得承认它的昂贵然后谨慎地把它用在最值钱的地方你得接受它会有偶发失败然后构建好排查机制而不是一红就慌你得让整个团队都理解这条用例在保护什么否则再漂亮的测试工程也会在忙碌中被悄悄废弃。还有一个很实际的小建议送给你不管你的团队有多忙请一定在最早阶段就把 trace 和截图机制打开。我遇到过太多次线上事故当时唯一能还原现场的就是 CI 里留下的那个带着所有请求记录的 trace 文件它比任何日志都有说服力。哪天你会感谢当初花十分钟打开这个开关的自己。
