★ FEATURED ARTICLE 端到端测试这几年几乎成了质量保障团队的标配但真把它讲清楚、做到位、能长期跑下去不被废弃的团队其实不多。很多人嘴上说的「e2e」实际是拿 Selenium 写了一堆脆弱的脚本跑一次红一片最后不了了之。这篇文章我想认真聊聊 e2e 到底在测什么、怎么选工具、怎么把一套配置化的执行方案比如很多团队在用的 profile1 这种固定档案真正落地并把我在维护端到端用例过程中反复踩过的坑一并整理出来。无论你是刚接触测试自动化的开发还是已经在维护一套用例但天天被 flaky 折磨的测试工程师这篇都值得看完。1. 先搞清楚一件事e2e 到底在测什么1.1 从测试金字塔说起软件测试里有个特别经典的分层概念测试金字塔。最底层是单元测试覆盖的是函数、类这种最小粒度的逻辑单元中间层是集成测试验证模块与模块之间的协作最顶层就是端到端测试也就是 e2eend-to-end。金字塔之所以长成塔形是因为越往上测试的覆盖范围越广但执行速度越慢、稳定性越难维护、排查问题越麻烦。单元测试跑几千个用例可能只要几十秒e2e 跑一条核心链路可能就要一两分钟。成本完全不同。那为什么我们还需要 e2e原因很简单单元测试和集成测试都验证的是「局部正确」但用户的体验是跨越整个系统的。用户在前端点一下「下单」按钮背后要经过前端表单校验、接口请求、网关路由、鉴权、库存扣减、订单状态流转、支付回调、消息通知……任何一个环节出了问题用户看到的就是「下单失败」。我在很多项目里见过这种情况单测覆盖率百分之八十以上集成测试也顺手做了但每次发版前手工回归还是要点出各种问题。缺的就是端到端这一层——它把所有模块串起来以用户的视角在真实环境里走完整条业务流。你可以把它理解成单测是在检查发动机的每个活塞而 e2e 是把整车开上路跑一圈跑完才知道这车到底能不能开。1.2 e2e 最常见的三种误用我见过太多团队在 e2e 上翻车翻车原因往往不是工具问题而是认知问题。有三种误用最常见第一把全站所有功能都写成 e2e。一个后台管理系统可能有几百个页面每个页面都要走一遍增删改查全写成端到端用例最后执行时间几个小时维护成本远超收益。e2e 的定位是「覆盖核心链路」不是「覆盖所有功能」。第二用 e2e 代替单元测试。连一个函数里的字符串拼接都要通过浏览器交互去验证这是本末倒置。e2e 是兜底不是主力。第三只在手工点一遍没有自动化落入回归。说白了手工回归也是一种 e2e只是它是人肉执行的。人肉执行的问题是不可重复、费时费力、还会漏。真正该做的是把这套最核心的回归流程固化下来变成每次发版前自动跑的脚本。那什么叫核心链路我的判断标准很简单这条链路如果断了用户会立刻感受到且无法绕过。比如前端项目的注册登录、加购下单、支付回调、订单查询比如管理后台的登录、数据导入、权限变更。每条核心链路走通e2e 的价值就发挥了百分之八十。2. 工具选型为什么我强烈推荐 Playwright2.1 主流 e2e 工具横测提到 e2e 工具绕不开三个名字Selenium、Cypress、Playwright。很多人选型时犹豫不决我先给个对比表把关键维度列清楚维度SeleniumCypressPlaywright浏览器支持Chrome、Firefox、Safari、Edge 等能力最全仅 Electron 内置和 Chrome 系对 Firefox/Safari 支持弱Chromium、Firefox、WebKit 三套内核通吃执行环境浏览器进程外驱动可跨域、跨标签页运行在浏览器内跨域场景受限进程外驱动自带多标签页、多浏览器上下文自动等待基本没有需要大量手工显式等待内置 DOM 自动重试内置 Actionability 自动等待默认就稳网络拦截能力较弱依赖第三方库可通过 cy.route 拦截原生 page.route()可 mock 任意请求调试体验一般靠截图和日志时间旅行回放体验很好Trace Viewer 看完整录屏网络DOM 快照测试隔离各 driver 自行管理自动清空应用状态context 级隔离干净彻底这个表格只是帮大家建立全局认知。真到选型的时候我建议不要只看功能列表而是看你的团队实际痛点在哪。2.2 我选择 Playwright 的几个关键理由我在实际项目中三套工具都用过最后长期用的是 Playwright。不是因为另外两个不好而是 Playwright 几乎把 Selenium 时代最痛的几个问题全部解决了。第一个是自动等待。用过 Selenium 的都知道最痛苦的就是Thread.sleep(2000)这种写不完的等待逻辑。网络一慢sleep 不够就挂网络一快sleep 又白白拖慢执行时间。Playwright 内置了 Actionability 校验它会在执行点击、输入、填写操作之前自动等待元素可见、可交互、不抖动不需要你手工 sleep。这个机制极大减少了 flaky。第二个是登录态复用。很多 e2e 用例需要登录如果每条用例都走一遍登录流程不仅慢还会增加失败点。Playwright 提供了storageState你只需要在测试启动时保存一次登录后的 cookie 和 localStorage后续所有用例都可以直接加载这个状态跳过登录步骤。这个功能我在第 5 节还会细讲。第三个是调试体验。Playwright 的 Trace Viewer 会把整个测试过程录下来包括页面截图、DOM 快照、网络请求时间线。用例失败后打开 trace你能像回放视频一样看每一步发生了什么而不是对着一个模糊的堆栈猜。这个能力在排查偶发失败时几乎是无价的。还有一个很实用的特性是page.route()它允许你在测试里直接拦截并 mock 网络请求。比如测试下单流程时不希望真的调用第三方支付接口直接 mock 一个返回结果就行。这样 e2e 既能测全链路又不会受外部依赖牵制。2.3 如果团队里存量是 Selenium要不要迁如果你们团队已经有大量 Selenium 用例我建议不要做「推倒重来」式的迁移那个成本和风险都太大。更稳妥的路径是先把核心链路用 Playwright 写一套 profile1 配置作为每天的冒烟测试跑起来跑稳以后再把周边不那么重要的 Selenium 用例逐步转移过来。迁移不是特别复杂因为 Playwright 和 Selenium 的测试模型在很多层面是相似的——都是驱动真实浏览器做操作、做断言。但你能明显感受到 Playwright 的 API 设计更贴近现代前端比如getByRole这种语义化定位比原来 XPath 一长串//div[class...]稳太多。这套迁移做完之后团队日常维护用例的幸福感会提升一个档次。3. 实操落地从零搭一个能跑的端到端项目3.1 环境准备与依赖安装说再多理论不如直接上手。这里的实操我以 Node.js Playwright 为例这是目前社区最主流的组合Windows / macOS / Linux 都能跑。第一步准备环境。你需要一个 Node.js 环境版本建议 18 以上。如果没有装 Node先去官网下载 LTS 版本装好命令行里能跑node -v看到版本号就行。第二步初始化项目。打开终端新建一个目录并初始化 npm 项目mkdir e2e-demo cd e2e-demo npm init -y第三步安装 Playwright 测试框架npm install -D playwright/test第四步装浏览器内核。Playwright 不像 Selenium 用系统自带浏览器它自带各内核的下载工具npx playwright install注意如果你在 CI 环境比如 Jenkins、GitLab CI里跑推荐用npx playwright install --with-deps它会自动把浏览器依赖的系统库一起装好否则很多 Linux 容器里会因为缺基础库导致浏览器起不来。装完之后项目里基本配置就绪了。我习惯再建两个目录tests放用例playwright-report放报告输出这样结构清晰CI 里也方便归档产物。3.2 写第一个真正有业务价值的用例很多人入门时跑来跑去都是在测一个没有业务逻辑的页面这其实没意义。我直接用一个登录 加购的场景来讲这是每个电商系统都有的核心链路。先创建一个测试文件tests/checkout.spec.tsimport { test, expect } from playwright/test; test.describe(核心下单链路, () { test(用户登录后可以添加商品到购物车, async ({ page }) { // 打开登录页 await page.goto(/login); // 使用语义化定位器输入账号密码 await page.getByLabel(用户名).fill(testuser01); await page.getByLabel(密码).fill(passw0rd123); // 点击登录 await page.getByRole(button, { name: 登 录 }).click(); // 断言登录成功页面上出现用户昵称 await expect(page.getByText(欢迎回来测试用户)).toBeVisible(); // 搜索商品并进入详情 await page.getByPlaceholder(搜索商品).fill(机械键盘); await page.getByPlaceholder(搜索商品).press(Enter); // 点击第一个商品 await page.locator(.product-card).first().click(); // 加入购物车 await page.getByRole(button, { name: 加入购物车 }).click(); // 断言购物车中的数量 await expect(page.locator(.cart-badge)).toHaveText(1); }); });这段代码有几个关键点值得展开说明。一是定位器用了getByLabel、getByRole、getByPlaceholder这类语义化 API而不是#username这种 CSS 选择器。原因很简单标签和按钮的可访问性语义通常比 class 稳定。开发改样式改 class 不会影响用例但改文字或 label 时你能清楚感知到是要改测试的。二是用了自动等待。我没有写page.waitForTimeout(3000)Playwright 会在click()和expect内部自动重试直到元素可交互或超时。这个默认能力只要不关掉就是用例稳定性的最大保障。三是断言的内容是「用户能看到什么」。我不是在检查 DOM 结构里某个 div 的 class而是检查登录后出现的欢迎语、购物车角标的数字——这些才是真实用户感知的业务结果。你可能已经注意到page.goto(/login)用的是相对路径。这个就是配合第 4 节要讲的 profile1 配置来用的不同的 profile 指向不同的环境地址但用例代码完全不用改。3.3 让人又爱又恨的断言设计断言写得好不好直接决定调试成本。我见过很多同学喜欢加一堆「过于精细」的断言比如检查某个按钮的 CSS 颜色、某个元素的 class 名称、某个文案的字号。这类断言和业务没有关系一旦前端微调样式就挂毫无意义。真正该断言的是业务结果和用户状态。加购成功要断言购物车数量变成 1支付成功要断言订单状态变成「已支付」退出登录要断言跳回了登录页、用户区不再可见。这套思路再往前推一步就是你的断言要让非开发人员也能看懂业务流程当前走到哪一步了。还有一个经验断言不需要多但每条都要稳。一条 e2e 用例里 3 到 5 个关键断言足矣。断言越多失败排查越难——你不知道是第几步出了问题还是前面的操作已经歪了。4. 把 profile1 用起来配置化的端到端执行策略4.1 profile1 是什么为什么需要它很多团队在做端到端测试时会遇到一个结构性问题同一个用例要在不同环境跑还要按不同节奏跑不同范围的用例。今天要在 SIT 环境跑冒烟明天要在 UAT 环境回归早高峰还要在预发环境跑一遍全量。如果每次手动修改配置文件不仅容易改错还无法在 CI 固化流程。「profile」这种叫法在 e2e 实践里越来越常见它是把一组固定配置打包成一个可命名的档案。profile1 通常指的就是第一套基础配置——核心链路冒烟档案它默认指向测试环境、只跑打了smoke标签的用例、超时时间更短、失败重试一次。后面还可以扩展 profile2 做全量回归、profile3 做性能冒烟。一个 profile 至少包含以下内容基础地址baseURL超时与重试策略跑哪些测试文件 / 哪些标签并发 worker 数量是否开启 trace 和截图需要加载的登录态文件storageState环境变量测试账号、支付 mock 开关等这样设计的好处是测试代码是一份但可以用不同 profile 在不同场景里执行不需要复制粘贴用例也不需要跑之前手动改环境地址。4.2 配置文件怎么写在 Playwright 中profile 通过配置文件里的多个projects来声明。下面是一个实际可用的playwright.config.tsimport { defineConfig } from playwright/test; export default defineConfig({ testDir: ./tests, timeout: 30_000, expect: { timeout: 5_000, }, retries: 1, workers: 4, projects: [ { name: profile1, grep: /smoke/, use: { baseURL: process.env.E2E_BASE_URL || https://sit.example.com, storageState: ./auth/sit-user.json, trace: retain-on-failure, screenshot: on, }, }, { name: profile2, grep: /regression/, use: { baseURL: process.env.E2E_BASE_URL || https://uat.example.com, storageState: ./auth/uat-user.json, trace: on, screenshot: only-on-failure, }, }, ], });这个文件里grep是 Playwright 的标签过滤机制。在用例文件中你可以这样打标签test(登录后下单 smoke, async ({ page }) { // ... });也可以直接写test.describe(核心链路, { tag: smoke }, () {})一个 describe 下的所有用例都会继承标签。标签体系建议越小越准越好smoke、regression、weekly不要造出十几套标签自己都记不住。这个配置还有一个细节值得关注storageState。它是我们之前说的登录态复用实际做法是先跑一个「登录脚本」生成 cookie 快照文件然后 profile1 里所有用例都自动带上了登录态不用每次走一遍登录流程。4.3 执行方式与报告输出配置好之后执行就是一条命令的事# 跑 profile1 的冒烟用例 npx playwright test --projectprofile1如果你想把 profile1 作为每天 CI 的固定环节只需要在流水线里调用这条命令并加上 HTML 报告生成参数npx playwright test --projectprofile1 --reporterhtml跑完以后playwright-report/目录下会生成一个可交互的 HTML 报告里面包含每个用例的执行时间、步骤、截图、失败堆栈。你可以把这个报告作为一个构建产物挂到 CI 的 Artifact 里团队所有人点开就能看到当天核心链路是否健康。我这里贴上实际项目里 profile1 的惯用配置参数清单配置项profile1 建议值说明baseURLSIT 环境域名冒烟环境要求数据稳定、恢复快retries1偶发失败自动重试一次但不要依赖重试掩盖问题timeout30 秒核心链路每一步 30 秒内必须完成workers4~8并发不宜过高防止压垮测试环境traceretain-on-failure失败才保留 trace节省空间screenshoton每一步截图排查时非常有用这个体系跑起来之后团队对「线上回归」的焦虑会明显下降因为发版前只要看 profile1 这个报告就够了。5. 常见问题与排查技巧实录5.1 偶发性失败flaky—— e2e 的头号杀手如果你在用 e2e迟早会遇到同一个用例昨天全绿、今天红色一条点进去看又没有任何代码改动。这种偶发失败是 e2e 维护路上的最大劝退因素。我见过的团队从「每天跑」变成「每周跑」再变成「不跑了」几乎都是被 flaky 逼的。排查 flaky我有一套固定顺序。第一看失败时的 trace 和截图重点关注断言失败前那一刻 DOM 的状态——是不是弹窗被什么东西挡住了是不是输入框里文字没填进去第二看网络请求时间线有没有接口响应超过 5 秒导致页面空白第三看测试环境数据是不是上一个用例留下的脏数据影响了当前用例flaky 的主要原因分布也很有规律时序问题元素出现但还没稳定、接口慢加载、共享数据被污染、弹窗遮罩、动画未结束。对应到 Playwright 中绝大多数时序问题会被自动等待吸附掉所以如果你还常遇到 flaky先检查自己的代码里有没有手动写waitForTimeout或者用了过脆的定位器。5.2 定位器太脆一改前端就挂很多团队测试维护成本高根子出在定位器上。以前 Selenium 时代大家习惯写driver.findElement(By.xpath(//div[classnav]/ul/li[2]/a))这种定位只要前端多套一层 div 就废了。Playwright 帮我们引入了更好的习惯但不能指望框架自动消除坏习惯。我的建议是建立一套团队约定优先用getByRole、getByLabel、getByText这种语义化定位其次是>!-- 前端在关键的交互元素上加一个稳定的 testid -- button>// 测试代码里这样定位 await page.getByTestId(submit-order).click();>import { test } from playwright/test; test(生成登录态文件, async ({ page }) { await page.goto(/login); await page.getByLabel(用户名).fill(testuser01); await page.getByLabel(密码).fill(passw0rd123); await page.getByRole(button, { name: 登 录 }).click(); // 等待登录完成保存 storageState await page.waitForURL(/home); await page.context().storageState({ path: ./auth/sit-user.json }); });跑一次这个 setup后面所有用例通过配置文件里的storageState自动带上登录态。注意这个 json 文件里存着 cookie 和 localStorage我强烈建议把它加入.gitignore并在 CI 里每次跑之前重新生成——因为不同环境的账号、token 有效期可能不同离线文件过期后会造成一堆诡异失败。5.4 测试数据与环境隔离该花的钱不能省e2e 还有一个资深从业者都知道的痛共享环境。如果你把 e2e 跑在开发手动的公共 SIT 环境上基本每天都会有不可控的失败——有人改了配置、有人造了脏数据、有人删了测试账号。这不是测试代码问题是环境治理问题。profile1 这类冒烟档案对应的环境我建议要么是独立的一套部署要么至少是数据恢复能力强的环境能在每次执行前清空并重建测试数据。很多团队会觉得「为了测试搭独立环境太奢侈」但算一笔账就明白了一个测试同学每周花五个小时排查共享环境导致的用例失败一年下来两百多个小时的工时比一台测试机的成本高多了。5.5 常见问题速查表最后把我实际维护过程中遇到频率最高的几类问题整理成一个速查表方便大家在下次用例报红时按图索骥现象常见原因排查方向推荐做法用例偶发超时接口慢、动画阻塞、长列表未渲染看 trace 中断言前页面状态增加 expect 超时或先断言中间产物点击按钮无反应遮罩层挡住、元素被加载中状态覆盖浏览器里手动复现看元素是否可交互用expect(button).toBeEnabled()前置断言定位器匹配到多个元素页面存在同 name 按钮或同文本组件检查失败信息中的 strict mode 报错用first()或限定范围内的 locator登录状态失效storageState 过期、token 过期看报错是否停留在登录页重新生成 storageState 文件环境数据被污染共享环境下前序用例改了数据对比失败用例和共同数据独立环境 用例前后数据清理本地跑通过CI 挂系统依赖缺失、并发抢占资源看 CI 日志中浏览器启动报错CI 里用--with-deps安装系统库5.6 让 e2e 可持续运行而不是一次性玩具我最后想分享一个关于团队协作的观察。很多团队引入 e2e 的第一周斗志昂扬每天看报告、修用例第二周开始用例偶发波动开始有人烦第三周红了一片没人处理变成了「反正它老挂」第四周有人在小群里提议「先把 e2e 停掉吧」。这不是技术问题是可持续运营问题。要避免这个滑铁卢我有几个实操建议。一是不要把 profile1 的通过率当作团队 KPI而是把它当作「核心链路健康体检」红了就去查查出来的 bug 要直接关联到具体负责开发。二是每周留出固定时间处理 flaky 用例要么修稳定要么删掉测试用例和产品代码一样债务不还只会越滚越大。三是新人加入团队的第一周就让他跑一遍 profile1理解核心链路和失败排查流程这样维护责任不是集中在一个人身上。我在实际维护这套用例时最明显的感受是e2e 不是用来「找 bug」的它是用来「兜底」的。单测和集成测试负责细致e2e 负责最后那一下整体性校验。只要你把 profile1 这类档案的配置逻辑理顺把环境和数据问题治理好它就能变成团队手里最可靠的一条质量底线。说到底写 e2e 本身不难难的是你能不能让它一直稳定地跑下去——而这恰恰是它最有价值的地方。
阅读完成 · 觉得有帮助？
