★ FEATURED ARTICLE 1. 先搞明白我不建议你把E2E当成“全流程点一遍”说到 e2e很多人第一反应是“端到端测试”然后立刻想到把整个页面从头到尾点一遍登录、搜索、加购物车、下单、支付一气呵成。这个理解不算错但我做测试工程这些年最怕的就是这种“理解不算错”带来的盲目自信真正把 e2e 用好的团队不是在堆用例而是在筛流程。这篇内容就从我个人的实操经验出发把 e2e 背后的设计思路、落地方式、稳定性处理和持续集成接入完整过一遍顺便聊聊我常挂在嘴边的 e2e profile1 到底是什么。准备入自动化测试的团队可以看已经被“分分钟 flaky”的用例折磨到秃头的测试同路人更应该看。1.1 E2E到底在测什么E2EEnd-to-End测试字面意思是“端到端”但它的核心不是“把用户能点的都点一遍”而是“验证一条完整业务链路在真实运行环境里能否走通”。这里的“端”有两个一端是用户入口比如浏览器里的页面、小程序里的按钮、移动端 App 的操作另一端是用户真正关心的结果比如订单状态变成“已支付”、邮件发出、余额扣成功。和单元测试、接口测试不一样e2e 测试往往会同时穿过前端界面、后端接口、数据库、第三方服务。它模拟的不是函数调用而是人类用户的行为。比如用户不会关心你某个按钮绑定的 click 事件写得好不好他关心的是点完“提交订单”之后钱是不是真的扣了页面是不是真的跳到了“支付成功”。这就决定了 e2e 的粒度天然是“业务场景级”而不是“代码函数级”。所以你会发现e2e 的用例名称通常长这样“用户登录后可以正常结算订单”“新用户注册后能收到验证邮件”“已登录用户修改密码后旧 token 失效”。这种用例不是在验证某一行代码而是在验证一整套业务承诺。1.2 为什么“全流程点一遍”会翻车我见过不少团队一听说要做 e2e第一批用例就把“所有菜单里的所有页面都点进去再退出来”写了一遍。这种用例跑起来确实很壮观截图里满满的页面但三个月之后基本全部死掉为什么呢第一个原因是成本。e2e 用例比单元测试贵得多。单元测试跑 1000 个可能只需要几秒钟但 e2e 用例每一条都要启动浏览器、加载页面、等待网络、操作数据库跑一条主流程轻松超过一分钟。全流程点一遍这种写法不是在做质量保障而是在制造一台“定时冒烟机”。第二个原因是重复。如果一个操作在五个流程里都会出现比如登录你把它重复写在五条用例里那么只要登录页面的某个 DOM 变了五个用例一起红。这在统计报表上很好看但对修脚本的人来说一点意义都没有因为他只改了一处前端代码却要处理五条失败记录。第三个原因是“流程太长所以稳定性太差”。一整条用户流程中任何一环出现抖动——网络慢了、第三方支付回调超时了、某个图片加载不出来——整条用例都可能失败。于是团队每天不是在排查业务 bug而是在给测试脚本“擦屁股”。久而久之连真正的回归问题也会被淹没在一堆 flaky 结果里。1.3 这篇文章适合谁如果你是一个后端工程师想在交付前快速验证核心页面没被改坏e2e 可以帮你建立“最低限度的安全感”。如果你是专职测试需要设计一套可持续维护的自动化用例这篇文章里的 profile、选择器、等待策略会直接可用。如果你是在带团队的技术负责人我觉得你更需要关注的是第五节里关于“门禁到底该卡在哪一层”的讨论这决定了团队会不会陷入“测试比开发还忙”的泥潭。2. E2E用例的设计拆解决定成败的不是工具是范围很多人一提到 e2e先问“用 Cypress 还是 Playwright”然后立刻去装环境写脚本。我的建议是反过来先想清楚“我要测哪些链路”再决定用什么工具。工具解决的是怎么写得稳而设计解决的是哪些值得写。后者才是决定 e2e 项目生死的关键。2.1 用“用户核心价值链路”圈定边界我设计 e2e 用例时筛选原则不是“影响面大”而是“如果这条链路挂了用户会立刻感知到”。说通俗点你在网上买东西如果商品详情页某个 banner 显示错位可能用户会吐槽但不会放弃购买但如果你点“立即购买”之后永远进不了结算页那用户就会流失。所以前者可以交给视觉回归测试后者才是 e2e 要守住的核心链路。拿电商来举例我会优先纳入 e2e 的范围是注册/登录、浏览商品、加入购物车、提交订单、支付成功、订单状态同步。因为这些环节跨前端、后端、数据库、第三方支付甚至消息队列任何一个环节出问题最终都会体现在“用户买不了东西”或“钱对不上账”上。至于商品筛选的排序是否准确、优惠券计算是否符合复杂规则这些更适合放进接口测试甚至单元测试因为它们的核心逻辑在后端通过界面去验证纯属绕远路。我还经常用一句话反问团队这条用例如果没有了你晚上敢安心睡吗不敢的才写进 e2e敢的放过。很多团队失败就是因为把“不敢睡的”和“其实无所谓”全写进了 e2e结果核心链路被海量边缘用例拖垮。2.2 从测试金字塔看E2E的位置测试金字塔是敏捷社区里老生常谈的概念但落到 e2e 里尤其重要。金字塔底层是单元测试数量最多中间是接口/组件测试顶层是 e2e数量最少。你可以把 e2e 看成“最后的守门员”而不是“唯一的守门员”。如果整个项目只有完整流程的 e2e 测试那一旦失败要从 UI 层面逐层推断是前端问题、后端问题还是数据问题效率非常低。反过来如果你有大量单元测试和接口测试它们会把问题定位到具体模块e2e 只需要承担“按用户视角走一遍确认各模块协作没问题”的职责。这套分工不是某个组织规定的而是由成本和反馈速度决定的。所以你在设计 e2e 用例时要经常问自己这个场景的核心断言能不能用接口测试更稳定地覆盖如果能那就别让它进 e2e。E2E 只做那些“只有从用户入口走一遍才能验证”的事比如页面交互、状态流转、跨系统协作。这样你的 e2e 用例数量会急剧下降每一条的含金量却会大幅上升。2.3 E2E Profile1一个更可执行的“用例分组”思路我平时在团队里常用“profile”来组织 e2e 用例。这里的 profile 不是性能测试里的 profile也不是用户画像而是“一套用例分组配置”。有人第一次听到我提 e2e profile1 时有点懵其实用大白话讲它就是“第一套跑得最勤的 e2e 用例组合”。我会把 e2e 用例分成几个 profileprofile1 通常对应“核心冒烟集”在每次代码合并、每天凌晨都跑数量最少、运行时间短、稳定性要求最高profile2 可以对应“全量回归集”在发版前跑数量多、跑得慢允许有一部分需要人工确认的边界场景甚至可以有 profile3专门跑跨系统、跨第三方服务的场景放在夜间执行。这么设计有什么好处因为一条 e2e 用例的“运行频率”不一定等于它的“重要性”。核心冒烟集可能只有 20 条但每次提交都跑能第一时间挡住明显的主流程破坏。全量回归集可能有 200 条如果也每次提交都跑团队会等到崩溃。用 profile 把用例切成不同执行节奏比单纯用 tag 标记“冒烟/回归”更好落地因为它把“什么时候跑哪些用例”变成了一套可执行、可调度的配置。2.4 场景拆分示例为了让“profile”不悬空我给你一个实际拆法。假设一个 B2B 后台系统用户核心链路是登录后台、切换项目、创建工单、指派负责人、关闭工单、查看报表。那么 profile1 核心冒烟集可以只写 6 条登录成功、登录失败提示、创建工单主流程、工单状态流转、报表页面能加载、退出登录。每条都在 3 分钟内能跑完总时长控制在 20 分钟以内。profile2 全量回归集则在上述基础上补充分页查询、权限校验、批量导入、不同浏览器的兼容场景。这些用例不需要每次提交都跑但在发版前必须全绿。这样拆分之后profile1 的高频执行不会拖累团队节奏profile2 的全面覆盖又不会丢失。3. 实操搭一套能落地的主链路E2E含代码讲完设计不落地的 e2e 都是空谈。这一节我用目前我比较常用的 Playwright 来做示范因为它在多浏览器支持、自动等待和调试体验上做得比较均衡。如果你团队已经在用 Cypress 或 Selenium思路完全通用不必纠结非要换工具。3.1 技术选型Playwright、Cypress、Selenium怎么选选型是我被问得最多的问题。我的判断依据很简单团队技术栈、应用形态、以及你需要的测试类型。下面这张表是我常用的对比方式工具优势常见痛点适合场景Playwright多浏览器同构、自动等待、支持多标签/多用户、内置 trace 和视频录制学习资料相对没有 Selenium 历史悠久中大型 Web 应用、需要跨浏览器或并行执行Cypress语法友好、调试体验好、Time travel 方便默认只支持自家浏览器体系、多标签支持有限前端团队为主、单页应用、偏组件与交互Selenium WebDriver生态最老、语言绑定多、兼容性广异步稳定性要自己多费心、脚本写起来啰嗦已有大量 Selenium 资产、或强绑定老框架如果让我给新项目一个默认答案Web 端且没有历史包袱我会选 Playwright。倒不是说 Cypress 不好而是 Playwright 的多浏览器和并行能力在 e2e 这种“重流程”测试里更省心。尤其是 profile1 这种要高频执行的用例集能多浏览器并行跑是很大的时间红利。3.2 项目初始化与基础配置先创建一个空目录初始化 npm 项目并安装 Playwrightmkdir e2e-project cd e2e-project npm init -y npm install -D playwright/test npx playwright install安装完成后创建一个playwright.config.ts这是所有 profile 和浏览器项目配置的入口。下面这份配置只保留了最核心的部分import { defineConfig, devices } from playwright/test; export default defineConfig({ testDir: ./tests, timeout: 60_000, expect: { timeout: 10_000, }, fullyParallel: true, retries: process.env.CI ? 2 : 0, reporter: [[html, { outputFolder: playwright-report }]], use: { baseURL: process.env.E2E_BASE_URL || http://localhost:3000, trace: on-first-retry, screenshot: only-on-failure, video: retain-on-failure, }, projects: [ { name: chromium, use: { ...devices[Desktop Chrome] }, }, { name: firefox, use: { ...devices[Desktop Firefox] }, }, ], });几个点需要重点说明。fullyParallel: true表示测试文件之间并行执行这能大幅压缩 profile1 的执行时间但对测试数据隔离有要求后面我会讲怎么处理。retries只在 CI 环境开 2 次本地不开因为本地重试会掩盖脚本问题。trace和video一开始就打开会帮你省下大量排查 flaky 的时间。3.3 写第一个E2E用例登录→创建订单→校验结果现在写一条真正的 e2e 用例。我习惯把 profile1 用例放在tests/profile1/目录下目录本身就是第一个分组信号。看一下这条用例import { test, expect } from playwright/test; test.describe(profile1 - 核心冒烟集, () { test(用户登录后可以创建订单, async ({ page }) { await page.goto(/login); await page.getByLabel(邮箱).fill(testexample.com); await page.getByLabel(密码).fill(password123); await page.getByRole(button, { name: 登录 }).click(); await expect(page.getByText(你好测试用户)).toBeVisible(); await page.goto(/orders/new); await page.getByLabel(商品名称).fill(无线键盘); await page.getByLabel(数量).fill(2); await page.getByRole(button, { name: 提交订单 }).click(); await expect(page.getByText(订单创建成功)).toBeVisible(); await expect(page).toHaveURL(/orders\/\d/); }); });你会注意到我全篇没有写sleep也没有写固定的waitForTimeout。关键断言都用了toBeVisible和toHaveURL它们会自动重试直到超时。这就是 Playwright 的 auto-waiting你不用手动去猜“这个接口要 2 秒还是 3 秒返回”框架会等到元素出现。选择器我也刻意避开了.class-name这种会随重构随意变化的写法。getByLabel和getByRole是站在用户使用习惯上找元素而不是站在 DOM 实现细节上找元素。如果开发把输入框外面的标签文案改了用例会红这是合理的但如果开发只是把内部 class 从input-wrapper改成了input-container用例不会红这才是稳定的。3.4 用Profile1跑通“核心冒烟集”现在我们有了 profile1 这个分组怎么让它真正变成一条可执行命令最简单的做法是在package.json里加几个脚本{ scripts: { test:e2e:profile1: playwright test tests/profile1 --projectchromium, test:e2e:profile2: playwright test tests/profile2 --projectchromium, test:e2e:all: playwright test } }如果你不想用目录区分也可以用标签。比如在用例名上写profile1然后运行npx playwright test --grep profile1我更推荐用目录区分 profile。理由很简单当你用--grep筛选用例时所有用例文件都必须先加载到同一个测试上下文里profile2 里那些慢用例的初始化配置多少会干扰 profile1。目录隔离之后每个 profile 可以有自己的 setup、自己的辅助函数互不污染。跑完一次 profile1你会得到一份 HTML 报告。如果某条用例失败报告里能看到失败那一步的截图、视频以及包含接口请求和 DOM 操作快照的 trace。不要小看这些调试数据它们就是 e2e 稳定性的第一道保险。没有这些排查一条偶发失败可能要一上午有了这些十分钟就能定位到是哪个网络请求超时了。4. E2E稳定性的关键等待、选择器与测试数据E2E 最大的敌人不是 bug而是“明明功能没问题测试却红了”。这类情况统称为 flaky。我做了几年 e2e总结下来大部分 flaky 都逃不开三个层面等待策略写得不对、选择器绑得太死、测试数据没有隔离。4.1 不要用固定sleep用自动等待最常见的新手写法是await page.waitForTimeout(3000); await page.click(#submit);这段代码背后的潜台词是“我等 3 秒接口总该回来了吧”。问题是这 3 秒在本地可能够用在 CI 的慢机器上可能不够用在接口偶发抖动时更不够用。于是你只能不断调大这个数字从 3000 改成 5000再改成 8000最后整个用例一小半时间都在空等。正确做法是让等待绑定“某个状态”。比如等按钮变成可点击、等加载提示消失、等某个关键文案出现。Playwright 的toBeVisible、toHaveText、toHaveURL这些断言本身就是等待策略它们会以 poll 的方式不断检查直到条件满足或超时。这样用例的耗时随应用实际响应速度浮动而不是被一个拍脑袋的固定数值锁死。顺便提醒一句不建议把总体超时时间设得过大。我见过有人把每个用例的 timeout 设成 5 分钟结果一个真正的性能回退问题拖了 5 分钟才暴露。60 秒对大多数 Web 主流程来说已经非常充裕。4.2 选择器怎么写得不容易碎选择器是 e2e 脚本里最让人头痛的一环。我见过用#root div div:nth-child(2) button这种路径写的用例后端一升级样式库就全员爆红。CSS 选择器说白了就是“DOM 结构地址”只要前端组件的嵌套层级一变地址就失效了。所以我的建议是优先用语义化选择器。顺序大概是这样的能找 label 就用getByLabel能找按钮文案就用getByRole(button, { name: ... })实在没有就用getByTestId。getByTestId需要开发在关键元素上主动加>name: e2e-profile1 on: pull_request: paths: - apps/** - packages/** - .github/workflows/e2e.yml jobs: e2e: runs-on: ubuntu-latest steps: - uses: actions/checkoutv4 - name: Setup Node uses: actions/setup-nodev4 with: node-version: 20 - name: Install dependencies run: npm ci - name: Install Playwright browsers run: npx playwright install --with-deps chromium - name: Start app run: npm run start:test env: NODE_ENV: test - name: Run profile1 run: npx playwright test tests/profile1 --projectchromium这个配置只装了 chromium因为 profile1 追求的是“快”而不是“覆盖所有浏览器”。如果你要求兼容可以把 firefox、webkit 都装进一个 job或者拆成三个并行 job。一般来说profile1 只跑 chromiumprofile2 才跑多浏览器矩阵这是成本和覆盖之间的平衡。5.2 并行分片、失败重试、报告汇总E2E 最怕的就是跑得太慢。比如 profile2 有 200 条用例串行跑平均每条 1 分钟就是三个多小时。这个时间在发版等待期里太致命了。所以执行效率几乎是 e2e 工程化程度的直接体现。Playwright 支持分片执行把同一份用例按比例切给多台机器并行npx playwright test --shard1/4 npx playwright test --shard2/4 npx playwright test --shard3/4 npx playwright test --shard4/4在 CI 里把它配置成四个并行 job总时长就从原来的三小时压缩到四十五分钟左右。如果还不够再配合fullyParallel: true在单台机器内多线程跑用例可以进一步压缩。还有一个小细节报告里一定要包含失败用例的 trace 和视频。默认配置trace: on-first-retry只会在第一次重试失败时录 trace含义是“没重试就失败说明问题足够稳定可复现不需要录也能查重试了还失败说明存在环境性或波动性问题我需要更详细的数据”。这个配置不是随便定的它是 trace 文件体积和排查能力之间的平衡点。如果空间允许也可以直接改成on但报告体积会大不少。报告汇总建议用 Playwright 官方 HTML reporter 或接入 Allure。HTML report 对团队沟通最友好点开就能看到测试步骤、失败截图、网络请求和 console 报错。至少要做到开发收到一条失败通知时不需要跑一遍复现就能判断“这是不是我的改动造成的”。6. 做了几年E2E我的几个真实体会前面讲了方法、代码和流程最后聊点个人感受。这些体会写在任何官方文档里都显得有点“软”但对长期维护 e2e 的团队来说可能比工具技巧更重要。6.1 E2E不是越多越好我见过最夸张的一个项目e2e 用例超过 2000 条每次全量跑要 6 个小时。维护它的测试团队每天上班第一件事就是修昨天的失败用例修到周末又刷出几十条新失败。问题出在哪里出在“把 e2e 当成了万能测试”。真正该做的是把大部分业务验证下沉到接口测试和单元测试e2e 只保留用户可感知的核心链路。少即是多这条定律在 e2e 上体现得比任何其他测试层都明显。6.2 E2E Profile1应该跟着发布计划走而不是跟着用例数量走我后来慢慢发现profile1 的组成不应该一成不变它应该随着产品阶段和发布计划调整。新功能上线前profile1 可以加入那条“新用户从注册到完成首单”的用例功能稳定后这条用例又可以降级到 profile2。永远维持 profile1 在一个“太慢不加、太脆不加、太边缘不加”的状态它不是用例库的缩减版而是发布风险清单的自动化表达。6.3 E2E的结果要为下一次迭代服务很多时候我们只关注“红了还是绿了”却忽略了“红是脚本问题还是业务问题”。如果红的是业务问题这就是一次真实的 bug 发现如果红的是脚本问题说明测试设计和环境治理还有改进空间。所以我在团队里有一个不成文的约定每条 e2e 失败都必须写一个一句话结论要么“产品 bug已提单”要么“测试脚本问题已修复”要么“环境问题已处理”。连续一个月统计下来如果第二条占比超过一半那说明不是用例太脆而是你的 e2e 稳定维护机制需要升级了。E2E 是个门槛不高但天花板很高的领域。从“全流程点一遍”到“设计 profile 并让它在 CI 里稳定护航”中间隔的不是工具熟练度而是对业务风险的理解。如果你正准备从零起步先别急着写用例按这篇的思路把核心链路圈出来把 profile1 跑稳你会在一次真实的发布事故里体会到这份投入的价值。
阅读完成 · 觉得有帮助？
