企业官网建设流程全解析

聊到 e2e 测试，很多团队都会先点头再苦笑。点头是因为都知道端到端测试的价值，苦笑是因为真正把它跑稳的团队并不多。我在过去几年带过多个项目的质量保障工作，从 Selenium 到 Cypress 再到 Playwright 都折腾过，最近在整理内部测试资产时，发现大家反复提到一个叫 e2e profile1 的配置场景——说白了，就是一套专攻核心主流程的端到端用例分组。这篇就把我围绕 e2e 测试从设计、落地到排障的完整思路写下来，希望能给到你一个可以直接复用的参考。

1. 为什么大家都说 e2e 测试是最后一公里

单测过了、接口测试也过了，全链路一跑还是翻车，这种事我遇到过太多次。上一秒下单接口返回 200，下一秒页面上的订单列表就是刷不出来；用户注册流程里每个接口都通，但真人在浏览器里点了一遍，却卡在短信验证码的倒计时上。e2e 测试要解决的就是这类问题：把真实用户的操作路径从界面到数据库完整串起来，验证系统在真实场景下到底能不能用，而不只是某个模块能不能工作。

1.1 从“单点可靠”到“全链路可用”

单元测试保证一个函数、一个类在输入输出上是对的；接口测试保证一个服务对外契约是对的。但用户不会直接调用你的接口，他们打开浏览器，点按钮、填表单、等跳转。任何一个中间环节掉了链子，前面所有“单点可靠”都会变成用户眼里的“整个系统都坏了”。

我习惯用一个下单流程来向团队解释这件事：商品详情页能打开，购物车能加购，订单服务能创建订单，库存服务能扣减，这些单测和接口测试都能覆盖。可如果前端在提交订单时把商品 ID 拼错、Redis 里的库存状态没同步、支付回调没有刷新订单状态，任何一个拼接处出错，用户看到的都是“下单失败”。e2e 测试就是在这些拼接处撒网，从输入手机号、选择收货地址、点击提交，到最后看到“支付成功”的页面，整条链路从头跑到尾，中间任何一只小蚂蚁都能被踩出来。

所以我把 e2e 测试看作质量保障的“最后一公里”。前面所有测试都在回答“零件有没有问题”，e2e 回答的是“整台车能不能开上路”。没有这最后一公里，前面的测试做得再多，线上事故也照样会从你的指缝里溜过去。

1.2 e2e profile1 到底是个什么配置

第一次看到 e2e profile1 这个说法的人都会愣一下，我一开始也愣过。它其实不是某个测试工具的内置术语，而是团队内部约定的一种运行配置组合：把“用例集合 + 目标环境 + 运行参数”打包成一个 profile，profile1 专门用来跑那些绝对不能出问题的核心主流程。

举个例子，我们的 e2e 用例会按用途分成几组：

• profile1：核心冒烟链路，覆盖登录、下单、支付、退款这类高频关键路径，每次发版前必须全绿。
• profile2：完整回归链路，覆盖所有已经沉淀下来的历史用例，一般跑在夜间或每次合并主干后。
• profile3：边缘场景链路，覆盖异常输入、权限边界、低概率并发等压力场景，按迭代节奏不定期跑。

这样的分组有一个很实际的好处：你可以用同一套测试代码，通过启动参数去决定这次“跑哪些用例、在哪个环境跑、用多长的超时”。比如在配置文件里声明一个 profile 对象：

export const profiles = { profile1: { name: 'core-smoke', grep: '@smoke', baseURL: 'https://staging.example.com', retries: 1, timeout: 30_000, worker: 4, }, profile2: { name: 'full-regression', grep: '@regression', baseURL: 'https://staging.example.com', retries: 2, timeout: 45_000, worker: 8, }, };

为什么叫 profile1 而不是直接叫 smoke？因为 smoke 只表达了“用例类型”，但没有表达“跑在哪个环境”和“用多大并发”。一旦环境多了、用例多了，你需要的是能一键切换的完整运行姿势，这就是 profile 的存在意义。

2. e2e 测试的整体设计与场景拆解

很多新手拿到 e2e 测试的第一反应是“把业务功能全部自动化”。这个想法很危险，也是很多团队最后把 e2e 测试做成“又贵又慢又难维护”的根源。e2e 测试不是越多越好，它最贵的不是写，而是跑和维护。

2.1 先圈定边界：哪些场景值得写 e2e

我每次接手一个新的测试体系，做的第一件事不是写用例，而是做减法。哪些场景值得用 e2e 去覆盖，我会看三个硬指标：

• 用户高频使用的主路径。比如电商里的加购下单、内容平台里的登录发布、后台系统里的创建和导出。
• 跨系统、跨服务的数据流转场景。只要链路里涉及前端、后端、缓存、第三方回调，任何一个交互点都可能在联调时出问题，这种场景非常值得用 e2e 兜住。
• 一旦回归会带来严重资损或舆情风险的功能。比如支付、退款、权限变更，这些功能出错不是“体验差”的问题，而是“事故”的问题。

反过来，一些纯内部逻辑、页面静态展示、单纯字段校验的场景，我通常不建议写 e2e。字段校验交给单测和组件测试，静态展示交给视觉回归，各自有更便宜的工具去做。e2e 用例是慢工出细活，每一条都要花真金白银去跑，必须用在刀刃上。

下面这张表是我在做用例规划时常用的一个判断参考：

2.2 测试数据与前置状态设计

e2e 测试里 80% 的随机失败都出在测试数据上。我见过很多人写用例，一上来就操作数据，完全不管环境里有没有历史残留，结果前一秒用例还能跑，后一秒同一套数据就跑崩了。

设计测试数据时，我坚持三个原则：隔离、幂等、可控。

• 隔离：每个用例最好使用自己独享的数据，不要和别人共用同一个账号、同一个订单号。并行跑起来的时候，一旦互相改数据，结果就是随机的。
• 幂等：同样的用例跑两遍，应该得到同样的结果。比如创建订单最好用时间戳或 uuid 生成唯一单号，避免第二次跑时命中已有数据。
• 可控：尽量通过接口或数据库把前置状态造好，而不是在 UI 上一步步点出来。比如需要登录态，就先用接口拿到 token 再写入浏览器上下文，而不是真的走一遍登录流程。这能帮每次用例省下好几秒。

举例来说，我在登录用例里会用这样一个 helper：

async function getToken(env: string) { const endpoint = `https://${env}.example.com/api/auth/login`; const res = await fetch(endpoint, { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify({ username: 'bot_user', password: 'test_pass' }), }); return (await res.json()).token; }

拿到 token 之后塞给 Playwright 或 Cypress，直接跳过繁琐的登录步骤。这样不仅快了，还让用例永远不需要依赖验证码、短信这类外部不稳定因素。

2.3 断言策略：别只盯着状态码

接口测试的断言习惯是“返回 200 就过”。e2e 测试如果也这么干，基本等于白写。用户看到的是页面，不是网络请求，所以你的断言必须落在用户可感知的结果上。

一个合格的下单 e2e 用例，至少要覆盖这几类断言：

• 页面跳转：是否从结算页跳到了订单详情页。
• 关键元素可见：订单号、金额、状态是否为用户实际期望的内容。
• 数据持久化：刷新页面之后，订单是否仍然存在。
• 网络副作用：是否有关键请求失败，比如支付回调、商品下架接口。

我常用的一段断言长这样：

await expect(page.locator('.order-status')).toHaveText('支付成功'); await expect(page.locator('.order-amount')).toHaveText('¥199.00'); await page.reload(); await expect(page.locator('.order-list-item')).toContainText('SN-20250607-001');

注意第二行的“刷新页面后数据还在”，这个断言非常关键。很多页面第一次渲染是正常的，一刷新数据就丢了，这种问题只有 e2e 能帮你抓住。所以不要省掉刷新页面这种“看起来多此一举”的步骤，它不是多此一举，它是检验前后端数据一致性的照妖镜。

3. 从零搭一套 e2e 测试框架：核心环节实操

这一节我会用实际踩过坑的经验，带你走一遍从选型到落地的完整流程。我不会只给你看代码片段，还会把每个选择背后的理由说清楚，这样你可以根据自己的项目情况做调整。

3.1 选型：Playwright / Cypress / Selenium

市面上的 e2e 工具很多，但核心就这几类。先放一张我常用的选型对比表：

如果是从零开始的新项目，我个人最推荐 Playwright。原因很简单：自动等待机制做得好，不需要整天去写sleep(3000)；内置浏览器上下文，可以很方便模拟多个登录用户；还有 Trace Viewer，一旦用例失败，回放整个操作过程的排查效率极高。

Cypress 的优势在于 API 友好，写起来像自然语言，但它处理多标签页和 iframe 时比较别扭。Selenium 的优势是生态老，什么语言都能接，但恰恰因为太灵活，写起来最容易失控。如果你的团队已经重度投入某个工具，没有必要强行迁移，工具只是手段，稳定的用例和维护效率才是目的。

3.2 目录结构与测试用例组织

一套清晰的目录结构，决定了你半年之后还能不能愉快地维护这套测试。我的习惯是功能模块 + 用例分级两层组织：

e2e/ ├── config/ │ ├── profiles.ts │ └── environments.ts ├── fixtures/ │ └── auth.ts ├── tests/ │ ├── smoke/ │ │ ├── login.spec.ts │ │ ├── order.spec.ts │ │ └── payment.spec.ts │ └── regression/ │ ├── refund.spec.ts │ └── permissions.spec.ts └── utils/ ├── api.ts └── selectors.ts

smoke目录下放的所有用例，都打上@smoke标签。regression目录下的用例打上@regression标签。这样运行时只要传入对应的 grep 参数，就能从海量用例里精准筛出 profile1 需要的部分。

如果你还在把所有用例堆在一个文件夹里，我建议现在就动手拆分。不是为了让目录好看，而是在 rider 上能轻松配置“这个 profile 只跑这些用例”。后面用例多了，你会发现“分类”比“单条用例写得漂亮”重要得多。

3.3 用 profile1 驱动多环境配置

e2e 测试最容易被忽略的问题，就是环境配置混乱。今天在本地跑，明天在 staging 跑，后天又要到预发环境验证一遍，如果 baseURL、账号、路由都写死在测试用例里，线下测试就是一个灾难。

我们现在的做法是把环境信息独立成文件，然后通过E2E_PROFILE这个环境变量选择加载哪一套配置：

// config/environments.ts export const environments = { local: { baseURL: 'http://localhost:3000', apiBase: 'http://localhost:8080', user: 'test_user', password: 'test_pass', }, staging: { baseURL: 'https://staging.example.com', apiBase: 'https://api.staging.example.com', user: 'staging_bot', password: 'staging_secret', }, production: { baseURL: 'https://www.example.com', apiBase: 'https://api.example.com', user: 'prod_readonly', password: 'prod_secret', }, };

然后在运行命令里直接指定 profile：

E2E_PROFILE=profile1 npx playwright test --grep "@smoke" --project=chromium

profile1 对应的配置文件里，baseURL指向 staging，grep限定为@smoke，retries设为 1。这样“我想知道核心主流程在 staging 是否可用”这一句话，就变成了一条可以反复执行的命令，而不是一段含糊的口头沟通。

3.4 报告、重试与稳定性

e2e 用例如果连续跑几次都挂，很影响团队信心。因此稳定性的设计要写进框架里，而不是靠“别让它挂”去祈祷。

我会在 Playwright 配置里设置三样东西：重试策略、超时时间、成功后的 Trace 保留策略。

export default defineConfig({ testDir: './tests', timeout: 30_000, retries: process.env.CI ? 2 : 0, reporter: [ ['list'], ['html', { open: 'never' }], ['allure-playwright'], ], use: { trace: 'retain-on-failure', screenshot: 'only-on-failure', video: 'retain-on-failure', }, });

这里重点解释三个参数：

• retries设成process.env.CI ? 2 : 0，意思是在 CI 上允许失败重跑 2 次，本地调试则为 0。重试能扛住偶发的网络抖动，但不要设得太多，否则问题会被掩盖。
• timeout最好不要低于 30 秒。e2e 用例涉及真实的页面渲染、请求、跳转，10 秒在本地可能够，但在 CI 那种低配机器上很容易误报。
• trace和video保留失败现场，是排查问题的救命稻草。没有 Trace，你只能看到一行堆栈；有了 Trace，你能看到鼠标停在哪、页面报了什么错、请求和响应是什么。

报告方面，我的选择是HTML reporter + Allure。HTML 报告适合日常快速查看，Allure 适合在 CI 上汇总历史趋势。用哪个不必太纠结，关键是稳定生成、随时可查，别让报告本身变成没人看的东西。

4. 常见问题与排查技巧实录

e2e 测试落地之后，你会遇到一堆奇奇怪怪的问题。我把这几年遇到的高频问题整理成一份速查表，每个都附上我的排查思路。

4.1 用例反复跑不通：先看选择器，再看等待

最典型的一个现象是：同一个用例，本地跑稳定，CI 上三天两头挂。一上去看报告，报的是“元素找不到”或者“点击被拦截”。

我先说选择器。千万不要用一串又长又脆的 CSS 路径，比如：

#root > div.app-body > div.main-content > div.panel > div.panel-body > div.btn-group > button:nth-child(3)

这种选择器只要页面布局动一下，或者前面多了一个 div，用例就废了。我现在的标准做法是让前端组件加上稳定的测试标记：

<button>await page.getByTestId('submit-order').click();

接着是等待。很多人习惯在点击之后立即断言页面元素，这是误报高发区。Playwright 虽然会自动等待可操作状态，但如果你用了第三方库，比如 Selenium，就必须手动等待。等待不要用固定 sleep，应该用显式等待，比如等元素可见、可点击、或者文本出现：

await expect(page.getByText('支付成功')).toBeVisible({ timeout: 15000 });

如果你发现用例总在某个步骤随机失败，先在本地关掉重试跑五遍，然后用 Trace 一步步回放，基本上问题都是“选择器定位到了隐藏元素”或者“点击过快事件没绑上”。

4.2 随机失败：从测试隔离到资源释放

随机失败是 e2e 测试最容易让人崩溃的问题。因为不稳定，所以没人信，最后逐渐失去维护，整个测试体系就变成了一座墓碑。

随机失败最常见的来源有三个：

• 测试数据互相污染。账号 A 的操作影响到了账号 B 的页面。
• 浏览器上下文没有隔离。多个用例共用一个登录态，前面的用例改了 localStorage，后面的用例拿到的就是被改过的状态。
• 没有等异步操作结束。比如点击提交后，页面还在 loading，你就去断言下一个元素，导致偶发失败。

我处理随机失败的顺序是：先在本地用--repeat-each=10复现，再打开 Trace 对比成功和失败的操作路径。不要一上来就加sleep，那不是修复，那只是掩盖。

真正的修复通常很小：给每个用例创建独立的 context，用完关闭；所有数据用唯一标识生成；在接口层等请求完成后再做 UI 断言。比如：

test.describe('下单流程', () => { let context: BrowserContext; test.beforeEach(async ({ browser }) => { context = await browser.newContext(); const token = await getToken('staging'); await context.addInitScript( ([t]) => { localStorage.setItem('token', t); }, [token] ); }); test.afterEach(async () => { await context.close(); }); });

这样每个用例都是干净的浏览器环境，和别的用例之间没有任何能互相污染的状态。资源释放做不到位，后面你就是在跟空气博弈。

4.3 断言误报：如何判断 e2e 结果是“真绿”

还有一个常见坑，是“用例是绿的，但功能其实坏了”。这种误报比失败更可怕，因为它给了团队一种虚假的安全感。

我遇到过一种经典情况：断言元素.success-tip可见，但实际上页面因为 JS 报错一直没有渲染成功，只是某个旧缓存节点还在页面上。于是用例通过了，用户的订单却没创建成功。

要识别这种“假绿”，我加了三道检查：

• 页面是否有 console error。在断言结束时主动检查浏览器控制台有没有error级别的日志。
• 关键网络请求是否全部完成。特别是下单、支付这类接口，不能只看 UI，要看请求响应码和返回值。
• 数据库或接口侧是否有对应记录。有条件的话，用例最后调用一次查询接口，确认数据真的落库。

一个简化的控制台检查思路：

test('下单后控制台没有异常', async ({ page }) => { const errors: string[] = []; page.on('console', (msg) => { if (msg.type() === 'error') errors.push(msg.text()); }); page.on('pageerror', (err) => errors.push(err.message)); await page.goto('/checkout'); await page.getByTestId('submit-order').click(); await expect(page.getByText('支付成功')).toBeVisible(); expect(errors).toEqual([]); });

这道检查我在多个项目里都放过，效果很直接：误报率大幅降低，“真绿还是假绿”这个问题基本不用争论了。

5. 一些我踩过的坑和长期建议

看到这里，你基本已经知道 e2e 测试该怎么从零搭起来了。但工具和用例只是开始，真正让 e2e 测试长期发挥价值，靠的是维护意识和团队共识。最后分享几个我这几年最深的体会。

5.1 把 e2e 用例数量控制在“够用”而不是“全”

很多团队一开始热情高涨，一个月写了 200 条 e2e 用例。等到了第三个月，每条用例跑一遍要 40 分钟，CI 排队排到怀疑人生，于是开始删用例、禁用用例，最后整个体系放弃。

我的建议是：e2e 用例数量宁少勿多。先把 profile1 跑稳，再逐步扩展。每新增一条用例之前问自己三个问题：这条用例有没有可能抓到其他测试抓不到的问题？它跑一次要多少时间？它需要维护多久？如果两个答案都是“否”或“很长”，我宁愿不写。

5.2 留出专门的时间维护测试资产

e2e 测试不是“写完就结束”的工程，页面改版、文案变更、交互调整，都会让用例失效。如果不维护，三个月后它就变成一段无人敢碰的代码。

我现在每两周会安排半天时间专门维护 e2e 用例。不是等用例挂了才去修，而是主动浏览一遍最近的页面改动，提前更新选择器和断言。这个习惯帮我避免过很多次“发版当天才发现测试全红”的尴尬。

5.3 最值得投入的调试基建

如果只能给刚做 e2e 的团队一个建议，我会说：把调试基建做好。截图、Trace、视频、报告归档，这些东西看起来不直接产生用例价值，但一旦出现问题，它们能帮你把排查时间从两小时缩短到五分钟。

我个人在实际操作中体会最深的一点是，e2e 测试的最终目的从来不是“让测试通过”，而是“让团队愿意相信测试结果”。只要大家都愿意点开报告、愿意看 Trace、愿意在合并主干之前等那几分钟，这套 e2e 体系就已经成功了。剩下的，都是在此基础上慢慢打磨的细节。