企业官网建设流程全解析

做e2e测试这些年，我最常被问到的一句话是：“e2e到底该写多少用例才够？” 问这话的人，多半已经在单元测试和接口测试上尝到过甜头，也知道端到端测试（e2e，End-to-End）能模拟真实用户操作、把核心业务链路从头到尾跑通，但真到自己上手搭框架、写脚本时，却发现要么用例跑得慢、要么环境一换就全红、要么定位问题定位到怀疑人生。这篇文章不打算讲那种“三天搞定e2e”的速成教程，而是想把我在多个项目里落地 e2e 测试的真实经验拆开：架构怎么设计、工具怎么选、稳定性和 ROI（投入产出比）怎么平衡，以及“e2e profile1”这种听起来有点黑话、实际就是一套面向特定场景的端到端配置方案，到底该怎么理解和配置。适合正在搭测试体系、或者已经在写 e2e 但被坑得浑浑噩噩的团队参考。

1. 先别急着写用例：e2e 到底解决什么问题

1.1 我见过最典型的 e2e 失败案例

两年前接手过一个 B2B SaaS 项目，团队特别认真，测试金字塔上三层一应俱全：单元测试覆盖率 80%，接口测试也写了三百多条。结果每次发版前最慌的还是前端联调环节。原因很简单，前端表单校验和后端字段约束偶尔对不上，A 模块改了下拉框的取值逻辑，B 模块的联动展示跟着出错，这些跨模块、跨接口的组合问题，单测和接口测试根本发现不了。

后来团队决定补 e2e，当时大家的第一反应是“那就用 Selenium 写 UI 自动化呗”，结果第一条用例刚跑通就踩了巨坑：测试环境一换，Chrome 驱动版本不匹配，整个 CI 直接挂掉。更痛苦的是用例本身的稳定性，某个弹窗偶尔延迟 300ms 出现，脚本里写死了sleep(2)，本地跑能过，CI 上跑就随机飘红。三个月之后，e2e 用例从 80 条缩水到 20 条，最后连那 20 条也没人敢信，成了纯粹的形式主义。

这段经历其实挺典型。e2e 测试最大的价值不是“写了多少条”，而是它能把用户在关键路径上的真实体验变成可回归的资产。登录、创建资源、提交审批、处理异常状态——这些跨页面、跨系统、跨服务的数据流转，只有 e2e 能端到端地给你兜底。但它也是最贵、最脆的一层测试，如果一开始没人想清楚“用它防什么”，那后续的每一个技术决策都会跑偏。

1.2 e2e、集成测试、单元测试的边界到底在哪

很多新手会把集成测试和 e2e 混为一谈，实际上它们验证的目标完全不同。

• 单元测试：验证某个函数、某个组件在给定输入下输出是否正确，不关心调用方。
• 集成测试：验证两个模块之间的接口契约和交互逻辑，比如前端调后端 API、服务 A 调服务 B，重点是“接口对不对”。
• e2e 测试：验证真实用户从入口到出口的完整链路，包括 UI 操作、路由跳转、请求发送、数据持久化、状态恢复。它覆盖的是“用户感知”层面的系统行为。

我用一句话帮助团队区分：集成测试问的是“零件之间能不能咬合”，e2e 问的是“整台机器能不能跑完一条流水线”。所以 e2e 的用例设计必须从用户场景出发，而不是从代码结构出发。一个常见误区是：既然叫端到端，那就所有页面所有按钮都给我覆盖。结果用例数量爆炸式增长，每条用例串得又长又重，维护成本直线上升，一有需求变更就是成片重写。

正确的做法是：只对关键业务流，以及“跨模块状态传递”这种最容易出问题的链路做 e2e。以那个 SaaS 项目为例，订单从创建到审核再到财务确认的整条路径，是必须要有 e2e 的；而那些单纯的展示页、纯查询列表，交给组件测试或接口测试就足够了。

1.3 什么项目真的需要 e2e，什么项目不需要

写 e2e 之前，先冷静判断一下项目阶段。如果你的产品还在天天改 UI、跳转逻辑一周变三次，那这时候上 e2e 就像在流沙上盖房子——用例永远在维护，价值全被成本吃掉。我一般建议满足下面几个条件的项目才把 e2e 作为正式质量门槛：

• 业务链路跨越多个页面或系统，且链路之间的状态有强依赖；
• 核心用户操作路径相对稳定，不会每周大改；
• 已经跑通了接口测试，e2e 是拿来兜底组合错误，而不是替代更底层的测试；
• 团队有明确的回归窗口，比如发版前、大版本合并后。

如果是内部管理后台或者一次性活动页面，真的没必要堆 e2e。我见过有人给一个 3 天就下线的营销活动页写了 15 条 e2e 用例，结果活动上线第一天 UI 改了，用例全部作废，白白浪费了两个人日。这种“为了 e2e 而 e2e”才是最要命的。e2e 不是越多越有面子，而是要配合项目所处的阶段和变更频率来动态调整。

2. 框架选型与项目结构：把 e2e 当工程做，而不是当脚本写

2.1 Playwright、Cypress、Selenium 三选一的真实体验

工具选型这一关会直接决定你之后半年的幸福指数。我只谈真实体感，不摆官网名词。Selenium 是老牌通用方案，支持各种浏览器、语言绑定多、生态成熟，但它的历史包袱也重：以前需要自己管理 driver 版本、需要处理各种隐式/显式等待、脚本写多了维护成本非常高。如果团队里已经有成熟的 Selenium 基础设施，继续用没问题；从零起步的话我一般不建议选它。

Cypress 的体验比 Selenium 好太多，安装简单、自带等待机制、调试界面漂亮，尤其适合纯前端团队快速上手。但它的架构决定了它的边界：默认只跑在浏览器内，多标签页和跨域场景处理起来比较别扭，如果要测真实的多系统跳转，Cypress 不一定顺手。Playwright 是目前我最常用的选择。它在设计上更现代：通过 CDP 协议与浏览器通信，能真正做到跨域、多标签页、移动端模拟，还内置了 web-first assertion（面向 Web 断言），绝大多数情况下不用手工写 sleep。而且它原生支持并行执行和分片（shard），这对 CI 提速极其重要。

下面是我在真实项目里对三个工具的直观对比，注意这是“体感”，不是 Benchmark：

如果你是团队第一个吃螃蟹的人，我建议直接 Playwright，理由不是它完美，而是它的“现代性”能帮你少踩很多历史坑。它在 TypeScript、Python、Java、.NET 里都有官方支持，用例即代码，语义清晰，读起来就像在描述用户操作步骤。

2.2 目录结构与配置文件设计：理解“e2e profile1”到底是什么

很多团队建 e2e 工程时只建一个 test 目录，所有用例随便往里丢，跑了一段时间后再想维护就无从下手。我常用的工程结构是分三层：测试场景目录、基础封装（page objects 或者操作指令）、配置文件。讲到配置文件，就正好解释一下“e2e profile1”这个看起来有点黑话的词。

所谓 profile，在我理解里就是一套具备明确业务含义和运行边界的 e2e 配置方案。一个项目往往有多个 profile，各自对应不同的测试目标。比如profile1可以是“核心购买流程全链路验证”，profile2是“后台管理与权限校验验证”，profile3是“异常场景与边界值验证”。每一个 profile 都包含自己的用例范围、环境基础 URL、登录凭证账号、测试数据准备方式、执行时的浏览器视口和全局超时参数。这样做的直接好处是：跑冒烟测试时，直接执行profile1就好，不用在几千条用例里挑；跑全量回归时再叠加其他 profile。

下面是一个精简版的playwright.config.ts例子，我会在注释里写明每个字段的意义：

import { defineConfig } from '@playwright/test'; export default defineConfig({ // 选中 profiles 目录下的 profile1 相关配置 testDir: './tests/checkout-flow', // 全局超时：单条用例最长 60 秒 timeout: 60_000, // 失败后自动重试 1 次，应对偶发 UI 异步问题 retries: 1, // 并行执行的 worker 数量，CI 上可根据 CPU 调整 workers: process.env.CI ? 4 : 1, use: { baseURL: process.env.APP_BASE_URL || 'https://staging.example.com', // 模拟真实用户的浏览器视口，有的 profile 会设为移动端 viewport: { width: 1440, height: 900 }, // 用户代理，避免被站点基础反爬策略干扰 userAgent: 'e2e-test-agent', locale: 'zh-CN', screenshot: 'only-on-failure', video: 'retain-on-failure', trace: 'retain-on-failure', }, // 每个 profile 里运行前要执行的全局 beforeEach globalSetup: './profiles/profile1.global-setup.ts', });

再给一个更贴近日常使用的 profile 文件示例，或者说是“配置片段”，你可以把它理解成一个可以被不同启动命令复用的参数集合：

// profiles/profile1.ts import { defineConfig } from '@playwright/test'; export const profile1 = defineConfig({ // 只跑与 checkout 相关的测试用例 testDir: './tests/checkout-flow', use: { baseURL: 'https://staging.example.com', // 相当重要：这个 profile 专门用已支付用户身份 storageState: './secrets/profile1-storage-state.json', screenshot: 'only-on-failure', }, reporter: [['list'], ['html', { outputFile: 'reports/profile1-report.html' }]], });

看到这里你应该明白了：e2e profile1不是某个标准里的强制名词，而是我用来表达“这组端到端测试用例及其运行参数、环境状态、数据设置的总称”。在实际团队协作中，你可以把 profile 理解成“测试套餐”，不同套餐解决不同场景的需求，复用同一套底层框架。

2.3 第一版用例怎么写：少而精，先把主链路跑通

第一版 e2e 用例最忌讳“一上来就全页面覆盖”。我的做法是先画出产品最核心的 3 到 5 条用户路径，每条路径用一句话描述清楚起点、操作序列和预期结果，然后再转成用例。以电商后台为例，核心路径可以拆成：

1. 登录成功后创建商品草稿；
2. 将商品提交审核；
3. 审核通过后上架；
4. 前台完成购买下单；
5. 后台看到订单状态流转。

这 5 条路径串起来就是一条经典型的主链路，每一条都涉及多个页面和多种状态。第一版用例应该只覆盖这 5 条。如果你一上来就写了 80 条用例，那么你大概率还没有理解这些链路之间的关系，后面的每一个需求变更都会让你感受到什么叫“处处是坑”。

3. 稳定性的战争：e2e 为什么会飘红，以及怎么治

3.1 最常见的三类不稳定因素

e2e 跑红原因千奇百怪，但深挖一下其实就那么几类，而且大多不是代码 bug，而是测试设计问题。

第一类是时序竞态。页面元素还没渲染完，脚本就去点击；前端还在发请求，后端响应还没回来，脚本就开始断言。早期我用 Selenium 时全靠固定 sleep，后来用 Playwright/Cypress 后自动等待解决了大部分问题，但还是会在自定义组件、Canvas、图表场景里遇到“看似等待了其实没有”的尴尬。

第二类是环境漂移。测试环境被其他团队占了、某个依赖服务挂了、数据库里多了一条脏数据，都会导致用例失败。这类问题用技术手段很难根治，只能通过环境治理和测试数据隔离来缓解。具体操作上，我会把“测试环境的部署状态”作为 e2e 的前置依赖：每次跑全量回归前，先由 DevOps 流水线把测试服务重置到基准版本，再触发 e2e，而不是让 e2e 在一个状态不可控的随机环境上裸奔。

第三类是数据污染。这是最隐蔽的敌人。一条用例创建了用户“张三”，另一条用例又用“张三”登录，如果前一条用例没清理干净，第二条就开始偶发失败。解决思路是：每条用例必须使用独立的测试数据，绝不能共享用户名、手机号、邮箱这类唯一键。

3.2 一次完整的排错过程：从“偶尔红”到“找到根因”的完整链路

讲一个我印象特别深的排错经历。某个周四的 CI 日志里，跑 80 条 e2e 用例，失败了 6 条，失败集中在“创建订单”相关的 4 条上。第一次看到时我以为是环境抖动，点了重跑，结果过了 3 次有 1 次依然失败，失败原因都是同一个：在点击“提交订单”按钮前，页面一直处于 loading 状态，脚本等超时了。

当时我用的是 Playwright 的默认自动等待，按理说它应该一直等到按钮可点击为止。但日志里显示，点击动作本身执行成功，只是随后等到的不是订单详情页，而是停留在原页面。于是我把 trace 打开，复跑了那一条用例。

Trace 里可以看到一个细节：页面在 loading 结束后，出现了一个短暂的弹窗遮罩（某个活动引导遮罩层），这个遮罩层正好盖住了“提交订单”按钮。Playwright 的无障碍可访问性检查认为按钮可以被点击，但真实用户在这一刻其实会先被弹窗挡住。脚本点击按钮时，事件被弹窗接收，页面自然就没有触发提交逻辑。

这就是典型的“可见性不等于可操作性”的坑。最终的修复方案很务实：在点击按钮之前，如果检测到遮罩层存在，就先关闭它；同时把断言从“等待页面跳转”改成“等待订单元数据出现在接口响应中”，这样即使 UI 层有遮挡，测试的核心验证对象——订单创建成功——依然能准确判断。后来团队复盘时还总结了一条规则：e2e 脚本里少写“按钮点击后页面应该长什么样”这类 UI 强断言，多用“业务状态是否发生变化”来验证结果。这个思路放到今天依然是 e2e 稳定性的核心心法。

3.3 重试机制、等待策略和测试隔离的正确姿势

关于等待策略，我现在的原则是：能用自动等待就不要用 sleep，非要 sleep 一定要写清楚原因。Playwright 的await expect(page.locator(...)).toHaveText(...)这类 web-first 断言已经解决了 90% 的等待需求。剩下那 10% 的场景，比如等待某个请求完成后再做接口断言，可以用Promise.all同时发起点击和监听 response，这样效率最高，也最稳：

await Promise.all([ page.waitForResponse(resp => resp.url().includes('/api/orders') && resp.status() === 200), page.click('button:has-text("提交订单")'), ]);

重试机制要分两层来看。单纯针对偶发失败的自动重试，能提升通过率，但会掩盖真实 bug。我的习惯是全局设置retries: 1，但如果同一用例连续失败两次，那一定不是手抖，需要人工介入分析。重试不是银弹，它更像是“筛掉 UI 异步抖动”的过滤器，真正的环境问题必须靠工程治理来处理。

测试隔离是我最在意的部分。在我们的 e2e 工程里，每一条用例的开头都会先通过 API 创建独立数据：

• 用户注册走测试 API，而不是 UI 注册流程，避免增加用例耗时；
• 数据统一加上用例前缀，比如e2e-订单创建-张三-20240101，方便出问题后定位是哪个用例留下的；
• 用例跑完后的清理动作放在afterEach里，写入测试数据库删除脚本，或者直接在环境层面做定时重置。

一句话总结：e2e 用例的质量高不高，看它的隔离性就知道。一个把测试数据耦合在一起的 suite，迟早会变成一个谁都不敢碰的定时炸弹。

4. 用例分级与执行编排：让 e2e 的成本可控

4.1 用例分级：冒烟、主链路回归、全量验证

e2e 不可能永远是一条一条跑全量，尤其到了项目后期，UI 和接口双向变化，全量回归一次可能要跑一两个小时。我的做法是把用例分成三级：

• P0 冒烟级：覆盖登录、核心创建流程、核心流转状态。每次发版前必跑，控制在 10 条以内，15 分钟内必须完成。
• P1 回归级：覆盖所有跨模块主链路，控制在 50 条左右，每天持续集成跑一次。
• P2 全量级：覆盖非核心页面与边界场景，比如设置页、权限组合、大数据量列表展示等，每周跑一次即可。

分级的判断标准不是“这个页面重要不重要”，而是“这个链路万一坏了，用户能不能立刻感知”。用户感知越强，越应该放在 P0。我见过团队把一个小按钮的 hover 效果都写成 P0 用例，这就是本末倒置。

4.2 并行执行、分片与 CI 集成：profile 的实际用法

当用例数量增长到一定程度，串行执行已经是不可接受的。Playwright 的多 worker 并行和 shard 分片是这个阶段最常用的加速工具。

shard 分片的核心思想是：把一批测试用例按用例文件切片，每个 CI 任务只运行其中的一份，然后把多份结果合并。写 CI 配置时，可以借助官方 Docker 镜像来保证运行环境一致，例如 GitLab CI 里这样配置：

e2e-checkout: stage: test image: mcr.microsoft.com/playwright:v1.45.0 script: - npm ci - npx playwright test --shard=1/4 e2e-backoffice: stage: test image: mcr.microsoft.com/playwright:v1.45.0 script: - npx playwright test --shard=2/4

上面这种“按物理分片”的切法，解决的是“量大跑得慢”的问题。而“按 profile 切”解决的是“不同业务场景需要不同配置”的问题。你可以把它们组合起来：每一个 profile 内再进行物理分片，这样既保证场景覆盖清晰，又能让每个 CI 任务控制在 10 分钟以内。这里再强调一下，profile 和 shard 不是一回事，profile 是逻辑维度的场景集合，shard 是物理维度的任务拆分，两者结合使用才是完整的执行编排方案。

4.3 ROI 视角：多少条 e2e 用例是理性的

最后聊一个可能不太合群的观点：e2e 用例的数量，应该被严格控制。很多团队写着写着就上瘾了，一个页面写了 50 条“所见即所得”的用例，无非都是“点击按钮--断言文案”，这就是把 e2e 当成了重复劳动。合理规模的判断，要看你的业务变更频率。以我自己带过的项目为例，一个每周发版一次的 SaaS 系统，e2e 用例总数长期控制在 150 条左右：

• P0 冒烟 10 条；
• P1 回归 60 条；
• P2 全量 80 条；
• 每次发版前必跑的只有 P0 那 10 条，整个回归周期能控制在 20 分钟内。

这背后有个简单逻辑：每新增一条 e2e 用例，它不是只跑一次，而是每次发版都要跑、每次需求变更都可能要改。所以新增用例前我会问自己两个问题。第一，这条用例发现的 bug，是否无法被下层测试提前捕获？第二，这条用例覆盖的业务状态变化，是否真的会用户可感知？两个问题都回答“是”，才值得写成 e2e。如果答案是否定的，那它更适合做成接口测试，甚至不需要自动化。

当然，用例数量也是个动态值。当你在一个稳定器上持续维护半年，你会发现 150 条恰好是团队维护成本的甜蜜点。超过这个量，每天光是修不稳定用例就得半天；少于这个量，核心链路又覆盖不够。真正理性的 e2e 规模，是通过数据摸出来的，不是拍脑袋拍出来的。

5. 让 e2e 成为团队的日常工具，而不是发版前的负担

技术层面聊得差不多了，再补充几点管理层面的经验。e2e 最大的敌人不是技术复杂度，而是“团队不信它”。如果每次跑红都没人解释清楚，大家就会默认 e2e 是垃圾、不可信，然后绕过它。要避免这种情况，我觉得有三件事很重要。

第一，失败分类必须明确。我给团队立了一条规矩：e2e 失败分为“环境失败”和“真实失败”。环境失败不怪代码，但要记录到一个共享表格里，并在群里通知环境负责人；真实失败必须当天拉起对应开发一起定位，不允许直接删用例了事。团队一旦形成“e2e 红了一定有价值”的信任共识，用例稳定率才会持续提升。

第二，报告必须人人可读。我在实践中特别注重把报告沉淀成一个公开链接，包含失败截图、视频回放、trace 链接和错误调用栈。开发在收到消息提醒后，不用打开 IDE 就能初步判断是不是自己改动的模块。这样 e2e 不只是一个测试工具的产出，而是一个协作工具。

第三，用例评审和维护要有负责人。我通常会在团队里指定一个“e2e owner”，负责用例新增/删除评审、用例稳定性监控、环境问题跟进。没有 owner，e2e 工程就像没铺轨的电车，迟早脱轨。

我个人实际带项目的体会是，e2e 的最大价值其实体现在大版本重构上。重构界面、换框架、调整底层服务，这些都是接口测试很难感知的高风险变动。但只要你的核心 profile 用例还在绿，团队重构之后的信心就还在。这也是为什么我在文章里反复强调“要像工程一样对待 e2e”的原因。

最后再分享一个实用技巧：在 nightly 全量回归跑完后，把失败用例的截图和 trace 按功能模块自动归档到类似reports/失败归档/2024-01-01/这样的目录下。一周下来再看这些归档，你大概率会发现某个模块的失败概率异常偏高——这往往意味着那个模块最近存在真正的架构隐患，而 e2e 只是恰好帮你把它放大出来了。