如果你接手过一个被单测全覆盖、但一到联调就翻车的项目你大概率会理解我为什么把端到端E2E测试当成保命符。E2E测试不是去测一个函数返回什么而是模拟一个真实用户从打开浏览器开始完成登录、搜索、筛选、加购、结算这一整条链路最后验证订单到底有没有落库。它解决的痛点和单测完全不同单测告诉我某个模块内部逻辑对不对E2E告诉我用户能不能顺利用完整个产品。E2E测试这个名字本身就说明问题end to end端到端从最外层入口到最底层数据一条线全打通。很多团队觉得它贵、慢、脆、维护成本高于是自动跳过。但我的实际体会是只要场景选得对、用例写得克制、运行环境治理到位E2E就是投入产出比最高的质量手段之一。这篇文章不聊空泛方法论直接把我的设计思路、选型对比、完整的用例写法和踩过的坑整理出来适合正在纠结要不要上E2E、或者已经上了但经常感觉每天在修测试的团队。1. 先把端到端想清楚它到底在测什么1.1 端到端测试解决的问题很多人对E2E有个误解以为它就是点一遍界面看有没有报错。实际上E2E的核心价值是验证跨模块、跨系统的集成正确性。一个典型业务系统里前端调后端接口后端读写数据库同步调消息队列再通知第三方支付平台。这里面任何一环的契约不匹配都会让用户卡在某个环节。我见过最经典的翻车案例登录接口状态码正常前端跳转正常最后用户页面白屏。排查半天发现后端返回的字段里多嵌套了一层单测全过因为单测只断言返回200且含token根本不管前端能不能解出来。这种问题只有E2E能拦住因为它把页面渲染出真实用户能看到的内容作为最终验收标准。所以E2E解决的问题不是逻辑对错而是整条链路是否能让用户真正完成目标。它站在用户视角把产品当黑盒只关心输入、操作、输出这三件事。这种验证方式没法被单测替代也没法靠代码评审发现因为评审看的是代码逻辑而链路上的问题经常是配置、环境、数据、时序共同作用的结果。1.2 与单元测试、集成测试的边界我习惯把测试金字塔里的三层想成三个问题单元测试问这个函数写对了吗集成测试问这个服务和那个服务对得上吗E2E问用户能完成他的任务吗。这三者不是替代关系而是层层递进。单元测试跑得最快毫秒级适合测纯函数、工具方法、组件状态。它的问题是只验证局部如果调用方把参数传错了单测很难发现。集成测试把两个模块接在一起测比如测接口服务跟数据库的交互能发现字段映射错误但它不关心页面怎么渲染。E2E把整个系统拉起来从浏览器这一端到数据库那一端都测一遍覆盖最广也最贵。我见过不少团队把E2E当万能药恨不得所有功能都上E2E。结果就是测试跑了两个小时随便一个网络抖动就让全盘红维护的人欲哭无泪。正确的做法是能用单测快速覆盖的判断逻辑绝不写进E2EE2E只留给用户核心旅程和跨系统关键链路。1.3 什么时候才需要上E2E我的判断标准很简单——如果某个功能出问题用户会立刻感知并且影响核心转化那它就应该有E2E覆盖。比如注册登录、商品搜索、加购结算、订单支付这些。反之一个后台管理页面的表单校验逻辑单测完全够用没必要非得上E2E。另一个判断是链路复杂度。如果一条业务流要经过前端、后端、缓存、消息队列、第三方服务这五层哪怕每个环节都有测试我也不敢说它一定跑得通。只有从入口到出口来一次真实演练才能证明整条链路是通的。我还建议团队在引入E2E之前先理清楚自己的核心用户旅程有几个。电商的下单流程是一个内容平台的文章发布流程是一个SaaS的邀请成员流程又是一个。一般来说核心旅程超过三个而且修改频率不低E2E就值得投入。如果只是个两三个月迭代一次的活动页手写脚本回归就够了。2. 测试场景设计才是真正的核心活2.1 用户旅程拆解法E2E用例设计最忌讳按页面来——登录页写一个用例商品页写一个用例购物车写一个用例。这样的用例组到跑的时候还是散的没法验证用户能不能从A走到B。我设计E2E场景时用的是用户旅程拆解法。先写一条主流程比如新用户在首页搜索无线耳机进入商品详情选择规格加入购物车结算使用优惠券支付成功看到订单状态。然后把这条主流程拆成可执行的动作序列每个动作对应一个页面操作和至少一个断言。拆解的关键是找状态转折点。用户从商品页进入购物车时购物车角标数量要变化从结算页提交订单后要出现支付成功的反馈页面支付回调处理完成后订单列表里要出现这条订单。这些转折点就是断言的最佳位置因为它们代表了系统状态的真实变化。我还会给每条旅程标上重要性等级。P0是核心转化路径每次发布必须跑P1是重要辅助路径比如注册时验证码模块可以一小时代一次P2是低频路径随主流程一起回归。没有这个分级E2E很容易变成一锅炖。2.2 数据入口、环境隔离与幂等性E2E测试最让人头疼的永远是数据问题。一个用例今天能跑过明天跑不过大概率不是代码变了而是环境数据变了。所以要跑E2E环境治理和数据治理比写用例本身还重要。我强烈建议给E2E准备独立的环境和数据源至少是独立的数据库。为什么因为E2E会真实地创建订单、写库、调第三方支付。如果和开发环境共用一套数据你在测试里创建的订单会污染别人的调试数据别人改数据也会让你的测试随机失败。数据的构造策略也要花心思。我的原则是能用接口预置的绝不走UI创建。比如测试需要一个已登录用户直接调后端接口拿token而不是在UI上一步步注册。测试需要一个有库存的商品直接调接口修改库存。这样可以极大缩短E2E用例的执行时间也降低了稳定性风险。幂等性也是一大重点。一个E2E用例如果执行两次结果应该完全一样或者至少不会留下影响下次执行的脏数据。比如支付类用例我会让测试订单绑定一个带时间戳的唯一标识这样哪怕重复跑也不会撞上同一个订单号。2.3 一个标准的E2E用例清单长什么样我自己维护用例清单时会分成几个维度写用例名、前置条件、操作步骤、预期结果、数据需求、依赖接口。下面是一个简化版示例用例名前置条件操作步骤预期结果数据需求用户完成商品购买全流程已登录、有库存商品、折扣可用搜索商品、加购、结算、使用优惠券、支付订单生成且状态为待发货独立测试账号、可重复使用的商品优惠券过期时结算失败已登录、过期优惠券在账号下进入结算页选择该优惠券页面提示优惠券不可用金额不变过期优惠券数据支付回调超时后订单状态更新已登录、已创建未支付订单模拟支付页超时等待回调订单状态变为已取消可控制回调的mock服务重点是每个用例都有明确的数据准备和后置清理策略。比如支付成功后要把创建出的订单通过接口标记为已归档避免影响后续用例的统计类断言。3. 工具选型和基础搭建实测过的方案对比3.1 Playwright、Cypress、Selenium怎么选三年前我还在用Selenium现在已经彻底换到Playwright了。这三者我给一个非常主观但实用的对比结论。Selenium的优势是生态老、支持几乎所有浏览器和语言劣势是API设计偏底层写起来啰嗦自带的等待机制薄弱网络波动时极其容易中断。如果团队有历史存量资产用Selenium写了几千条用例我建议逐步迁移而不是推倒重来。Cypress的优势是开发体验好、自带断言、时间旅行调试非常爽适合前端团队自己维护测试。但它的缺陷是只能在Node技术栈里跑跨域场景支持比较费劲而且不支持多标签页这种偏底层的浏览器行为。Cypress跑单页应用体验一流但涉及多系统跳转、三方登录之类的场景就会别扭。Playwright是目前我最推荐的。它由微软维护支持Chromium、Firefox、WebKit三套浏览器引擎API设计现代化自带自动等待还能通过CDP直接控制浏览器底层。实际使用下来它的稳定性和执行速度都明显优于另外两家。如果你要问我新项目选什么无脑Playwright。3.2 环境搭建与依赖安装以Playwright为例一个最小可运行的环境只需要三步。我用Node.js生态Python生态也很类似。创建一个项目目录初始化npm然后安装Playwright和浏览器内核npm init -y npm install playwright/test npx playwright install chromium这里要注意npx playwright install下载的浏览器内核体积很大在CI环境里一定要单独做缓存层我见过太多团队因为临时下载浏览器导致构建超时。另外安装完以后建议跑一下npx playwright --version确认版本再跑一条最小的用例把整个链路验证通。我还会顺手做两件事一是把Playwright的trace和截图目录配置好这样失败用例会自动留下现场证据二是装好faker-js/faker用于生成随机用户名和邮箱E2E测试最怕的就是造数据时硬编码。3.3 目录结构与配置文件解析一个我从实战中沉淀下来的推荐目录结构e2e/ ├── config/ │ └── playwright.config.ts ├── fixtures/ │ ├── auth.json │ ├── products.json │ └── coupons.json ├── pages/ │ ├── login.page.ts │ ├── product.page.ts │ └── cart.page.ts ├── tests/ │ ├── checkout.spec.ts │ └── order.spec.ts └── utils/ ├── api-client.ts └── db-cleanup.tspages目录存放页面对象把选择器和页面交互封装起来用例里不直接出现page.click(...)这种裸写。fixtures存放固定数据utils里放接口客户端和清理脚本。这样做的核心原因有两条一是用例可读性大幅提升二是后端接口变化时只需要改utils不用改每一条用例。配置文件里我最重视三个参数retries、timeout、workers。本地调试时retries设0CI里设2timeout我习惯设30秒太长会让失败用例拖垮整个流水线workers根据机器核数调整并行度太高会引起资源争抢。4. 实操写一个完整的端到端测试用例4.1 登录——用接口预置数据而不是每次都点UI很多新手写E2E时喜欢从头到尾都在页面上操作包括注册和登录。这样不是不行而是会让用例体积膨胀至少一倍还容易因为验证码、短信等外部因素失败。我的做法是登录状态尽量用接口预置。Playwright里可以用storageState把登录后的cookie和localStorage存下来用例开始时直接复用。这样不仅执行快还让用例聚焦在真正要测的业务上。不过这里有个取舍如果团队的核心旅程本身就包括登录页的UI交互和登录后的跳转逻辑那至少保留一条完整的UI登录用例。其他的业务用例全走预置登录效果是最好的。4.2 核心业务流从搜索到提交订单直接给一段我实际用过的代码示例以电商下单主流程为模板。用例结构完全符合我前面说的动作序列 状态转折点断言import { test, expect } from playwright/test; import { createUser, seedProduct, createOrderApi } from ../utils/api-client; import { LoginPage } from ../pages/login.page; import { ProductPage } from ../pages/product.page; import { CartPage } from ../pages/cart.page; test.describe(核心购买流程, () { test(用户完成搜索-加购-结算-支付, async ({ page }) { // 前置接口创建用户和库存商品 const user await createUser(buyer_ Date.now()); const product await seedProduct({ title: 无线耳机, stock: 5, price: 299 }); await page.goto(/login); // 流程一登录走接口写入storageState const loginPage new LoginPage(page); await loginPage.loginByApi(user.email, user.password); // 流程二搜索商品并进入详情 await page.goto(/search?q encodeURIComponent(无线耳机)); await page.getByText(无线耳机).click(); // 流程三选规格加购 const productPage new ProductPage(page); await productPage.selectColor(黑色); await productPage.clickAddToCart(); await expect(page.locator(.cart-badge)).toHaveText(1); // 流程四结算并提交订单 const cartPage new CartPage(page); await cartPage.clickCheckout(); await page.getByRole(button, { name: 提交订单 }).click(); // 状态转折点订单成功返回订单号 await expect(page.locator(.order-success)).toBeVisible(); // 后置通过接口确认订单已落库 const order await createOrderApi.getLatestByUser(user.id); expect(order.status).toBe(PAID); }); });这段代码有几个关键设计点。createUser和seedProduct走接口或数据库直插让用例稳定。每一步操作后都加了断言但只断言跟用户感知相关的状态变化比如购物车角标数量、订单成功页面。最后一步通过接口验证订单落库等于把整条链路从UI到数据库验证了一遍。4.3 断言写什么不是所有东西都值得断言E2E里最容易犯的错误是过度断言。我见过有人对一个购物车页面写了二十个断言从商品标题到价格从图片链接到库存文案恨不得把所有字段都校验一遍。结果页面改了一个不起眼的描述用例就红了。我的经验是每条用例只断言三件事用户目标的完成标志、链路关键状态转折、核心数据的一致性。比如下单流程用户目标完成标志是出现订单成功页面状态转折是购物车数量从1变0数据一致性是接口返回的订单金额等于页面展示的金额。至于页面文案、按钮颜色、布局样式这些完全不应该出现在E2E里。一旦你开始为这些写断言用例数量会爆炸而且每个断言都在拉低稳定性。记住E2E测的是行为和状态不是静态UI。4.4 测试数据管理与清理策略数据清理是我在E2E上收获最多的教训。最开始我没有清理数据的习惯结果跑完一轮测试后测试库里堆了几千条垃圾订单导致后续用例的统计断言全部异常。现在的策略分两层。第一层是测试开始前的预置——每个用例都尽可能创建自己需要的数据不依赖环境里已有的数据第二层是测试结束后的清理——通过接口把创建的订单置为失效或者直接调数据库删除。test.afterEach(async ({}) { await cleanUpTestOrders(); });这里要注意清理动作一定要幂等即使用例中途失败了清理函数也要能适配可能只创建了一半数据的情况。我会习惯把创建数据时生成的唯一ID记录到一个全局数组清理时遍历这个数组逐个删除这样就能避免误删线上数据。5. 跑起来之后的各种坑问题与排查实录5.1 选择器易碎如何设计稳定选择器E2E测试稳定性最大的敌人就是选择器。我给团队立过一条规则优先用getByRole、getByLabel、getByText这些可访问性选择器永远不要用CSS里的嵌套类名构造长链选择器。道理很简单开发者重构CSS时改类名太正常了但按钮的可访问性名称不会随便变。比如一个提交按钮它的可访问性名称是提交订单用getByRole(button, { name: 提交订单 })就比.btn-submit-order稳定得多。如果遇到没有语义属性的组件我的兜底方案是给测试用独立的数据属性比如> 端到端测试实战：从用户旅程到Playwright用例设计
如果你接手过一个被单测全覆盖、但一到联调就翻车的项目你大概率会理解我为什么把端到端E2E测试当成保命符。E2E测试不是去测一个函数返回什么而是模拟一个真实用户从打开浏览器开始完成登录、搜索、筛选、加购、结算这一整条链路最后验证订单到底有没有落库。它解决的痛点和单测完全不同单测告诉我某个模块内部逻辑对不对E2E告诉我用户能不能顺利用完整个产品。E2E测试这个名字本身就说明问题end to end端到端从最外层入口到最底层数据一条线全打通。很多团队觉得它贵、慢、脆、维护成本高于是自动跳过。但我的实际体会是只要场景选得对、用例写得克制、运行环境治理到位E2E就是投入产出比最高的质量手段之一。这篇文章不聊空泛方法论直接把我的设计思路、选型对比、完整的用例写法和踩过的坑整理出来适合正在纠结要不要上E2E、或者已经上了但经常感觉每天在修测试的团队。1. 先把端到端想清楚它到底在测什么1.1 端到端测试解决的问题很多人对E2E有个误解以为它就是点一遍界面看有没有报错。实际上E2E的核心价值是验证跨模块、跨系统的集成正确性。一个典型业务系统里前端调后端接口后端读写数据库同步调消息队列再通知第三方支付平台。这里面任何一环的契约不匹配都会让用户卡在某个环节。我见过最经典的翻车案例登录接口状态码正常前端跳转正常最后用户页面白屏。排查半天发现后端返回的字段里多嵌套了一层单测全过因为单测只断言返回200且含token根本不管前端能不能解出来。这种问题只有E2E能拦住因为它把页面渲染出真实用户能看到的内容作为最终验收标准。所以E2E解决的问题不是逻辑对错而是整条链路是否能让用户真正完成目标。它站在用户视角把产品当黑盒只关心输入、操作、输出这三件事。这种验证方式没法被单测替代也没法靠代码评审发现因为评审看的是代码逻辑而链路上的问题经常是配置、环境、数据、时序共同作用的结果。1.2 与单元测试、集成测试的边界我习惯把测试金字塔里的三层想成三个问题单元测试问这个函数写对了吗集成测试问这个服务和那个服务对得上吗E2E问用户能完成他的任务吗。这三者不是替代关系而是层层递进。单元测试跑得最快毫秒级适合测纯函数、工具方法、组件状态。它的问题是只验证局部如果调用方把参数传错了单测很难发现。集成测试把两个模块接在一起测比如测接口服务跟数据库的交互能发现字段映射错误但它不关心页面怎么渲染。E2E把整个系统拉起来从浏览器这一端到数据库那一端都测一遍覆盖最广也最贵。我见过不少团队把E2E当万能药恨不得所有功能都上E2E。结果就是测试跑了两个小时随便一个网络抖动就让全盘红维护的人欲哭无泪。正确的做法是能用单测快速覆盖的判断逻辑绝不写进E2EE2E只留给用户核心旅程和跨系统关键链路。1.3 什么时候才需要上E2E我的判断标准很简单——如果某个功能出问题用户会立刻感知并且影响核心转化那它就应该有E2E覆盖。比如注册登录、商品搜索、加购结算、订单支付这些。反之一个后台管理页面的表单校验逻辑单测完全够用没必要非得上E2E。另一个判断是链路复杂度。如果一条业务流要经过前端、后端、缓存、消息队列、第三方服务这五层哪怕每个环节都有测试我也不敢说它一定跑得通。只有从入口到出口来一次真实演练才能证明整条链路是通的。我还建议团队在引入E2E之前先理清楚自己的核心用户旅程有几个。电商的下单流程是一个内容平台的文章发布流程是一个SaaS的邀请成员流程又是一个。一般来说核心旅程超过三个而且修改频率不低E2E就值得投入。如果只是个两三个月迭代一次的活动页手写脚本回归就够了。2. 测试场景设计才是真正的核心活2.1 用户旅程拆解法E2E用例设计最忌讳按页面来——登录页写一个用例商品页写一个用例购物车写一个用例。这样的用例组到跑的时候还是散的没法验证用户能不能从A走到B。我设计E2E场景时用的是用户旅程拆解法。先写一条主流程比如新用户在首页搜索无线耳机进入商品详情选择规格加入购物车结算使用优惠券支付成功看到订单状态。然后把这条主流程拆成可执行的动作序列每个动作对应一个页面操作和至少一个断言。拆解的关键是找状态转折点。用户从商品页进入购物车时购物车角标数量要变化从结算页提交订单后要出现支付成功的反馈页面支付回调处理完成后订单列表里要出现这条订单。这些转折点就是断言的最佳位置因为它们代表了系统状态的真实变化。我还会给每条旅程标上重要性等级。P0是核心转化路径每次发布必须跑P1是重要辅助路径比如注册时验证码模块可以一小时代一次P2是低频路径随主流程一起回归。没有这个分级E2E很容易变成一锅炖。2.2 数据入口、环境隔离与幂等性E2E测试最让人头疼的永远是数据问题。一个用例今天能跑过明天跑不过大概率不是代码变了而是环境数据变了。所以要跑E2E环境治理和数据治理比写用例本身还重要。我强烈建议给E2E准备独立的环境和数据源至少是独立的数据库。为什么因为E2E会真实地创建订单、写库、调第三方支付。如果和开发环境共用一套数据你在测试里创建的订单会污染别人的调试数据别人改数据也会让你的测试随机失败。数据的构造策略也要花心思。我的原则是能用接口预置的绝不走UI创建。比如测试需要一个已登录用户直接调后端接口拿token而不是在UI上一步步注册。测试需要一个有库存的商品直接调接口修改库存。这样可以极大缩短E2E用例的执行时间也降低了稳定性风险。幂等性也是一大重点。一个E2E用例如果执行两次结果应该完全一样或者至少不会留下影响下次执行的脏数据。比如支付类用例我会让测试订单绑定一个带时间戳的唯一标识这样哪怕重复跑也不会撞上同一个订单号。2.3 一个标准的E2E用例清单长什么样我自己维护用例清单时会分成几个维度写用例名、前置条件、操作步骤、预期结果、数据需求、依赖接口。下面是一个简化版示例用例名前置条件操作步骤预期结果数据需求用户完成商品购买全流程已登录、有库存商品、折扣可用搜索商品、加购、结算、使用优惠券、支付订单生成且状态为待发货独立测试账号、可重复使用的商品优惠券过期时结算失败已登录、过期优惠券在账号下进入结算页选择该优惠券页面提示优惠券不可用金额不变过期优惠券数据支付回调超时后订单状态更新已登录、已创建未支付订单模拟支付页超时等待回调订单状态变为已取消可控制回调的mock服务重点是每个用例都有明确的数据准备和后置清理策略。比如支付成功后要把创建出的订单通过接口标记为已归档避免影响后续用例的统计类断言。3. 工具选型和基础搭建实测过的方案对比3.1 Playwright、Cypress、Selenium怎么选三年前我还在用Selenium现在已经彻底换到Playwright了。这三者我给一个非常主观但实用的对比结论。Selenium的优势是生态老、支持几乎所有浏览器和语言劣势是API设计偏底层写起来啰嗦自带的等待机制薄弱网络波动时极其容易中断。如果团队有历史存量资产用Selenium写了几千条用例我建议逐步迁移而不是推倒重来。Cypress的优势是开发体验好、自带断言、时间旅行调试非常爽适合前端团队自己维护测试。但它的缺陷是只能在Node技术栈里跑跨域场景支持比较费劲而且不支持多标签页这种偏底层的浏览器行为。Cypress跑单页应用体验一流但涉及多系统跳转、三方登录之类的场景就会别扭。Playwright是目前我最推荐的。它由微软维护支持Chromium、Firefox、WebKit三套浏览器引擎API设计现代化自带自动等待还能通过CDP直接控制浏览器底层。实际使用下来它的稳定性和执行速度都明显优于另外两家。如果你要问我新项目选什么无脑Playwright。3.2 环境搭建与依赖安装以Playwright为例一个最小可运行的环境只需要三步。我用Node.js生态Python生态也很类似。创建一个项目目录初始化npm然后安装Playwright和浏览器内核npm init -y npm install playwright/test npx playwright install chromium这里要注意npx playwright install下载的浏览器内核体积很大在CI环境里一定要单独做缓存层我见过太多团队因为临时下载浏览器导致构建超时。另外安装完以后建议跑一下npx playwright --version确认版本再跑一条最小的用例把整个链路验证通。我还会顺手做两件事一是把Playwright的trace和截图目录配置好这样失败用例会自动留下现场证据二是装好faker-js/faker用于生成随机用户名和邮箱E2E测试最怕的就是造数据时硬编码。3.3 目录结构与配置文件解析一个我从实战中沉淀下来的推荐目录结构e2e/ ├── config/ │ └── playwright.config.ts ├── fixtures/ │ ├── auth.json │ ├── products.json │ └── coupons.json ├── pages/ │ ├── login.page.ts │ ├── product.page.ts │ └── cart.page.ts ├── tests/ │ ├── checkout.spec.ts │ └── order.spec.ts └── utils/ ├── api-client.ts └── db-cleanup.tspages目录存放页面对象把选择器和页面交互封装起来用例里不直接出现page.click(...)这种裸写。fixtures存放固定数据utils里放接口客户端和清理脚本。这样做的核心原因有两条一是用例可读性大幅提升二是后端接口变化时只需要改utils不用改每一条用例。配置文件里我最重视三个参数retries、timeout、workers。本地调试时retries设0CI里设2timeout我习惯设30秒太长会让失败用例拖垮整个流水线workers根据机器核数调整并行度太高会引起资源争抢。4. 实操写一个完整的端到端测试用例4.1 登录——用接口预置数据而不是每次都点UI很多新手写E2E时喜欢从头到尾都在页面上操作包括注册和登录。这样不是不行而是会让用例体积膨胀至少一倍还容易因为验证码、短信等外部因素失败。我的做法是登录状态尽量用接口预置。Playwright里可以用storageState把登录后的cookie和localStorage存下来用例开始时直接复用。这样不仅执行快还让用例聚焦在真正要测的业务上。不过这里有个取舍如果团队的核心旅程本身就包括登录页的UI交互和登录后的跳转逻辑那至少保留一条完整的UI登录用例。其他的业务用例全走预置登录效果是最好的。4.2 核心业务流从搜索到提交订单直接给一段我实际用过的代码示例以电商下单主流程为模板。用例结构完全符合我前面说的动作序列 状态转折点断言import { test, expect } from playwright/test; import { createUser, seedProduct, createOrderApi } from ../utils/api-client; import { LoginPage } from ../pages/login.page; import { ProductPage } from ../pages/product.page; import { CartPage } from ../pages/cart.page; test.describe(核心购买流程, () { test(用户完成搜索-加购-结算-支付, async ({ page }) { // 前置接口创建用户和库存商品 const user await createUser(buyer_ Date.now()); const product await seedProduct({ title: 无线耳机, stock: 5, price: 299 }); await page.goto(/login); // 流程一登录走接口写入storageState const loginPage new LoginPage(page); await loginPage.loginByApi(user.email, user.password); // 流程二搜索商品并进入详情 await page.goto(/search?q encodeURIComponent(无线耳机)); await page.getByText(无线耳机).click(); // 流程三选规格加购 const productPage new ProductPage(page); await productPage.selectColor(黑色); await productPage.clickAddToCart(); await expect(page.locator(.cart-badge)).toHaveText(1); // 流程四结算并提交订单 const cartPage new CartPage(page); await cartPage.clickCheckout(); await page.getByRole(button, { name: 提交订单 }).click(); // 状态转折点订单成功返回订单号 await expect(page.locator(.order-success)).toBeVisible(); // 后置通过接口确认订单已落库 const order await createOrderApi.getLatestByUser(user.id); expect(order.status).toBe(PAID); }); });这段代码有几个关键设计点。createUser和seedProduct走接口或数据库直插让用例稳定。每一步操作后都加了断言但只断言跟用户感知相关的状态变化比如购物车角标数量、订单成功页面。最后一步通过接口验证订单落库等于把整条链路从UI到数据库验证了一遍。4.3 断言写什么不是所有东西都值得断言E2E里最容易犯的错误是过度断言。我见过有人对一个购物车页面写了二十个断言从商品标题到价格从图片链接到库存文案恨不得把所有字段都校验一遍。结果页面改了一个不起眼的描述用例就红了。我的经验是每条用例只断言三件事用户目标的完成标志、链路关键状态转折、核心数据的一致性。比如下单流程用户目标完成标志是出现订单成功页面状态转折是购物车数量从1变0数据一致性是接口返回的订单金额等于页面展示的金额。至于页面文案、按钮颜色、布局样式这些完全不应该出现在E2E里。一旦你开始为这些写断言用例数量会爆炸而且每个断言都在拉低稳定性。记住E2E测的是行为和状态不是静态UI。4.4 测试数据管理与清理策略数据清理是我在E2E上收获最多的教训。最开始我没有清理数据的习惯结果跑完一轮测试后测试库里堆了几千条垃圾订单导致后续用例的统计断言全部异常。现在的策略分两层。第一层是测试开始前的预置——每个用例都尽可能创建自己需要的数据不依赖环境里已有的数据第二层是测试结束后的清理——通过接口把创建的订单置为失效或者直接调数据库删除。test.afterEach(async ({}) { await cleanUpTestOrders(); });这里要注意清理动作一定要幂等即使用例中途失败了清理函数也要能适配可能只创建了一半数据的情况。我会习惯把创建数据时生成的唯一ID记录到一个全局数组清理时遍历这个数组逐个删除这样就能避免误删线上数据。5. 跑起来之后的各种坑问题与排查实录5.1 选择器易碎如何设计稳定选择器E2E测试稳定性最大的敌人就是选择器。我给团队立过一条规则优先用getByRole、getByLabel、getByText这些可访问性选择器永远不要用CSS里的嵌套类名构造长链选择器。道理很简单开发者重构CSS时改类名太正常了但按钮的可访问性名称不会随便变。比如一个提交按钮它的可访问性名称是提交订单用getByRole(button, { name: 提交订单 })就比.btn-submit-order稳定得多。如果遇到没有语义属性的组件我的兜底方案是给测试用独立的数据属性比如>