1. 从“e2e”说起：端到端测试到底在测什么
第一次看到“e2e”这个词，很多人会以为是某个新框架的缩写，或者某个工具的名字。其实它是end-to-end的缩写，中文叫“端到端”。在软件研发语境里，它指的是一种测试层级——从用户真实操作的入口开始，一路走完整个业务流程，直到最终结果落地，全程不替换任何中间环节。与之对应的还有单元测试、集成测试，它们各自负责不同粒度的验证，而 e2e 负责的是“整条链路能不能跑通”。
我最早接触 e2e 是在一个电商项目里。当时单元测试覆盖率做到 80% 以上，集成测试也全绿，结果上线当天用户下单后优惠券没抵扣。排查发现是前端传参字段名和后端接收字段名大小写不一致，单元测试里 mock 掉了接口，集成测试里又用了同一套错误约定，只有真实点一遍下单流程才能暴露。这就是 e2e 存在的意义：它不关心某个函数写得对不对，它只关心“用户能不能完成这件事”。
“e2e profile1”这个热词，我理解是社区里对 e2e 测试配置档案的一种叫法。实际项目中，e2e 往往需要多套 profile：本地开发跑一套（连本地服务、用测试账号），CI 跑一套（连预发环境、用隔离数据），回归跑一套（连类生产环境、跑全量用例）。不同 profile 对应不同的 baseURL、账号体系、数据清理策略和超时阈值。很多人 e2e 写不好，不是用例写得差，而是 profile 没分清楚，本地能过 CI 挂，CI 能过回归挂，最后变成“玄学测试”。
这篇文章适合谁看？如果你正在写 e2e 用例但总觉得不稳定，或者团队刚引入 e2e 不知道从哪下手，又或者你已经在用 Playwright、Cypress、Selenium 但只停留在“能跑就行”的阶段，那接下来的内容应该对你有用。我会从设计思路、核心细节、实操过程到问题排查，把 e2e 这套东西拆开讲清楚，尽量让你看完能直接对照自己项目改。
2. e2e 测试的整体设计与思路拆解
2.1 为什么 e2e 不能“什么都测”
刚做 e2e 的人容易犯一个错：把单元测试和集成测试没覆盖到的边角料全塞进 e2e。结果用例数量膨胀到几百条，跑一次半小时，失败率还高。e2e 的成本结构决定了它必须“少而精”。单元测试跑一次几毫秒，e2e 跑一次可能几秒到几十秒，因为要启动浏览器、加载页面、等待网络、操作 DOM。成本高意味着它应该只覆盖核心业务链路。
那什么算核心链路？我的判断标准是三条：第一，这条链路断了会导致用户无法完成主要目标（比如下单、支付、登录）；第二，这条链路涉及多个系统或服务协作（前端、网关、订单服务、支付服务）；第三，这条链路的 bug 用其他测试层级很难发现（比如跨服务字段映射、时序问题、真实网络延迟）。三条里占两条以上，才值得写 e2e。
反过来，表单校验规则、按钮禁用状态、某个接口返回码处理，这些用单元测试或组件测试更合适。e2e 里重复测这些，除了拖慢流水线没有任何收益。我见过一个项目 e2e 写了 400 条，其中 200 条在测输入框必填校验，后来全删了，回归时间从 40 分钟降到 12 分钟，缺陷逃逸率反而没变化。
2.2 测试金字塔里的 e2e 位置
经典测试金字塔是单元测试最多、集成测试次之、e2e 最少。但实际项目里经常倒过来，因为 e2e 写起来“最像用户操作”，心理上觉得最可靠。这是个陷阱。e2e 的可靠性建立在环境稳定、数据可控、选择器健壮的基础上，缺一个都会变成 flaky test（不稳定测试）。而单元测试几乎不受环境影响。
我的建议比例是：单元测试 60% 到 70%，集成测试 20% 到 30%，e2e 控制在 10% 以内。一个中等规模项目，e2e 用例数在 20 到 50 条之间比较合理。如果超过 100 条，就要审视是不是把太多东西塞进来了。当然这不是硬性规定，业务复杂度高的项目可以适当放宽，但方向是“e2e 只做最关键的验证”。
2.3 profile 分层的设计逻辑
前面提到 e2e profile1，这里展开说。profile 本质是一组环境配置的集合。我通常分三层：
- local profile：连本地启动的服务，用本地数据库或内存数据库，账号是种子数据，超时设短（比如 5 秒），失败立即重试一次。目的是开发时快速反馈。
- ci profile：连 CI 环境部署的预发服务，用独立测试库，每次跑之前重置数据，超时设中等（比如 15 秒），失败重试两次。目的是合并前验证。
- regression profile：连类生产环境，用脱敏数据或影子库，超时设长（比如 30 秒），失败重试三次，并且开启录屏和 trace。目的是发版前全量回归。
这三层不是必须完全一样，用例可以按标签筛选。比如 local 只跑@smoke标签的 10 条，ci 跑@core的 30 条，regression 跑全部 50 条。这样既保证反馈速度，又保证覆盖深度。profile 配置文件一般放在项目根目录，比如e2e/config/local.json、e2e/config/ci.json，通过环境变量E2E_PROFILE切换。
2.4 工具选型：Playwright、Cypress 还是 Selenium
这三个是主流选择，我分别用过。Selenium 最老，生态最广，但 API 偏底层，等待机制要自己封装，新手容易写出满屏sleep。Cypress 开发者体验好，自带重试和时间旅行调试，但跨域和多标签页支持弱，且只能在浏览器内跑。Playwright 是后来者，支持多浏览器、多语言、自动等待、网络拦截、trace 查看，目前是我首选。
选型时看几个点：团队技术栈（Node 项目选 Playwright/Cypress 都行，Java 项目可能 Selenium 更顺）、是否需要多浏览器（Playwright 覆盖 Chromium/Firefox/WebKit）、是否需要移动端模拟（Playwright 有设备描述符）、CI 集成难度（Playwright 官方镜像很省事）。如果项目刚起步，我直接推荐 Playwright，它的codegen能录制操作生成代码，trace viewer能回放失败现场，对排查问题帮助很大。
3. 核心细节解析与实操要点
3.1 选择器策略：为什么>const profile = process.env.E2E_PROFILE || 'local'; const configs = { local: { baseURL: 'http://localhost:3000', retries: 1, timeout: 5000 }, ci: { baseURL: 'https://staging.example.com', retries: 2, timeout: 15000 }, regression: { baseURL: 'https://preprod.example.com', retries: 3, timeout: 30000 }, }; export default defineConfig({ ...configs[profile], use: { trace: 'on-first-retry', screenshot: 'only-on-failure' }, });
第三步写第一条用例。比如登录：
import { test, expect } from '@playwright/test'; test('用户可以用正确密码登录', async ({ page }) => { await page.goto('/login'); await page.getByTestId('login-username').fill('testuser'); await page.getByTestId('login-password').fill('password123'); await page.getByTestId('login-submit').click(); await expect(page).toHaveURL('/dashboard'); await expect(page.getByTestId('welcome-message')).toContainText('testuser'); });跑E2E_PROFILE=local npx playwright test，如果本地服务起着，应该能过。不过第一次跑大概率挂，因为选择器可能不对，或者页面加载慢。这时候用npx playwright test --headed看浏览器实际操作，或者--debug一步步走。
4.2 核心链路用例设计：以电商下单为例
下单链路通常涉及：登录、搜索商品、加入购物车、结算、填地址、选支付、提交、查看订单。这一整条如果写一条 e2e，会非常长且脆弱。我一般拆成三条：加购到结算页、结算到支付成功、支付成功到订单详情。每条独立，用 API 预置前置状态。
第一条：加购到结算。预置一个上架商品，UI 搜索、加购、进购物车、点结算，断言结算页有该商品且金额正确。第二条：结算到支付。预置一个购物车和默认地址，UI 进结算、选地址、选支付方式、提交，断言跳转支付页或支付成功。第三条：支付成功到订单详情。预置一个已支付订单，UI 进订单列表、点详情，断言状态和金额。
这样拆的好处是失败定位快。如果支付挂了，前两条还是过的，能快速判断是支付环节问题。如果写成一条，失败了你不知道是加购挂了还是支付挂了。
4.3 参数化与数据驱动
同一链路不同参数可以参数化。比如登录用例，测正确密码、错误密码、空密码。用数组驱动：
const cases = [ { name: '正确密码', pwd: 'password123', expect: '/dashboard' }, { name: '错误密码', pwd: 'wrong', expect: '/login?error=1' }, { name: '空密码', pwd: '', expect: '/login?error=2' }, ]; for (const c of cases) { test(`登录-${c.name}`, async ({ page }) => { // ... }); }参数化时注意数据隔离，每个 case 用独立账号或跑完清理。如果共用账号，错误密码尝试次数多了可能触发账号锁定，导致后续 case 失败。我一般给每个 case 分配独立账号，或者用 API 重置锁定状态。
4.4 CI 集成：让 e2e 在流水线里跑起来
CI 里跑 e2e 关键是环境准备。以 GitHub Actions 为例，步骤是：checkout 代码、装 Node、装依赖、起服务（或用已部署的预发环境）、跑 e2e、上传报告。如果服务要本地起，用docker-compose up -d起依赖，等健康检查通过再跑。
Playwright 官方有 Docker 镜像mcr.microsoft.com/playwright:v1.x.x-jammy，里面浏览器和依赖都装好了，直接用省事。跑的时候加--reporter=html生成报告，失败时上传 trace 和截图作为 artifact。CI 上超时要设够，e2e 跑 10 分钟很正常，别设 5 分钟导致被 kill。
注意：CI 上并发跑 e2e 要小心数据冲突。如果多个 job 同时跑，共用数据库会互相干扰。解决办法是每个 job 用独立 schema 或独立测试库，或者串行跑。Playwright 支持
workers配置，本地可以多 worker，CI 上建议设 1 到 2，避免资源竞争。
4.5 报告与可观测性
e2e 跑完要有报告，不然失败了不知道哪挂。Playwright 自带 HTML 报告，npx playwright show-report打开，能看到每条用例耗时、失败原因、trace 链接。CI 上把报告目录上传，失败时下载查看。另外可以接 Slack 或邮件通知，但别每条都通知，只在主分支失败时通知，否则噪音太大。
可观测性还包括指标收集：用例通过率、平均耗时、flaky 率。这些数据攒一段时间能看出趋势。比如某条用例耗时从 3 秒涨到 10 秒，可能是页面变慢了；某条用例 flaky 率 20%，肯定有问题要修。我一般用简单脚本解析 JSON 报告，存到数据库或表格里，每周看一眼。
5. 常见问题与排查技巧实录
5.1 常见问题速查表
| 问题现象 | 可能原因 | 排查方法 | 解决方向 |
|---|---|---|---|
| 元素找不到 | 选择器失效、页面未加载完 | 加--headed看实际页面，检查 DOM | 换>
|
