★ FEATURED ARTICLE 1. 我为什么从写了就死的e2e调到越跑越稳的e2e先讲一段真实经历。去年年初我接手了一个电商中台项目团队里早就有e2e用例数量不少几百条但CI里常年一片红。最离谱的一次下单主流程挂了整整两天没人发现——因为e2e跑得太随机今天过明天挂大家都默认这玩意就是碰运气。后来排查原因居然是一个按钮文案从确认支付改成了立即付款用例里写死了旧文案冒烟直接失败。而这正是e2e最尴尬的死法它明明在帮你守质量底线结果先把自己的命搭进去了。所以当热搜词里反复出现e2e、e2e profile1的时候我大概能猜到很多人正在经历我走过的阶段要么刚准备上e2e不知道怎么设计要么已经上了但用例和测试环境互相折磨维护成本高到想删库跑路。这篇我把自己从零搭建端到端测试体系的全过程拆开讲包括用例怎么设计、profile配置怎么玩、稳定性怎么治理、CI怎么接入。老实说跑稳定一套e2e并不难难的是想清楚每一步为什么这么做。适合正在搭e2e体系、或已有一堆flaky test不知道从哪下手的团队参考。我反复跟团队强调一个观点e2e不是银弹它是一张安全网。它的价值不应被覆盖率量化而应该被能不能把用户主流程的回归成本降下来量化。做e2e的前提是先接受它一定是贵这个现实——脚本维护贵、运行耗时贵、环境要求贵。贵不怕怕的是贵得没价值。想让e2e物有所值就要在用例设计、profile隔离、稳定性治理上花功夫。下面我把这几块逐一展开。2. e2e用例生存现状三种死法以及它们的根因2.1 死法一把e2e当成单元测试写用例多到跑不完很多团队接手e2e第一反应是把所有接口场景、所有分支逻辑都用e2e跑一遍。我见过一个后台管理系统e2e用例400多条每条都要走完整的登录→菜单→操作→断言流程跑完两小时起步。问题在于很多逻辑分支用单元测试或服务层测试几毫秒就能验证完非要放到浏览器里跑一遍纯粹是给CI加刑。根因是对e2e覆盖范围没有共识。我做了一个简单的分层约定测试层级关心的对象典型工具执行速度成本单元测试函数/类逻辑Jest/Vitest毫秒级低服务/集成测试接口、数据库、消息队列Testcontainers/Supertest秒级中e2e测试用户真实操作路径Playwright/Cypress分钟级高分工很清晰单元测试管算法和纯函数服务测试管接口和数据流转e2e只管用户在浏览器里能不能把事情办成。有了这个约定团队里再没人拿浏览器去测价格计算边界这种活e2e用例量自然收敛到健康的范围。我建议的标准一个产品主流程关键分支控制在20~40条e2e跑完10分钟以内是可接受的超过这个量先砍用例而不是加机器。2.2 死法二选择器随前端重构成天崩修用例比写新功能还累这是项目里最常见的抱怨。前端组件库升级、DOM结构调整、React/Vue版本迭代往往一夜之间几十条用例全部阵亡。不是业务坏了是#app div .content .btn-primary这种选择器路径断了。团队越用标签名、CSS类名甚至内联style去定位元素后续维护成本越高。根因是把定位元素和模拟用户搞混了。用户不看CSS类名用户看到的是按钮上写着立即付款。所以e2e定位元素的正确姿势是尽可能模拟用户视角用可访问性角色、标签文本、name属性去定位而不是依赖结构和样式。项目里推了一条规定前端所有可交互核心元素必须带>Given 一个已登录用户购物车中已有1件商品 When 用户在结算页点击去结算 And 填写收货地址通过测试数据工厂生成 And 选择在线支付并提交订单 Then 系统生成订单号 And 页面跳转至支付页 And 支付成功后页面展示支付成功状态 And 订单中心能看到该订单这条用例覆盖了至少四个模块购物车、结算、支付、订单中心任何一个模块之间配合出问题它都会变红。这才是e2e的核心价值不能只验证局部功能正常要验证跨模块协同下用户真的能办成事。3.2 一条用例只讲一个故事但故事要完整我的另一个原则是一件用例只验证一个完整的用户目标不要在中间插太多无关的额外断言。比如在上面这条下单用例中不要在支付成功之后顺手去点开个人中心→我的优惠券再看看优惠券列表那属于另一个故事应该放到独立的用例里。为什么因为一旦用例变长排查失败时你很难快速区分是主流程挂了还是附加步骤挂了。此外附加的步骤往往依赖额外数据准备又给用例增加了一分不稳定性。我还建议在用例命名时直接表达用户价值不要用抽象的测试编号。比如test_order_payment_success就比test_case_001_payment清晰得多。好处是当CI跑挂的时候任何人看到用例名就能判断影响范围不用点进去读代码。对长期维护的团队来说这比什么都重要。3.3 借力数据工厂和API预置别傻傻走UI造数据新同学常犯的一个错误是用例一开始就用UI去注册用户、去后台创建商品、去个人中心添加收货地址一步不到位后面全白跑。正确做法是能用API预置的数据就不要走UI。UI操作既慢又脆弱能通过接口直接创建的测试夹具就通过接口直接造出来。我们项目里维护了一个专门叫test-data-api的模块封装了创建测试用户创建已登录会话创建带商品购物车创建指定状态订单等方法。用例里是这样用的Given 一个通过API创建的已登录用户默认带一张优惠券 And 该用户购物车中有1件商品通过API预置然后UI上只走当次要验证的那段路径前面的铺垫全部由API完成。这样单条用例的执行时间可能从3分钟降到40秒稳定性也会大幅提升。核心逻辑是e2e不要去做所有事情而是只做你要验证的那个用户体验切片。3.4 反面教材为覆盖率而堆页面冒烟用例为了说明白为什么20条比200条更有效我再举一个反面案例。某个模块文档页有50多个字段团队为了追求每个字段都验证写了一堆e2e每个字段都要准备不同类型的数据、处理各种空态。结果就是维护成本爆炸每次后端改个字段类型前端改个labele2e全红。而真正的用户主流程——从列表点进详情看到信息能发起申请——反而没有一条完整用例。后来我把那批字段级用例全部删除只保留两条一条是详情页正常展示各区块信息另一条是在详情页发起点申请并成功。剩下的验证交给组件测试和服务测试去覆盖。改造之后e2e执行时间少了60%CI红蓝率反而显著改善。所以每次有人问我e2e用例数量指标我的标准回答都是先衡量用例覆盖了多少用户目标而不是覆盖了多少页面元素。4. profile机制不是玄学多环境、多账号、多场景的一键切换4.1 什么是e2e profile以及它解决了什么问题说回热搜词里的e2e profile1。很多人看到profile会以为这是什么高深概念其实它就是一组命名的e2e配置集合。一个profile通常包含指向哪个环境baseURL、用哪套账号、加载哪份测试数据、使用什么浏览器规格、设置多长的超时、跑哪些标签的用例等。我最初被profile这个概念吸引就是因为它解决了团队里一个特别痛的场景同一套e2e源码要在本地环境、测试环境、预发环境各跑一遍但每个环境的账号、域名、支付配置全不一样。没有profile之前每次切换环境都要改配置文件再跑改着改着就忘了恢复直接把配置推到CI把大家全坑了。有了profile后整个项目通过不同的--profile参数就能在任意环境一键执行代码本身完全不用动。从工程化的角度来说profile把环境差异这个维度从测试代码中抽离出来有点像后端开发里的多环境配置文件dev/prod但粒度更细它甚至可以支持同一个环境中不同角色账号的切换。4.2 一套最小可用的profile实现我用Playwright作为e2e框架来演示。如果你用的Cypress或者其它框架思路完全相通只是配置文件的写法不同。我的项目里有一个playwright.config.ts作为基座配置然后为不同profile写了独立配置。核心思路是不同profile共用大部分配置只覆盖少量差异化字段。// playwright.config.ts import { defineConfig } from playwright/test; const baseConfig { testDir: ./tests, timeout: 30_000, retries: process.env.CI ? 1 : 0, workers: process.env.CI ? undefined : 1, use: { baseURL: process.env.E2E_BASE_URL || http://localhost:3000, viewport: { width: 1280, height: 720 }, screenshot: only-on-failure, video: retain-on-failure, trace: retain-on-failure, }, }; export default defineConfig(baseConfig);// playwright.stage.config.ts import { defineConfig } from playwright/test; import baseConfig from ./playwright.config; export default defineConfig({ ...baseConfig, timeout: 45_000, use: { ...baseConfig.use, baseURL: https://stage.example.com, storageState: ./.auth/stage-user.json, }, });在package.json里加上脚本{ scripts: { e2e:local: playwright test --configplaywright.config.ts, e2e:stage: playwright test --configplaywright.stage.config.ts, e2e:prod-smoke: playwright test --configplaywright.prod.config.ts --grep smoke } }这样我和团队同学执行npm run e2e:stage就能自动跑到预发环境不用再手动改baseURL。处于e2e profile1这类场景中的你多半也是想解决本地、测试、生产云环境的切换问题上面这套配置可以直接抄。4.3 profile里该放哪些差异化内容实践中我会把以下几类内容放进profile配置项说明示例baseURL环境入口https://dev.example.comvshttps://stage.example.com账号体系各环境角色账号、登录态storageState指向不同用户的JSON文件数据策略该环境预置数据、清理策略数据库连接串/API base地址超时与重试慢环境用更长超时CI用retrytimeout: 45s、retries: 2标签过滤各profile跑不同用例集--grep smoke只跑冒烟浏览器特性开启/关闭无头模式headless: false用于本地点调试特别提醒一个坑不要把测试账号密码硬编码在代码库里。账号信息应当通过环境变量或安全配置中心动态注入storageState这类文件也不要提交到git仓库而是通过CI的secrets生成。我在早期项目里犯过这个错账号密码直接写在配置里结果同事在GitHub上凭着仓库历史就能看到安全风险极大。后来统一改成运行时从环境变量读取既安全又方便不同环境复用同一套profile。4.4 profile引发的两个常见问题配置漂移和忘记打tagprofile用习惯了之后也会出现新问题。第一个是配置漂移有人临时在小本子上改了一个环境变量跑通了后续步骤里有一步依赖那个临时变量过了几天别人再执行同样命令配置已经不存在了用例就莫名其妙的挂。解决办法是给每个profile配上环境自检步骤在跑用例之前先请求几个关键接口登录、商品接口、配置接口如果返回结果不符合预期就立刻fail fast把环境不对这个问题提前暴露而不是等到跑完50条用例再告诉你全挂了。第二个常见问题是用例忘记打tag导致在某个profile里被过滤掉或者被多跑。比如--grep smoke就是只跑打了smoke标签的用例一个关键主流程用例没打标那么prod环境的冒烟就漏检了。为应对这个问题我在CI里加了一个tag覆盖率检查的小脚本每次跑全量用例时统计所有用例的tag分布如果存在一条关键用例没有任何tag就警告。虽然看起来多此一举但真的阻止过好几次上线前漏测。5. 稳定性治理别用sleep对抗竞态学会等一切可等待之物5.1 固定等待是e2e里最贵的偷懒我见过最典型的flaky写法是await page.waitForTimeout(5000);注释写着等页面加载完成。问题是5秒真的够吗网络慢的时候可能10秒才出数据网络快的时候2秒就出来了你永远在赌一个下限。更糟糕的是这类固定等待堆多了之后单条用例执行时间被无限拉长整个e2e套件慢得像爬。解决这个问题的核心思想是**等一切可等待之物**等元素可见、等文本出现、等网络请求返回、等某个API可调用、等某条DOM移除。一切用状态判断而不是用时间猜。以Playwright为例它内置了web-first assertionexpect会自动等待直到元素满足条件默认超时5秒。这比手写waitForTimeout可靠得多// 不推荐盲等5秒 await page.waitForTimeout(5000); expect(page.getByText(支付成功)).toBeVisible(); // 推荐等到元素真正可见 await expect(page.getByText(支付成功)).toBeVisible({ timeout: 10_000 });上面这个例子看着简单但背后是一个很重要的认知转变e2e调试的重点不是把等待时间调长而是把断言语义写准。一旦暴露出来的条件是明确的——支付成功文本可见那框架就该自动轮询等这个条件出现而不是程序员手动估算一个时间。这样既不会误报也不会无谓地拉长用例时间。5.2 flaky测试排查的标准链路trace比截图管用得多不管怎么写总会遇到偶发失败。过去没有trace的时候排查一个偶红用例要翻视频、翻日志、翻网络请求几个人凑一块猜。现在我统一采用这个排查链路打开CI失败记录的trace——看每一步的DOM快照和网络请求——对比成功跑和失败跑两次的差异。trace里能看到浏览器里具体发生了什么哪个选择器没找到哪个请求超时了哪个页面报错了定位效率比看截图高十倍。排查完的修复通常无外乎三类选择器不对改成语义定位或data-testid、等待条件不对改成web-first assertion、测试数据干扰改成用API预置独立数据。每一条flaky用例都要走完这个排查链路而不是简单加个retry了事。我给CI配置的retries是1作为最后兜底但它绝不能替代排查。5.3 网络拦截与模拟把第三方接口从e2e里摘出去还有一个稳定性的大头是第三方依赖比如支付回调、短信验证码、地图SDK。这些外部服务在测试环境经常不稳定还不好控制。我对这类场景的处理是在登录和主流程用例中通过Playwright的page.route拦截关键第三方接口返回mock数据。await page.route(**/api/sms/send, route { route.fulfill({ status: 200, body: JSON.stringify({ code: 0000, msg: ok }), }); });这样做有两个好处一是把e2e从外部服务的随机故障中解放出来二是能让测试聚焦验证自家产品的逻辑。当然后台一般会提供测试环境的mock开关但用路由拦截更轻量不依赖对方配合。需要注意的是不要把核心支付流程的端到端验证也mock掉那会失去用户真能支付成功这条最有价值的回归保障。我的策略是主流程不含真实支付mock第三方另配少量真实支付联调用例在特定profile中跑。5.4 数据清理策略测试环境也是你的实验台我前面反复强调数据自给自足现在具体说下做法。每条e2e用例在准备阶段会通过API向测试环境写入业务前置数据比如创建一个用户名唯一的新用户生成一张可用优惠券预置一个待发货订单。测试执行为什么不稳十有八九是数据串了。比如两条用例共用一个手机号注册第二次注册时就提示手机号已存在直接失败。所以数据工厂设计时一定要保证唯一性和隔离性createUniqueUser: 每次使用时间戳或UUID生成唯一手机号/邮箱 createCartWithProduct: 每次创建独立购物车不引用共享商品ID cleanupByTestId: 用例结束后通过API删除本次产生的所有数据某些系统删除接口不好用或不安全那么至少做到软隔离每条用例使用独特前缀的数据互相不可见。比如测试订单号统一带e2e-timestamp前缀断言时只查询该前缀。这样即使不清理也不会互相干扰。数据隔离做得好的团队e2e稳定性一定是上一台阶的——因为很多偶发失败其实根本不是偶发是数据没隔离干净。5.5 一个容易被忽略的细节失败时的证据要尽量多排查e2e失败有时候像破案现场证据越充分越容易结案。我建议至少开启失败截图screenshot only-on-failure、失败视频video retain-on-failure、tracetrace retain-on-failure。这三个在Playwright里都是一行配置的事情但对非技术同事看报告也友好。我甚至在CI报告里把失败截图直接贴在评论区让前端同事不看日志就能判断是不是他们改了UI。这中间的体会是e2e框架默认给的能力不少重要的是把它当成工程基础设施去配置好而不是只当一个跑脚本的工具。6. CI集成与执行策略让e2e成为发布流程的守门员而不是定时炸弹6.1 PR阶段跑主链路高风险全量留给Nightly很多人第一个问题就是e2e该在哪个环节跑我的答案是分层。PR阶段只跑一个最小的主链路高风险冒烟集合比如登录、浏览、加购、下单、后台基础操作控制在15分钟内。这样开发者每次提交代码都能快速获得反馈而不会因为一条不相关的用例失败卡住合并。全量e2e包括所有业务分支、权限矩阵、支付核心流程放到Nightly任务里跑保证覆盖的同时不拖慢迭代节奏。这套策略下CI的配置大概是这样的name: E2E Pipeline on: pull_request: branches: [ main ] schedule: - cron: 0 2 * * * # 每天凌晨2点跑全量 workflow_dispatch: jobs: e2e: runs-on: ubuntu-latest strategy: fail-fast: false matrix: shard: [1, 2, 3] steps: - name: Checkout uses: actions/checkoutv4 - name: Setup Node uses: actions/setup-nodev4 - name: Install deps run: npm ci - name: Run E2E tests by shard run: npx playwright test --shard${{ matrix.shard }}/3这段配置的效果是PR触发时只跑主链路用例可以通过profile或tag控制Nightly跑全量且分成3个分片并行整体执行时间可以压缩一半以上。这个方案的思路是**快反馈和深覆盖分家**不让它们互相拖累。6.2 分片shard如何提升速度与发现问题速度e2e跑久了另一个瓶颈是执行时间长。全量300条用例单机跑可能40分钟。如果凌晨2点才开始失败后发现已经是第二天早上了修复窗口非常小。用分片之后3台机器并行跑执行时间压到15分钟以内。其实分片不复杂Playwright和Cypress都原生支持无非是测例自动切分成几份分给多个worker。我建议的两个实践细节一是fail-fast: false。这意味着一个分片失败不会取消其他分片。因为很多时候不同分片发现的可能是不同问题全取消会导致上报信息不完整往往修复了一处却发现还有第二处来回浪费好几个轮次。二是报告汇总。分片之后结果不会自动归集到一个报告里可以用Playwright的merge命令把多个reporter结果合并这样看板展示和告警都统一。6.3 retry策略治标可以别忘了治本我支持在CI中配置retries: 1或retries: 2但要明确它是标题党式的兜底不是借口。每次retry成功之后我要求团队必须拉取上一次失败的trace分析根因。如果三次以内找不到原因就暂停这条用例标记为known flaky从门禁中移除避免它持续污染CI信号。听起来有点极端但我见过太多团队被几条薛定谔的用例折磨数月最后发现是测试环境DNS偶发解析失败。退一步把环境问题修好再重新启用用例比天天看红灯健康多了。所以在CI集成时我一般会配一个失败告警自动建issue的流程当一条用例连续失败N次或回收率超过阈值时自动在测试平台建一个issue指派给这场用例的owner。人都是健忘的如果不自动把问题推到人面前它很容易就被埋没在报告海洋里。6.4 从跑完就行到用数据衡量e2e健康度现在很多团队评估e2e只看一个通过率这其实远远不够。我在团队里坚持每周看三个指标指标口径健康阈值flake率同一用例在CI重试中先失败后成功的次数 / 总执行次数 5%平均执行耗时全量套件从开始到结束的时间随分片控制在15分钟内用例新鲜度最近30天内是否有人动过这条用例超过30天未更新的用例要review为什么看flake率而不是通过率因为通过率是一个结果指标flake率能直接反应套件本身的健康度。如果一个项目flake率超过20%那它的通过率再好看也是假的——大概率是retry硬顶上去的。用数据说话团队才愿意投入精力去做稳定性治理而不是每次发布前祈祷别红。7. 最后分享几个踩坑后的个人习惯文章写到这技术框架基本都齐了。最后分享三条心得体会都是踩过坑之后沉淀下来的东西。第一先做20条能稳定跑一个月的用例比做200条天天红的用例有价值得多。稳定性的代价不在于框架选型而在于用例设计、数据隔离和等待策略这三件小事。先把这三件事做到位再逐步扩量你会发现后面每加一条用例都变得很轻松。第二让产品、前端、测试共同参与e2e的设计评审。用例是用户主路径的直接映射不能只让测试一个人拍脑袋。我后来每个迭代专门留30分钟过一次e2e用例变更这个流程改了用例要不要跟着改新加的主流程分支要不要加用例这样团队对e2e的ownership感极强而不是只有测试为红绿发愁。第三每周挑一条最慢的用例优化。全量套件里最慢的那几条往往因为等待时间过长、跑了很多不必要的UI步骤对它们做手术式的优化比如把前置条件从UI改成API把断言从DOM断言改成网络断言长期积累下来整个套件的速度会越来越快大家的信心也就越来越足。我用这套方法论在当前项目里跑了快两年e2e用例稳定在45条flake率长期在5%以下PR门禁几乎没有误报过。如果你正在为e2e是写废了还是跑废了而头疼不妨从profile配置和用例设计开始动手改先让核心链路跑稳再慢慢往两边扩展。e2e这条路不难走难的是别把它当成写脚本的任务而是当成一个需要持续经营的质量基础设施。
阅读完成 · 觉得有帮助？
