1. 我为什么决定把 e2e 测试当作正经工程来做
先聊聊最直接的一个感受。很多人一听到 e2e，第一反应是"哦，就是端到端测试"，然后立刻联想到 Playwright、Cypress 这类工具，觉得找时间写几个用例就行。但真正在项目里把 e2e 跑起来、跑稳定、跑出价值，完全不是这么回事。
我最早接触 e2e 是在一个中大型后台管理系统上，那时候项目已经上线了，每次发版前都要人工把核心流程点一遍：登录、建单、审批、导出，几个页面来回跳，至少得花一两个小时。后来业务方提了个需求，要在某个复杂流程里新增一个状态流转，前端改了十几个组件，结果上线当天才发现某个联动逻辑坏了，用户数据差点出错。就是那次事故之后，我才下定决心把 e2e 测试当成一个必须长期维护的工程来做，而不是临时写几个脚本应付检查。
这篇内容我想从一个实践者的角度，把 e2e 测试从策略设计、用例编写、执行环境，到排查问题这套完整链路讲清楚。适合谁看呢？两类人：一类是刚接触 e2e、不知道从哪里下手的测试同学或前端同学；另一类是已经写了几个 e2e 用例，但发现用例老是挂、维护成本越来越高、CI 里动不动就红，想系统梳理一遍思路的开发者。整篇不会绕弯子，全部是我自己踩过坑之后整理出来的"少走弯路"方案。
先说一个核心观念：e2e 测试的价值不在"测试"这两个字，而在"端到端"这三个字。它验证的不是某个函数返回了正确结果，也不是某个组件渲染出了正确 DOM，而是整条用户链路——从用户打开页面、输入数据、点击按钮、发出请求、后端处理、再回到前端展示——这一整条链路是否真的符合业务预期。所以 e2e 测试的用例设计视角，得从"程序员怎么写代码"切换成"用户怎么用产品"。
2. e2e 测试的策略设计：先想清楚再写用例
2.1 e2e、集成测试、单元测试的分工边界
在写任何 e2e 用例之前，得先想清楚一个边界问题：什么东西应该用 e2e 测，什么东西应该用更底层的测试去覆盖。如果这个边界没想清楚，很容易出现两种极端情况：要么 e2e 用例写得又多又杂，跑一次要半小时，维护成本高到让人想放弃；要么 e2e 只覆盖了登录这种无关痛痒的流程，真正核心的业务链路反而裸奔。
我的习惯是给三个测试层级画一条清晰分工线。单元测试管的是"这个函数在这个输入下能不能返回预期输出"，比如一个日期格式化工具、一个金额计算函数，这种逻辑用单元测试测，定位问题快，跑得也快。集成测试管的是"几个模块拼在一起能不能对上接口"，比如前端调后端的某个 API，参数传对了没有、返回的数据结构能不能被正确消费。e2e 测试管的是"用户能不能完成一次完整的业务操作"，比如从注册到下单再到支付成功，这个过程的每一步都需要真实发生，任何一个环节断了，用例就挂。
这三者不是替代关系，而是过滤关系。单元测试和集成测试把底层 90% 的问题过滤掉，e2e 只需要关注那 10% 的跨模块、跨系统、真实用户路径上的问题。如果单元测试和集成测试做得足够扎实，e2e 用例的数量其实不需要特别多，但每一条都要打在关键业务链路上。
2.2 如何挑选需要做 e2e 覆盖的核心业务链路
这一步直接决定 e2e 测试能产生多大价值。我见过不少团队的做法是把所有页面跳转都写一遍 e2e，结果用例数量庞大、执行时间漫长、每次前端组件一改就红一片，最后项目组干脆不看 e2e 报告了。这种"为了覆盖率而覆盖率"的做法，本质上是把 e2e 当成了撒网工具，但 e2e 的代价决定了它不适合撒网。
我的筛选标准有三个维度。第一个维度是业务价值，这个链路如果挂了对用户影响有多大？比如支付流程挂了，用户付不了钱，这是 P0 级别，必须覆盖。第二个维度是跨系统复杂度，这个链路是不是要经过多个系统、多个服务、多个团队？流程越是跨系统，越容易在接口对不上、数据状态不一致这些地方出问题，越值得用 e2e 去兜底。第三个维度是回归频率，这个功能是不是经常被改动、经常出现回归？一个每周都有新需求的模块，比一个半年都不动的静态页面更需要 e2e 保护。
用这三个维度过一遍项目需求，基本能筛出一份核心链路清单。以我当时的后台系统为例，最终定了四条必须用 e2e 覆盖的链路：登录鉴权、管理员创建用户并分配角色、数据导入导出、审批流状态流转。这四个链路覆盖了当时项目里"出过事故"或"风险最高"的全部场景，加起来十六七个用例，比原来动不动上百个用例的方案收敛得多，执行时间控制在十分钟以内，维护成本也大幅下降。
2.3 测试数据管理：e2e 稳定性的地基
很多人写 e2e 用例，第一步就打开页面开始操作，完全不考虑数据从哪来。这是后面用例开始随机挂掉的最常见根源。e2e 和单元测试不一样，它跑在真实环境里，会真实地创建数据、修改数据、删数据，如果数据不隔离、不清理，跑到第 N 次就会因为上一轮留下的脏数据产生各种奇怪失败。
怎么管理测试数据，我总结了三层做法。第一层是接口造数，在执行 e2e 用例前置步骤之前，直接通过后端 API 把测试需要的数据准备好。比如要测审批流状态流转，就通过接口提前创建好一个待审批的单据，e2e 用例直接从操作这个单据开始，不需要在界面里一步步把单据建出来。这样做的好处是速度快、依赖少，缺点是要求被测系统有稳定可用的 API 文档，而且这些 API 本身得靠谱。第二层是数据库直连造数，适合那些接口还不完善或者造数逻辑特别复杂的场景，直接往测试库里插入符合业务状态的记录。第三层是 UI 操作造数，只在前面两层都不好使的时候才用，因为通过 UI 造数速度慢、而且它本身就在执行一部分业务逻辑，万一造数步骤挂了，很难判断是被测功能的问题还是造数流程的问题。
另外还有一件非常重要的事：测试数据必须带上明显的标识符，并且在用例结束之后尽量清理。我习惯在每条测试数据里加上用例 ID 或者时间戳这种唯一标记，比如创建一个用户名为e2e_user_20250120_001的测试账号，这样即使清理逻辑偶发失效，排查的时候也能一眼看出来哪些数据是测试残留的。
3. 工具选型与执行环境搭建
3.1 主流 e2e 工具对比：Playwright、Cypress 与 Selenium
聊到 e2e 工具，现在市面上主流的几款大家应该都听说过，但"听说过"和"真正知道自己该选哪个"是两回事。我这几款都用过，简单说下实际感受。
Selenium 是最老牌的工具了，支持多种语言、多种浏览器，插件生态也很庞大。但它的问题在于 API 设计相对底层，写出来的代码啰嗦，而且稳定性依赖 WebDriver 的版本匹配，经常出现浏览器一升级、WebDriver 没跟上导致整个测试环境崩掉的情况。如果从一个新项目的角度去选型，我基本上不会推荐从 Selenium 开始了。
Cypress 把 e2e 的体验往前推了一大截，尤其它那个交互式调试界面，点一下就能看到每一步对应的页面截图和 DOM 快照，排查用例失败的时候非常直观。但 Cypress 有一个我在实际项目中不太舒服的点：它对多标签页和跨域场景的支持比较绕，某些传统 Web 应用里的跳转方式它接管不了。如果被测系统是新一代的 SPA，Cypress 用起来会比较顺手。
我目前的主力工具是 Playwright。选它有几个很实在的理由：首先是安装简单，通过 npm 一条命令就能把依赖和浏览器一起装好，不像 Selenium 还要手动去维护 driver；其次是它的自动等待机制做得非常好，绝大多数情况下不需要手工在代码里写死 sleep 等待，框架会自动等元素可操作再继续；第三是它对多浏览器、多标签页、移动端视口的支持都很自然，一套用例可以同时跑 Chromium、Firefox、WebKit。
下面用一张表做个直观对比，方便你按自己项目的情况做选择：
| 维度 | Selenium | Cypress | Playwright |
|---|---|---|---|
| 安装复杂度 | 需要维护 WebDriver | 相对简单 | 一条命令安装浏览器 |
| 多浏览器支持 | 好 | 一般 | 非常好 |
| 自动等待机制 | 弱，需要手写等待 | 内置 | 内置且智能 |
| 调试体验 | 一般 | 交互式回放 | Trace Viewer |
| 多标签页/跨域场景 | 支持 | 较弱 | 支持 |
| 上手成本 | 偏高 | 低 | 低 |
上面的对比只代表我个人的实际体感，工具没有绝对的好坏，关键是匹配自己要测的系统形态。但有一条建议是通用的：e2e 工具选型要趁早，因为用例累积起来之后切换工具的成本非常高，我在真实项目中经历过从 Selenium 迁到 Playwright 的过程，一百多条用例硬生生重写了两个星期。
3.2 本地开发环境、CI 流水线和测试环境隔离
工具选好了，下一步是搭执行环境。这个环节最容易犯的错误，是只在本地跑 e2e，从来没在 CI 里正经跑过一次。本地跑和 CI 跑的差别非常大，最大的差别之一是网络环境影响，本地访问测试环境可能几十毫秒就响应了，CI 容器里可能因为网络抖动直接超时。所以我的建议是：环境搭建的第一天，就把 CI 跑起来，不要等用例写完再想 CI 的事。
前面说过怎么把 Playwright 配到 CI 里，下面把顺序再细化一下。先把 Cl 流程里的执行命令盯着看一遍，跑的时候要注意 CI 用的浏览器依赖，容器里可能缺一些操作系统的库。虽然官方镜像一般已经预装好了，但如果你不用官方镜像，很可能会踩到缺依赖的坑。等跑稳定了，再考虑并行分片执行，这个功能在用例数量上来以后价值很大，团队里的用例从十几条涨到上百条的阶段，不发散、分片一跑，十分钟能压缩到两三分钟，反馈速度会有一个很明显的提升。
测试环境隔离是我要单独拎出来强调的一点。e2e 测试必须有一套独立的测试环境，不能和开发自测环境混着用，更不能拿生产环境来跑。我见过一个特别典型的反面案例：某个团队为了"省事"，直接在预发环境跑 e2e，预发环境里同时还有其他同事在手工验证功能，两边操作的同一条业务数据互相脏写，e2e 用例时不时就挂一次，查了几天都找不到根因，最后发现是测试环境打架。从那之后我就定了两条死规矩：测试环境独立部署，且只允许测试脚本访问；测试环境的数据源独立，绝不复用其他环境的数据库。
3.3 e2e profile：一套用例怎么跑出多套业务场景
标题里有个热词叫 e2e profile，可能有些人不太熟，这里专门展开讲一下。所谓 profile，说白了就是给同一套 e2e 用例配上不同的"运行档案"，让同样的用例代码在不同的环境下、用不同的配置参数跑出不同的测试效果。
我最早接触 e2e profile 是因为一个很实际的痛点：公司有多个测试环境，每个环境的后端地址不同、部分功能的开关不同、测试账号也不同，如果每套环境都维护一份用例代码，那光同步代码就能把人累死。后来我引入了 profile 机制，把环境相关的所有配置全部抽出来，放到 profile 文件里，用例代码里面不允许出现环境相关的硬编码。
举个具体例子。我的 Playwright 项目里会有这样的配置结构：
config/ playwright.base.ts # 公共配置 playwright.dev.ts # 开发环境 profile playwright.staging.ts # 联调环境 profile playwright.prod.ts # 生产冒烟 profile每个 profile 文件只维护自己独特的字段，比如baseURL、testAccount、featureSwitch这些，公共部分继承自 base 配置。跑用例的时候通过环境变量指定用哪个 profile：
# 在开发环境跑 PLAYWRIGHT_PROFILE=dev npx playwright test # 在联调环境跑 PLAYWRIGHT_PROFILE=staging npx playwright test # 跑生产冒烟用例集 PLAYWRIGHT_PROFILE=prod npx playwright test --grep @smoke这样做的收益非常明显：新增一套测试环境，不需要改用例代码，只需要新增一个 profile 配置文件；某些环境不支持的功能，可以在 profile 里打标记，用例层面用条件判断跳过；同一套用例既可以在日常联调环境全量回归，也可以在预发环境只跑冒烟集，灵活度很高。这个模式是我目前做 e2e 测试工程化最推荐的一个实践，无论你是三五条用例的小项目还是上百条用例的大项目，都可以用类似思路去管理。
4. 核心 e2e 用例的编写实战
4.1 一条完整用例应该长什么样
前面把策略和环境都铺完了，这一节开始进入最核心的实操部分：一条真正稳定的 e2e 用例应该怎么编。我先放一个完整的例子，后面逐步拆解每段代码背后的设计逻辑。
假设我们的业务里有一条主链路：管理员在后台新建一个用户，然后给这个用户分配一个角色，最后验证这个用户能正常登录。这条链路覆盖了三个核心操作，跨了用户管理和鉴权两个模块，非常有代表性。
import { test, expect } from '@playwright/test'; test('管理员新建用户并分配角色后，该用户可以正常登录', async ({ page }) => { // 前置：通过接口准备管理员会话 const adminToken = await requestLogin('admin', process.env.ADMIN_PASSWORD!); const newUser = `e2e_user_${Date.now()}`; test.step('创建用户', async () => { await page.goto('/admin/users/create'); await page.getByLabel('用户名').fill(newUser); await page.getByLabel('初始密码').fill('Test@12345'); await page.getByRole('button', { name: '保存' }).click(); await expect(page.getByText('创建成功')).toBeVisible(); }); test.step('分配角色', async () => { await page.getByRole('button', { name: '分配角色' }).click(); await page.getByRole('checkbox', { name: '运营审核岗' }).check(); await page.getByRole('button', { name: '确认' }).click(); await expect(page.getByText('角色分配成功')).toBeVisible(); }); test.step('验证新用户登录', async () => { const newPage = await page.context().newPage(); await newPage.goto('/login'); await newPage.getByLabel('用户名').fill(newUser); await newPage.getByLabel('密码').fill('Test@12345'); await newPage.getByRole('button', { name: '登录' }).click(); await expect(newPage.getByText('欢迎回来，' + newUser)).toBeVisible(); }); });这段代码里有几个点值得单独说。第一，管理员登录走的是接口而不是 UI，这一步直接把 UI 操作缩短了十几秒，而且避开了登录页面可能存在的验证码、风控逻辑这些干扰项。第二，测试用户名用了Date.now()做后缀，保证每次运行时用户名都不重复，从根上避免数据冲突。第三，把用例拆成了三个 step 块，一旦用例失败，报告里能直接看到是创建、分配还是登录这一步挂的，定位问题的效率大幅提升。
4.2 元素定位与自动等待：让用例不再"忽绿忽红"
e2e 用例最让人头疼的问题，就是"我什么都没改，用例怎么就挂了？"。这种不稳定绝大多数来自两个地方：一个是元素定位写得太脆弱，另一个是等待逻辑不正确。
先说元素定位。很多新手喜欢用 CSS 选择器去定位，比如.btn-primary、#submit-btn，因为看 DOM 结构里就有这些类名和 ID，写起来非常顺手。但这种定位方式很脆：前端工程师改了一下样式，类名从btn-primary改成了btn-primary-light，你的用例当场就挂。我的习惯是优先用角色和文本定位，也就是页面上用户能感知到的信息来定位元素。比如"登录"按钮，就用page.getByRole('button', { name: '登录' })，输入框就用page.getByLabel('用户名')。用这种方式定位，前端怎么改样式都不影响你的用例，只要按钮的文案和功能不变，用例就一直稳定。如果遇到某些元素确实没有合适的角色和文本，退而求其次才用 CSS 定位，并且要做到尽量唯一的定位锚点。
再说自动等待。Playwright 的定位器自带自动等待机制，执行click()、fill()这类操作时，框架会自动等元素出现、可见、可操作，然后才执行动作。这本来是个很省心的设计，但有一个反模式恰恰是利用了这个机制：在代码里到处写page.waitForTimeout(3000)这种固定等待。我见过太多人写这种代码了，他们的逻辑是"这里可能要加载一下，我等等它"，这是完全错误的用法。固定等待会让用例执行时间被无谓拉长，而且如果这次加载花了 4 秒，你等了 3 秒就挂了；如果这次加载只花了 0.1 秒，你还要白白等 3 秒。正确做法是让等待绑定在某个具体的状态上，比如await expect(page.getByText('创建成功')).toBeVisible()，这个等待会持续检查条件是否满足，直到超时为止，既不会早跑也不会晚跑。
4.3 多标签页、接口 Mock 和网络请求验证
前面提到普通用例用页面操作，这里补充几个我经常用到的高阶技巧，这些技巧在处理复杂业务场景的时候几乎必用。
有一些系统，验证码或者短信验证码通过接口返回，这个接口的响应结构可能会变。Mock 的关键作用是不依赖第三方服务和不确定的网络环境，把这些不稳定因素挡住，这在 e2e 里可以大幅提稳。
多标签页场景主要用于两类业务：一类是保存或分享的链接在新标签页打开，另一类是跨系统跳转后回到原系统。Playwright 的context.newPage()或者waitForEvent('page')可以处理，这里不展开，只说一个高频的坑：如果点击一个链接之后在新标签页打开，直接用page这个对象去操作的话，你操作的还是旧页面，应该监听新页面的事件来拿到新页面的 page 对象再继续操作。
网络请求验证是我强烈推荐加进用例的一种断言方式。比如你要测"导出报表"，点击导出按钮之后，前端会调一个/api/export的接口，如果你只用界面层断言，只能判断"页面提示导出成功"，但接口到底有没有正常发出、返回了什么状态码，界面上看不出来。这种情况下我习惯用page.waitForResponse()去拦截并检查这个接口：
const responsePromise = page.waitForResponse(resp => resp.url().includes('/api/export') && resp.request().method() === 'POST' ); await page.getByRole('button', { name: '导出' }).click(); const response = await responsePromise; expect(response.status()).toBe(200); const body = await response.json(); expect(body.data.taskId).toBeTruthy();这个写法既验证了用户操作的真实性（按钮确实可点、点击后确实发起了正确的请求），又从接口层验证了结果（状态码、返回数据都符合预期）。如果这个用例挂了，你能很精确地知道到底是前端没调接口、还是接口报了错、还是接口返回的数据结构不对，排查范围被大大缩小。
4.4 断言的艺术：什么时候用软断言，什么时候用硬断言
最后说一个很多人忽略的细节：断言策略。硬断言是只要失败就立刻终止用例，软断言是失败后继续往下执行，最后统一报告。这两种断言各有各的适用场景，选错了同样会制造大量烦恼。
我的经验法则很简单：在一条用例里，如果前一步是后一步的前提，那前后之间的检查用硬断言；如果几个检查之间相互独立，任何一个失败都不影响其他检查继续做，那可以考虑用软断言。不过，我对软断言的态度比较保守，e2e 用例本身就比其他测试重，执行一次成本高，如果一个用例里软断言太多，等于一次跑了很多独立检查，一旦某个检查失败，后面所有的执行操作都在一个"已经出问题"的状态里继续，产生的错误信息很可能互相干扰，反而增加排查困难。
所以在实际编写中，我会尽量把一条用例收敛到一个主流程的验证，围绕这个主流程配置若干个关键的硬断言。如果确实有多个互不相关的独立业务规则要校验，我更倾向于拆成多条用例，而不是塞进一条用软断言撑着。这样做还有一个额外的好处：用例失败后，报告里显示的失败原因更聚焦，看一眼就知道业务上哪里不对。
5. 常见问题与排查技巧实录：e2e 调试实战
5.1 用例偶发失败：先查这五个地方
e2e 的偶发失败是所有人绕不开的坎，也是劝退很多人写 e2e 的最大心理障碍。我必须在最后分享一点实际的调试经验，下面这几条来自真实项目中的高频问题。
第一条，定时任务导致的页面内容变化。测试的页面上如果同时有别人在操作，或者有个定时任务在刷新某些数据，你断言的那个元素可能就消失了。这部分要靠测试环境隔离来解决。
第二条，接口超时无兜底。前端调后端接口的时候，如果后端响应超过了某个阈值，前端可能弹出一个错误提示，你断言的成功文案永远等不到。建议在 e2e 测试环境里把接口超时阈值调大，或者在用例级别配比常规环境更长的超时时间。
第三条，全局 toast 和局部操作资源互相干扰。页面弹出的全局提示往往会遮挡或者挤掉你正在操作的元素，Playwright 的自动等待会等元素可见，但如果提示有动画，通常会等它动画稳定再操作。
第四条，数据残留导致下一次运行报错。上一轮跑完的脏数据没清理，影响了本轮用例的初始化判断。强烈建议在用例的前置和后置都对测试数据做清理或者至少做唯一化处理。
第五条，CI 机器性能不足导致的超时。本地跑没事，CI 跑就挂，多半是这个问题。不要急着改代码，先看 CI 的执行日志和 Playwright 的 trace 文件。
5.2 善用 Trace Viewer、录屏和截图定位问题
排查 e2e 失败有一个好习惯：依赖现场证据，而不是依赖猜测。Playwright 默认会在失败的时候自动截图、自动保存 trace 文件，很多人没注意这些产物，失败之后直接看错误堆栈，看完就开始猜。
我的排查路径是这样的：先打开 trace 文件，用 Trace Viewer 的"时间线"功能，把用例执行过程中的每一步操作都看一遍，包括每一步的页面快照、网络请求、控制台输出。大多数情况下，滚动到失败前的一两步就能发现问题：可能是某一个元素在那一帧没有出现，可能是某个网络请求返回了 5xx，也可能是页面上弹了一个意想不到的对话框。看到现场再回头推理根因，比对着报错文本瞎猜要准确得多。
另外，建议在 CI 配置里把失败用例的截图和 trace 作为 artifact 保留下来，特别是 trace 文件的保留。截图是静态的，只能看最后一眼的页面状态；trace 能回放整个过程，信息量完全不是一个级别。
5.3 常见问题速查表
| 现象 | 常见原因 | 排查方向 |
|---|---|---|
| 用例在 CI 挂、本地不挂 | 网络波动、机器性能不足 | 查看 trace 和网络请求耗时 |
| 用例第一次跑成功、第二次就挂 | 测试数据污染 | 检查是否有重复数据残留 |
| 元素报"定位到多个元素" | 定位器写得太宽泛 | 改用角色+名称组合定位 |
| 点击按钮无响应 | 按钮被遮罩层遮挡 | 检查页面是否有弹层或动画 |
| 等待超时 | 前端接口响应过慢 | 在 profile 里调大超时时间 |
| 新标签页操作失败 | 还用原 page 对象操作 | 监听新页面对象再继续 |
| 断言文本找不到 | 页面提示文字被修改 | 用接口断言替代文本断言 |
| 浏览器起不来 | CI 镜像缺操作系统依赖 | 使用官方 Playwright 镜像 |
这个速查表当然不可能覆盖所有问题，但它涵盖了 e2e 用例从编写到落地最常碰到的八种异常，你按照表里的"排查方向"逐条对照，能省下大量瞎试的时间。
5.4 一个典型的"航班改签" debug 案例
讲一个真实案例，是我在某个航空类系统里做 e2e 排障时遇到的。当时要测一条"航班改签"的链路，用户选中一张机票、点击改签、选择新航班、提交订单、完成支付。用例每跑两三次就有一轮挂在"提交订单"这一步，而且失败时页面显示的是"订单金额与计算不一致"。
看到这个错误提示的第一反应是后端金额计算逻辑有问题，但相同的用例跑成功时，订单金额是对的，这就说明后端逻辑大概率没问题，问题出在测试的执行环境。后来我打开 trace 仔细看，发现失败轮次里"选择新航班"那一步，页面展示的却是上一轮测试留下的旧航班数据，因为航班列表有缓存，没有刷新，导致前端提交的金额和界面显示不一致。
最后的修复方式就是在"选择新航班"之前加一个关键的断言：先等新航班的数据真正出现在列表里，再继续下一步操作。这个案例给我一个很重要的启发：e2e 排障的时候，第一直觉往往是"被测功能有问题"，但真正高频的原因反而在"测试自身对状态变化的依赖没处理好"。排查的时候一定不要预设结论，把 trace 和页面快照打开，顺着时间线走一遍，问题自然就浮出水面了。
6. 从"能跑"到"好用"：我的 e2e 工程化体会
写到这里，其实已经把 e2e 测试从策略、环境、用例编写到排查的完整链路都讲了一遍。最后分享几个我在实际操作中的体会。
关于用例数量，我一直坚持"少而精"的原则。e2e 用例不是越多越好，多了以后执行时间、维护成本、不稳定概率都会同步上升，最终导致整个测试资产被废弃。我见过太多团队从一两百条 e2e 用例一路砍到只剩几条核心冒烟用例，就是因为前面铺得太广、后续维护不住了。与其这样，不如一开始就克制，只覆盖真正的核心业务链路，把每条用例的质量和稳定性打磨到位。
关于 e2e profile 的使用，我强烈建议从项目初期就引入。不需要一开始就把 profile 做得特别复杂，只要把环境相关的配置抽离出来，不要散落在用例代码里，就已经成功了一半。等到环境多起来、用例多起来，你会发现当初这个决定省下的时间非常可观。我自己就是因为后期才引入 profile，中间改了几十个文件，才深刻体会到"抽离配置"这件事越早做越划算。
关于团队协作，e2e 测试的维护责任一定要明确到人。最怕的就是用例挂在 CI 里，谁看见了都觉得"这不是我的代码，我不动它"，结果连续红了一个星期没人管。我后面在团队里推了一个简单机制：e2e 出现失败，当天值班的人必须在当天定位到原因，要么修复，要么明确记录为已知问题并注明修复时间。这个机制推行之后，e2e 的稳定性肉眼可见地提升了。
最后再分享一个小技巧。做 e2e 调试的时候，不要只在本地改完就提交代码，建议先把 trace 在本地自己跑一遍回放，确认你改的代码确实解决了问题、没有引入新问题，再推到 CI。这个习惯能帮你省下一大堆"看起来修好了结果 CI 又挂了"的尴尬循环。e2e 测试这个东西，写得好是非常有价值的工程资产，写得不好就是天天报红的鸡肋，关键是看你怎么规划、怎么维护。根据我自己的经验，只要处理好数据、定位、等待、环境隔离这几件事，它给你带来的稳定性回报会远超你投入的时间和精力。
