端到端测试是什么
端到端测试从用户视角出发，贯通界面、接口、数据库与外部依赖，验证一条完整业务链路是否可用。它是最接近真实使用的自动化测试：信心最高，但执行慢、失败定位贵、受环境影响大，因此只用于登录、下单、支付这类关键路径。与组件测试只覆盖单个界面模块、接口测试只覆盖服务契约不同，端到端测试验证的是各层拼装后的整体行为——任何一处错配都会在这里暴露。
基本信息
| 典型工具 | Playwright、Cypress、Selenium、Appium |
|---|---|
| 覆盖范围 | 登录、下单、支付等核心链路与跨系统集成点 |
| 运行时机 | 合并前、发布前以及夜间巡检 |
| 维护成本 | 高：选择器、数据、环境都会影响稳定性 |
| 常见形态 | Web UI、移动 App、桌面客户端、跨服务业务链路 |
典型使用场景
- 关键业务冒烟：发布前用小集合快速验证主流程未被破坏
- 跨系统集成验证：多服务协作链路端到端穿透
- 重大重构回归：框架升级、网关切换后按风险挑选核心链路执行
- 生产巡检：只读式走查首页与登录可用性，注意与业务数据隔离
- 验收测试配套：把业务方确认过的验收场景固化为自动化用例
- 跨浏览器与多端覆盖：按用户分布对核心链路开 Chromium/WebKit/Firefox 组合
- 故障复盘闭环：线上问题修复后补一条同路径的端到端用例
Playwright 示例
Playwright 示例
# 覆盖登录到进入工作台的核心链路
test('user can sign in', async ({ page }) => {
await page.goto('/login'); # 打开登录页
await page.getByLabel('Email').fill(USER); # 填写账号
await page.getByRole('button', { name: 'Sign in' }).click();
await expect(page.getByText('Welcome')).toBeVisible(); # 断言工作台可见
});
# 用可访问性角色定位元素，避免脆弱的 CSS 选择器与相邻层级对比
| 维度 | 端到端测试 | API 集成测试 | 组件测试 |
|---|---|---|---|
| 验证对象 | 整条业务链路 | 服务接口契约 | 单个界面模块 |
| 执行速度 | 十秒到分钟级 | 秒级 | 毫秒到秒级 |
| 失败信心 | 最高，最接近用户 | 中高 | 中 |
| 定位成本 | 高，横跨多层 | 中 | 低 |
| 数量策略 | 只留关键路径 | 按契约覆盖 | 按组件行为覆盖 |
等待策略决定稳定性：优先使用框架内置自动等待与条件轮询（如 expect 的轮询断言），不要用固定 sleep；相关坑点见 no-hard-sleep 条目。
测试数据要按用例隔离：独立账号、独立租户或自动清理，避免并发执行时互相污染；失败现场保留截图、trace 与录屏，先归类环境/数据/等待问题再改产品代码。
规模化技巧：用例按业务域拆分并并行分片（如 Playwright shard），把整组时长压到可接受区间；提高并行度的同时要复核数据隔离方案是否仍然成立。
用例命名与断言要业务化：失败信息包含业务动作与预期结果，值班同学才能一眼判断影响面；端到端用例数量少，可读性比技巧更重要。
工具差异：Cypress 在浏览器内运行、调试体验好；Playwright 支持多浏览器并行与跨语言绑定；Selenium 生态最广但需自行封装等待与定位。按技术栈与并行需求选型。
端到端套件要像产品一样被维护：指定固定责任人，每月审视失败率、重复覆盖与执行时长，删除长期无价值的用例，让这组高成本资产持续保持可信，否则团队会率先放弃它。