1. 从“e2e”这个标题说起它到底指什么第一次看到“e2e”这个标题很多人脑子里会蹦出好几个答案。做测试的会想到端到端测试做通信的会想到端到端加密做产品的会想到端到端流程做AI的最近还会想到端到端模型。这个标题本身足够短短到像一个内部代号但它背后能承载的东西非常多。我之所以想认真聊这个话题是因为“e2e”这三个字符在最近的技术讨论里出现频率明显变高了尤其是“e2e profile1”这个说法开始在一些圈子里流传说明它已经从一个单纯的缩写变成了某种方案选型的代名词。先把范围收一收。这篇内容我主要围绕“e2e”作为一个工程实践主题来展开重点放在端到端测试与端到端流程验证这条线上同时会把“e2e profile1”作为一个配置档位的概念来解释。为什么选这个角度因为在实际项目里e2e最容易出问题的地方从来不是“写一个测试脚本”本身而是整个链路的组织方式、环境准备、数据构造、断言策略和失败排查。这些细节如果没人讲透你写出来的e2e就是一堆跑一次就废的脚本维护成本高到让人想删库。这篇文章适合谁看如果你正在负责一个需要跨多个模块、多个服务、甚至多个端的产品并且已经被“改一处崩三处”搞到头疼那e2e这套东西你迟早要碰。如果你只是听说过e2e但不知道从哪下手我也会从最基础的概念和最小可运行方案讲起。如果你已经在写e2e但总觉得不稳定、跑得慢、维护累那中间关于profile配置和排查技巧的部分应该能帮你省不少时间。我自己的经验是e2e这件事最怕两种极端一种是觉得它太重要什么都要端到端测一遍结果套件跑一次要两个小时没人愿意等另一种是觉得它太脆弱干脆不写最后线上出问题全靠人肉回归。合理的做法是在中间找一个平衡点用分层策略把e2e用在刀刃上。下面我就按这个思路把e2e的整体设计、核心细节、实操过程和常见问题一块一块拆开讲。2. e2e整体设计与思路拆解2.1 为什么e2e不能“什么都测”端到端测试的核心价值在于验证“用户视角的完整链路”。比如用户从打开页面、登录、下单、支付到收到确认这一整条路走通才叫端到端。它的优势是贴近真实场景能发现单元测试和集成测试发现不了的跨系统问题。但它的代价也很明显慢、脆、依赖多。我见过不少团队一开始热情很高把几乎所有功能都写成e2e结果半年后这套件没人敢动。原因很简单每加一个功能就要加几条e2e环境稍微抖一下全红排查一个失败要翻五六个服务的日志。所以设计e2e的第一原则不是“覆盖全”而是“选关键路径”。通常我会把链路按业务价值分成三档核心交易链路、重要但非交易链路、边缘链路。e2e只覆盖第一档和第二档里最容易出跨系统问题的部分剩下的交给下层测试。这个取舍背后的逻辑是成本收益比。一条e2e的编写成本可能是单元测试的十倍维护成本可能是二十倍。如果它验证的东西单元测试也能验证那这条e2e就是负资产。只有那些“必须多个真实组件一起工作才能验证”的场景才值得用e2e。2.2 e2e profile1到底在配什么“e2e profile1”这个说法我理解为一套预设的e2e运行配置档。在实际项目里e2e通常不会只有一种跑法而是根据目的不同分成几个profile。profile1往往是最基础、最稳定、跑得最快的那一档用来做日常提交前的快速验证。它可能只跑核心链路的冒烟用例环境用本地或轻量容器数据用预置的固定数据集。为什么要有profile这个概念因为e2e的使用场景是分层的。开发本地改完代码需要几分钟内知道核心链路有没有断这时候跑全量e2e不现实。CI流水线上每次合并请求需要比本地更全一点但也不能太久。 nightly构建或者发版前才需要跑最完整的e2e。如果只有一套配置你要么太慢要么覆盖不够。profile就是把“跑哪些用例、用什么环境、造什么数据、并发多少”这些参数打包成几个档位按需切换。我一般会设计三个profileprofile1是冒烟级5到10分钟profile2是回归级30分钟左右profile3是全量级可能一两个小时只在发版前跑。profile1的用例选择标准是“如果这条断了整个产品基本不可用”。比如登录、核心查询、核心写入、核心支付。这些用例必须极其稳定环境依赖降到最低数据尽量自包含。2.3 分层策略e2e在测试金字塔里的位置测试金字塔这个概念很多人听过但实际落地时容易走形。底层是大量单元测试中间是集成测试顶层是少量e2e。e2e的“少量”不是随便说的通常建议不超过总用例数的10%到15%。如果e2e占比超过30%基本可以判断这个团队的测试策略出了问题。为什么e2e要少因为它的反馈周期长、失败原因复杂、修复成本高。单元测试失败你打开文件看一眼就知道哪错了。e2e失败可能是代码问题、环境问题、数据问题、网络问题、第三方服务问题甚至时间同步问题。排查一条e2e失败的时间可能够你写二十条单元测试。所以e2e的定位应该是“最后一道防线”而不是“主要验证手段”。但这不意味着e2e可以随便写。恰恰因为它少每一条都要写得极其扎实。我的做法是每条e2e都要有明确的业务场景描述、清晰的断言点、独立的测试数据、可重试的失败处理。宁可一条e2e覆盖一个完整场景也不要拆成五条互相依赖的碎片用例。碎片用例之间的依赖是e2e不稳定的最大来源之一。3. 核心细节解析与实操要点3.1 环境准备e2e稳定的地基e2e跑不起来十有八九是环境问题。我踩过的坑包括数据库里残留了上次跑的数据导致断言失败、某个依赖服务没启动导致超时、环境变量配错连到了测试环境之外的库、浏览器版本和驱动版本不匹配。这些问题看起来低级但每次都能耗掉你半天。我的做法是把环境准备做成幂等的脚本。所谓幂等就是不管跑多少次结果都一样。具体来说每次e2e开始前脚本会做这几件事清理测试数据库的特定表或schema、重新灌入基线数据、检查所有依赖服务的健康检查接口、确认配置文件指向正确的环境、启动必要的mock服务。这些步骤全部自动化不依赖人工操作。对于profile1这种快速档环境可以更轻量。比如用容器化的数据库每次启动一个全新的实例跑完就销毁。这样数据绝对干净不会互相污染。代价是启动时间稍长但比起排查数据污染的时间这点启动时间完全值得。如果团队有现成的测试环境管理平台那就更好直接申请一个隔离的命名空间。注意千万不要让e2e直接跑在共享的测试环境上尤其是多人同时跑的时候。数据互相覆盖是必然的失败会变得随机且无法复现。3.2 数据构造自包含是唯一原则e2e的数据构造有个铁律每条用例的数据必须自包含。什么意思就是这条用例需要的数据由它自己创建用完自己清理不依赖其他用例创建的数据也不依赖数据库里预先存在的“历史数据”。很多团队为了省事直接在测试库里塞一批固定数据所有用例都读这批数据。短期看很方便长期看是灾难。因为一旦某个用例修改了这批数据其他用例就挂了而且你很难定位是谁改的。自包含的数据构造通常有两种方式。一种是通过API创建比如用例开始前调用创建用户的接口拿到返回的ID然后用这个ID走后续流程。另一种是直接操作数据库插入必要的数据行。前者更贴近真实用户行为后者更快但耦合数据库结构。我一般优先用API创建只有在API不支持或者太慢的情况下才用数据库直插。数据清理同样重要。如果用例跑完不清理下次跑可能因为唯一约束冲突而失败。清理可以在用例结束时做也可以在用例开始时做“防御性清理”。我倾向于两者都做开始时确保没有残留结束时尽量清理。对于profile1这种高频跑的档位数据清理必须极其可靠否则跑几次就脏了。3.3 断言策略别只断言“没报错”新手写e2e最常见的毛病是断言太弱。比如一个下单流程脚本跑完了没有抛异常就认为通过了。这其实什么都没验证。用户可能下单后订单状态不对可能金额算错了可能库存没扣减。这些都不会让脚本抛异常但都是严重问题。好的断言应该覆盖三个层面界面层面、接口层面、数据层面。界面层面检查关键元素是否出现、文案是否正确。接口层面检查返回的状态码和关键字段。数据层面直接查数据库或通过查询接口确认数据落库正确。三个层面都通过才算这条e2e真的过了。断言还要注意“等待”的问题。前端渲染是异步的你点完按钮立刻断言很可能元素还没出来。这时候需要智能等待比如等待某个特定元素出现或者等待某个网络请求完成。不要用固定sleep固定sleep要么太短导致偶发失败要么太长拖慢整个套件。用条件等待条件满足就继续不满足就超时失败。3.4 失败重试用对了是帮手用错了是遮羞布e2e失败重试是个有争议的话题。支持的人说e2e本来就有环境抖动重试能过滤掉偶发失败。反对的人说重试会掩盖真实的bug让团队对失败麻木。我的观点是重试可以用但必须有限制、有记录、有分析。限制是指重试次数不能多通常一次就够了。重试两次还失败基本不是抖动问题。记录是指每次重试都要记下来哪个用例重试了、重试后过了还是没过。如果一个用例经常需要重试才过那它就是个不稳定用例必须修。分析是指定期看重试数据找出高频不稳定的用例集中治理。我一般会在profile1里关闭重试因为profile1的用例少且核心失败就是失败必须立刻查。profile2和profile3可以开一次重试但重试结果要单独标记不能和首次通过混在一起。这样既保证了核心档位的严格性又给了全量档位一定的容错空间。4. 实操过程与核心环节实现4.1 从零搭一个最小e2e框架假设你现在要为一个Web应用搭e2e技术栈选型上我推荐Playwright或Cypress两者都很成熟。这里以Playwright为例因为它对多浏览器、多语言支持更好而且自带等待机制比较省心。下面是一个最小可运行的骨架。首先初始化项目并安装依赖mkdir e2e-demo cd e2e-demo npm init -y npm install -D playwright/test npx playwright install然后创建配置文件playwright.config.ts这里就是profile概念的落地处import { defineConfig } from playwright/test; export default defineConfig({ testDir: ./tests, timeout: 30000, retries: process.env.CI ? 1 : 0, use: { baseURL: process.env.BASE_URL || http://localhost:3000, trace: on-first-retry, screenshot: only-on-failure, }, projects: [ { name: profile1, testMatch: /.*\.smoke\.spec\.ts/, retries: 0, }, { name: profile2, testMatch: /.*\.regression\.spec\.ts/, retries: 1, }, ], });这个配置里profile1只跑文件名带.smoke.的用例不重试。profile2跑.regression.的用例允许一次重试。通过npx playwright test --projectprofile1就能只跑冒烟档。4.2 写一条自包含的核心链路用例下面这条用例模拟用户登录后创建一个订单并确认订单出现在列表里。注意数据是自包含的断言覆盖了界面和数据两个层面。import { test, expect } from playwright/test; test(用户登录后创建订单并能在列表中看到, async ({ page, request }) { const uniqueSuffix Date.now(); const username e2e_user_${uniqueSuffix}; const password Test123456; // 通过API创建独立用户保证数据自包含 const createUserResp await request.post(/api/test/users, { data: { username, password }, }); expect(createUserResp.ok()).toBeTruthy(); // 界面登录 await page.goto(/login); await page.fill(#username, username); await page.fill(#password, password); await page.click(#login-button); await expect(page.locator(.user-avatar)).toBeVisible(); // 创建订单 await page.goto(/orders/new); await page.fill(#product-name, e2e_product_${uniqueSuffix}); await page.fill(#quantity, 2); await page.click(#submit-order); await expect(page.locator(.order-success)).toBeVisible(); // 界面断言订单出现在列表 await page.goto(/orders); await expect(page.locator(texte2e_product_${uniqueSuffix})).toBeVisible(); // 数据断言通过API确认订单落库 const orderResp await request.get(/api/orders?keyworde2e_product_${uniqueSuffix}); const orderData await orderResp.json(); expect(orderData.total).toBe(1); expect(orderData.items[0].quantity).toBe(2); });这条用例有几个关键点。第一用户名带时间戳避免和已有数据冲突。第二通过API创建用户而不是界面注册减少界面依赖提高速度。第三断言既有界面可见性也有API返回的数据校验。第四没有用固定sleep全部用Playwright的自动等待。4.3 参数计算超时和并发怎么定e2e的超时时间不能拍脑袋定。我的方法是先跑一遍记录每条用例的实际耗时然后取P95耗时乘以2作为超时。比如核心链路P95是8秒那超时设16到20秒比较合理。设太短会导致正常波动也失败设太长会让真正卡死的用例拖慢整个套件。并发数同样需要计算。假设你有20条profile1用例单条平均10秒串行跑就是200秒。如果机器有4个CPU核心每个用例大概占0.5到1个核心那并发4能压到50到60秒。但并发太高会导致资源竞争反而让用例变慢或失败。我的经验是并发数不超过CPU核心数且要观察实际运行时的CPU和内存占用。如果并发跑的时候失败率明显上升就降并发。对于profile1我通常要求整个套件在5分钟内跑完。如果超了要么减用例要么优化用例要么加机器。不能因为“用例多”就放任它跑20分钟那样没人会在提交前跑它profile1就失去意义了。4.4 接入CI流水线e2e最终要接入CI才有价值。我的做法是在合并请求的流水线里跑profile1在主干合并后跑profile2在发版前跑profile3。profile1必须快所以只跑最核心的冒烟用例并且用独立的容器环境避免和其他任务抢资源。CI配置里要注意几点。第一失败时保存trace、截图和视频方便排查。第二设置合理的超时防止卡死的任务占着资源。第三把e2e结果和代码变更关联起来比如在合并请求里直接显示哪些e2e失败。第四profile1失败要阻断合并profile2失败可以告警但不阻断profile3失败必须人工确认。提示CI上的e2e环境最好每次都是全新的用容器编排工具动态创建和销毁。共享的CI环境是e2e不稳定的重灾区。5. 常见问题与排查技巧实录5.1 常见问题速查表问题现象可能原因排查方向解决建议用例偶发失败重跑就过环境抖动、异步等待不足、数据竞争看失败截图和trace检查是否有固定sleep改用条件等待隔离数据profile1关闭重试用例一直失败报元素找不到页面改版、选择器失效、加载超时检查选择器是否还匹配当前DOM用稳定的data-testid属性避免依赖样式类名数据断言失败但界面正常数据落库延迟、事务未提交、缓存未刷新查数据库确认数据状态检查是否有异步写入增加轮询等待或通过API确认最终状态套件越跑越慢数据累积、日志膨胀、资源泄漏监控每次运行的耗时趋势每次运行前清理环境限制日志大小CI上失败但本地通过环境差异、依赖版本不一致、网络策略不同对比本地和CI的环境变量、依赖版本用容器统一环境锁定依赖版本5.2 独家避坑技巧第一个技巧是关于选择器的。很多团队用CSS类名或XPath做选择器页面一改版就全挂。我的做法是要求前端在关键元素上加> e2e测试与profile1配置实战：从环境准备到CI接入的完整指南
1. 从“e2e”这个标题说起它到底指什么第一次看到“e2e”这个标题很多人脑子里会蹦出好几个答案。做测试的会想到端到端测试做通信的会想到端到端加密做产品的会想到端到端流程做AI的最近还会想到端到端模型。这个标题本身足够短短到像一个内部代号但它背后能承载的东西非常多。我之所以想认真聊这个话题是因为“e2e”这三个字符在最近的技术讨论里出现频率明显变高了尤其是“e2e profile1”这个说法开始在一些圈子里流传说明它已经从一个单纯的缩写变成了某种方案选型的代名词。先把范围收一收。这篇内容我主要围绕“e2e”作为一个工程实践主题来展开重点放在端到端测试与端到端流程验证这条线上同时会把“e2e profile1”作为一个配置档位的概念来解释。为什么选这个角度因为在实际项目里e2e最容易出问题的地方从来不是“写一个测试脚本”本身而是整个链路的组织方式、环境准备、数据构造、断言策略和失败排查。这些细节如果没人讲透你写出来的e2e就是一堆跑一次就废的脚本维护成本高到让人想删库。这篇文章适合谁看如果你正在负责一个需要跨多个模块、多个服务、甚至多个端的产品并且已经被“改一处崩三处”搞到头疼那e2e这套东西你迟早要碰。如果你只是听说过e2e但不知道从哪下手我也会从最基础的概念和最小可运行方案讲起。如果你已经在写e2e但总觉得不稳定、跑得慢、维护累那中间关于profile配置和排查技巧的部分应该能帮你省不少时间。我自己的经验是e2e这件事最怕两种极端一种是觉得它太重要什么都要端到端测一遍结果套件跑一次要两个小时没人愿意等另一种是觉得它太脆弱干脆不写最后线上出问题全靠人肉回归。合理的做法是在中间找一个平衡点用分层策略把e2e用在刀刃上。下面我就按这个思路把e2e的整体设计、核心细节、实操过程和常见问题一块一块拆开讲。2. e2e整体设计与思路拆解2.1 为什么e2e不能“什么都测”端到端测试的核心价值在于验证“用户视角的完整链路”。比如用户从打开页面、登录、下单、支付到收到确认这一整条路走通才叫端到端。它的优势是贴近真实场景能发现单元测试和集成测试发现不了的跨系统问题。但它的代价也很明显慢、脆、依赖多。我见过不少团队一开始热情很高把几乎所有功能都写成e2e结果半年后这套件没人敢动。原因很简单每加一个功能就要加几条e2e环境稍微抖一下全红排查一个失败要翻五六个服务的日志。所以设计e2e的第一原则不是“覆盖全”而是“选关键路径”。通常我会把链路按业务价值分成三档核心交易链路、重要但非交易链路、边缘链路。e2e只覆盖第一档和第二档里最容易出跨系统问题的部分剩下的交给下层测试。这个取舍背后的逻辑是成本收益比。一条e2e的编写成本可能是单元测试的十倍维护成本可能是二十倍。如果它验证的东西单元测试也能验证那这条e2e就是负资产。只有那些“必须多个真实组件一起工作才能验证”的场景才值得用e2e。2.2 e2e profile1到底在配什么“e2e profile1”这个说法我理解为一套预设的e2e运行配置档。在实际项目里e2e通常不会只有一种跑法而是根据目的不同分成几个profile。profile1往往是最基础、最稳定、跑得最快的那一档用来做日常提交前的快速验证。它可能只跑核心链路的冒烟用例环境用本地或轻量容器数据用预置的固定数据集。为什么要有profile这个概念因为e2e的使用场景是分层的。开发本地改完代码需要几分钟内知道核心链路有没有断这时候跑全量e2e不现实。CI流水线上每次合并请求需要比本地更全一点但也不能太久。 nightly构建或者发版前才需要跑最完整的e2e。如果只有一套配置你要么太慢要么覆盖不够。profile就是把“跑哪些用例、用什么环境、造什么数据、并发多少”这些参数打包成几个档位按需切换。我一般会设计三个profileprofile1是冒烟级5到10分钟profile2是回归级30分钟左右profile3是全量级可能一两个小时只在发版前跑。profile1的用例选择标准是“如果这条断了整个产品基本不可用”。比如登录、核心查询、核心写入、核心支付。这些用例必须极其稳定环境依赖降到最低数据尽量自包含。2.3 分层策略e2e在测试金字塔里的位置测试金字塔这个概念很多人听过但实际落地时容易走形。底层是大量单元测试中间是集成测试顶层是少量e2e。e2e的“少量”不是随便说的通常建议不超过总用例数的10%到15%。如果e2e占比超过30%基本可以判断这个团队的测试策略出了问题。为什么e2e要少因为它的反馈周期长、失败原因复杂、修复成本高。单元测试失败你打开文件看一眼就知道哪错了。e2e失败可能是代码问题、环境问题、数据问题、网络问题、第三方服务问题甚至时间同步问题。排查一条e2e失败的时间可能够你写二十条单元测试。所以e2e的定位应该是“最后一道防线”而不是“主要验证手段”。但这不意味着e2e可以随便写。恰恰因为它少每一条都要写得极其扎实。我的做法是每条e2e都要有明确的业务场景描述、清晰的断言点、独立的测试数据、可重试的失败处理。宁可一条e2e覆盖一个完整场景也不要拆成五条互相依赖的碎片用例。碎片用例之间的依赖是e2e不稳定的最大来源之一。3. 核心细节解析与实操要点3.1 环境准备e2e稳定的地基e2e跑不起来十有八九是环境问题。我踩过的坑包括数据库里残留了上次跑的数据导致断言失败、某个依赖服务没启动导致超时、环境变量配错连到了测试环境之外的库、浏览器版本和驱动版本不匹配。这些问题看起来低级但每次都能耗掉你半天。我的做法是把环境准备做成幂等的脚本。所谓幂等就是不管跑多少次结果都一样。具体来说每次e2e开始前脚本会做这几件事清理测试数据库的特定表或schema、重新灌入基线数据、检查所有依赖服务的健康检查接口、确认配置文件指向正确的环境、启动必要的mock服务。这些步骤全部自动化不依赖人工操作。对于profile1这种快速档环境可以更轻量。比如用容器化的数据库每次启动一个全新的实例跑完就销毁。这样数据绝对干净不会互相污染。代价是启动时间稍长但比起排查数据污染的时间这点启动时间完全值得。如果团队有现成的测试环境管理平台那就更好直接申请一个隔离的命名空间。注意千万不要让e2e直接跑在共享的测试环境上尤其是多人同时跑的时候。数据互相覆盖是必然的失败会变得随机且无法复现。3.2 数据构造自包含是唯一原则e2e的数据构造有个铁律每条用例的数据必须自包含。什么意思就是这条用例需要的数据由它自己创建用完自己清理不依赖其他用例创建的数据也不依赖数据库里预先存在的“历史数据”。很多团队为了省事直接在测试库里塞一批固定数据所有用例都读这批数据。短期看很方便长期看是灾难。因为一旦某个用例修改了这批数据其他用例就挂了而且你很难定位是谁改的。自包含的数据构造通常有两种方式。一种是通过API创建比如用例开始前调用创建用户的接口拿到返回的ID然后用这个ID走后续流程。另一种是直接操作数据库插入必要的数据行。前者更贴近真实用户行为后者更快但耦合数据库结构。我一般优先用API创建只有在API不支持或者太慢的情况下才用数据库直插。数据清理同样重要。如果用例跑完不清理下次跑可能因为唯一约束冲突而失败。清理可以在用例结束时做也可以在用例开始时做“防御性清理”。我倾向于两者都做开始时确保没有残留结束时尽量清理。对于profile1这种高频跑的档位数据清理必须极其可靠否则跑几次就脏了。3.3 断言策略别只断言“没报错”新手写e2e最常见的毛病是断言太弱。比如一个下单流程脚本跑完了没有抛异常就认为通过了。这其实什么都没验证。用户可能下单后订单状态不对可能金额算错了可能库存没扣减。这些都不会让脚本抛异常但都是严重问题。好的断言应该覆盖三个层面界面层面、接口层面、数据层面。界面层面检查关键元素是否出现、文案是否正确。接口层面检查返回的状态码和关键字段。数据层面直接查数据库或通过查询接口确认数据落库正确。三个层面都通过才算这条e2e真的过了。断言还要注意“等待”的问题。前端渲染是异步的你点完按钮立刻断言很可能元素还没出来。这时候需要智能等待比如等待某个特定元素出现或者等待某个网络请求完成。不要用固定sleep固定sleep要么太短导致偶发失败要么太长拖慢整个套件。用条件等待条件满足就继续不满足就超时失败。3.4 失败重试用对了是帮手用错了是遮羞布e2e失败重试是个有争议的话题。支持的人说e2e本来就有环境抖动重试能过滤掉偶发失败。反对的人说重试会掩盖真实的bug让团队对失败麻木。我的观点是重试可以用但必须有限制、有记录、有分析。限制是指重试次数不能多通常一次就够了。重试两次还失败基本不是抖动问题。记录是指每次重试都要记下来哪个用例重试了、重试后过了还是没过。如果一个用例经常需要重试才过那它就是个不稳定用例必须修。分析是指定期看重试数据找出高频不稳定的用例集中治理。我一般会在profile1里关闭重试因为profile1的用例少且核心失败就是失败必须立刻查。profile2和profile3可以开一次重试但重试结果要单独标记不能和首次通过混在一起。这样既保证了核心档位的严格性又给了全量档位一定的容错空间。4. 实操过程与核心环节实现4.1 从零搭一个最小e2e框架假设你现在要为一个Web应用搭e2e技术栈选型上我推荐Playwright或Cypress两者都很成熟。这里以Playwright为例因为它对多浏览器、多语言支持更好而且自带等待机制比较省心。下面是一个最小可运行的骨架。首先初始化项目并安装依赖mkdir e2e-demo cd e2e-demo npm init -y npm install -D playwright/test npx playwright install然后创建配置文件playwright.config.ts这里就是profile概念的落地处import { defineConfig } from playwright/test; export default defineConfig({ testDir: ./tests, timeout: 30000, retries: process.env.CI ? 1 : 0, use: { baseURL: process.env.BASE_URL || http://localhost:3000, trace: on-first-retry, screenshot: only-on-failure, }, projects: [ { name: profile1, testMatch: /.*\.smoke\.spec\.ts/, retries: 0, }, { name: profile2, testMatch: /.*\.regression\.spec\.ts/, retries: 1, }, ], });这个配置里profile1只跑文件名带.smoke.的用例不重试。profile2跑.regression.的用例允许一次重试。通过npx playwright test --projectprofile1就能只跑冒烟档。4.2 写一条自包含的核心链路用例下面这条用例模拟用户登录后创建一个订单并确认订单出现在列表里。注意数据是自包含的断言覆盖了界面和数据两个层面。import { test, expect } from playwright/test; test(用户登录后创建订单并能在列表中看到, async ({ page, request }) { const uniqueSuffix Date.now(); const username e2e_user_${uniqueSuffix}; const password Test123456; // 通过API创建独立用户保证数据自包含 const createUserResp await request.post(/api/test/users, { data: { username, password }, }); expect(createUserResp.ok()).toBeTruthy(); // 界面登录 await page.goto(/login); await page.fill(#username, username); await page.fill(#password, password); await page.click(#login-button); await expect(page.locator(.user-avatar)).toBeVisible(); // 创建订单 await page.goto(/orders/new); await page.fill(#product-name, e2e_product_${uniqueSuffix}); await page.fill(#quantity, 2); await page.click(#submit-order); await expect(page.locator(.order-success)).toBeVisible(); // 界面断言订单出现在列表 await page.goto(/orders); await expect(page.locator(texte2e_product_${uniqueSuffix})).toBeVisible(); // 数据断言通过API确认订单落库 const orderResp await request.get(/api/orders?keyworde2e_product_${uniqueSuffix}); const orderData await orderResp.json(); expect(orderData.total).toBe(1); expect(orderData.items[0].quantity).toBe(2); });这条用例有几个关键点。第一用户名带时间戳避免和已有数据冲突。第二通过API创建用户而不是界面注册减少界面依赖提高速度。第三断言既有界面可见性也有API返回的数据校验。第四没有用固定sleep全部用Playwright的自动等待。4.3 参数计算超时和并发怎么定e2e的超时时间不能拍脑袋定。我的方法是先跑一遍记录每条用例的实际耗时然后取P95耗时乘以2作为超时。比如核心链路P95是8秒那超时设16到20秒比较合理。设太短会导致正常波动也失败设太长会让真正卡死的用例拖慢整个套件。并发数同样需要计算。假设你有20条profile1用例单条平均10秒串行跑就是200秒。如果机器有4个CPU核心每个用例大概占0.5到1个核心那并发4能压到50到60秒。但并发太高会导致资源竞争反而让用例变慢或失败。我的经验是并发数不超过CPU核心数且要观察实际运行时的CPU和内存占用。如果并发跑的时候失败率明显上升就降并发。对于profile1我通常要求整个套件在5分钟内跑完。如果超了要么减用例要么优化用例要么加机器。不能因为“用例多”就放任它跑20分钟那样没人会在提交前跑它profile1就失去意义了。4.4 接入CI流水线e2e最终要接入CI才有价值。我的做法是在合并请求的流水线里跑profile1在主干合并后跑profile2在发版前跑profile3。profile1必须快所以只跑最核心的冒烟用例并且用独立的容器环境避免和其他任务抢资源。CI配置里要注意几点。第一失败时保存trace、截图和视频方便排查。第二设置合理的超时防止卡死的任务占着资源。第三把e2e结果和代码变更关联起来比如在合并请求里直接显示哪些e2e失败。第四profile1失败要阻断合并profile2失败可以告警但不阻断profile3失败必须人工确认。提示CI上的e2e环境最好每次都是全新的用容器编排工具动态创建和销毁。共享的CI环境是e2e不稳定的重灾区。5. 常见问题与排查技巧实录5.1 常见问题速查表问题现象可能原因排查方向解决建议用例偶发失败重跑就过环境抖动、异步等待不足、数据竞争看失败截图和trace检查是否有固定sleep改用条件等待隔离数据profile1关闭重试用例一直失败报元素找不到页面改版、选择器失效、加载超时检查选择器是否还匹配当前DOM用稳定的data-testid属性避免依赖样式类名数据断言失败但界面正常数据落库延迟、事务未提交、缓存未刷新查数据库确认数据状态检查是否有异步写入增加轮询等待或通过API确认最终状态套件越跑越慢数据累积、日志膨胀、资源泄漏监控每次运行的耗时趋势每次运行前清理环境限制日志大小CI上失败但本地通过环境差异、依赖版本不一致、网络策略不同对比本地和CI的环境变量、依赖版本用容器统一环境锁定依赖版本5.2 独家避坑技巧第一个技巧是关于选择器的。很多团队用CSS类名或XPath做选择器页面一改版就全挂。我的做法是要求前端在关键元素上加>