经常有朋友问我项目上线前手工把核心流程点一遍真的够吗我一般会反问一句你的“核心流程”覆盖了登录、下单、支付、回调这几个环节之间的衔接吗多数人卡住的不是单个功能而是功能与功能之间的链路。这也是我为什么一直强调每个项目都应该有一套e2e端到端测试兜底。今天这篇我不打算给你贴一堆官方文档而是用我实际落地时的思路从设计到编码再到排错完整拆一遍“e2e profile1”这套配置到底该怎么理解、怎么用、怎么跑进流水线。先说结论e2e 测试不是“点了按钮没报错”那么肤浅的东西它的核心价值在于把整个业务链路当成一个黑盒用自动化模拟真实用户行为验证系统内外所有依赖是否按预期协作。而 profile1 这种配置说白了就是同一套测试代码在不同环境、不同测试账号、不同数据集合之间切换的钥匙。你理解了这个再去看任何 e2e 框架的配置文件就不会觉得那是一堆魔法参数了。这套经验适合谁刚被领导要求“补一下自动化测试”的后端、前端同学或者已经在写用例但总被稳定性问题折磨的测试开发工程师都可以读一读。我尽量把每一步都讲透包括那些文档里不会写的坑。1. 内容整体设计与思路拆解1.1 e2e 测试到底解决什么问题在软件开发里测试金字塔通常分三层单元测试、集成测试、端到端测试。单元测试锁死的是“这一个函数在给定输入下的输出是否正确”集成测试关注“两个模块拼在一起时接口协议是否对得上”而 e2e 测试关心的是从用户入口到最终落库、回显整条业务链路是否闭环。举个例子你写了一个登录接口单测可以 100% 覆盖校验逻辑你写了一个订单模块单测也能验证价格计算。但用户真正使用时是先登录、再下单、然后支付回调、最后看到订单状态变更。任何一环超时、字段对不上、Cookie 没带上单测全绿也照样白屏。e2e 的价值就在这里它模拟的是“人”而不是“函数”。我一般这样分维度看待各类测试方便团队统一认知测试类型关注点执行频率失败时说明的问题单元测试函数/方法逻辑正确性每次提交某段逻辑写错了集成测试模块间接口契约每日/合并前接口或数据格式不匹配e2e 测试跨模块业务闭环发布前/定时链路断裂、环境或依赖异常这个表也是我在跟开发团队“安利” e2e 时最常用的开场。因为它能让大家都快速理解e2e 不负责抓小虫子它负责守住最后的底线。1.2 为什么需要 e2e profile1 这种机制你可能会问直接写死一套环境配置不就行了做过的人都知道不行。同一套测试代码可能在本地跑的时候连的是 localhost 的服务在测试环境跑的时候连的是 staging 的后端在验收环境跑的时候又要切换成预发布的账号和 SKU 数据。如果每次切换都改代码、改配置维护成本直接爆炸。profile1 便是这套切换机制的典型实现。它像一个“环境档案”把不同场景下的 baseURL、账号、密钥、测试数据集、浏览器参数打包在一起按需激活。你跑本地调试时选 profile1 的本地档CI 跑回归时选 profile1 的 CI 档数据和环境互不干扰。这套设计思路其实来源于服务端的“多环境配置”理念。你写后端项目时一定用过 application-dev.yml 和 application-prod.ymle2e 的 profile 机制本质上就是把这个成熟方案搬到了测试工程里。2. 核心细节解析与实操要点2.1 工具选型为什么我最后留下了 Playwright做 e2e 可选的工具不少Selenium、Cypress、Playwright 都算主流。早期我用了很长一段时间 Selenium它在多浏览器兼容上有天然优势但有两个痛点始终绕不过去环境依赖重、等待策略写起来痛苦。WebDriver 需要额外的驱动管理CI 环境里经常莫名其妙因为 driver 版本不匹配而罢工而隐式等待和显式等待的混合使用几乎每个用例里都要手写轮询逻辑项目一大了就没法看。后来换到 Cypress优点是上手快、debug 体验好时间旅行式的错误回放谁用谁知道。但它对多标签页和跨域场景的支持比较弱这一点对业务系统强依赖第三方登录或支付回调的团队来说很致命。最终我的主力框架换成了 Playwright原因很简单它把常见的等待场景全部内置了并且对多页面、多 API 的模拟能力强出一大截。如果你的团队还在纠结选型我列一个非常主观的对比表可以参考工具上手难度跨域/多页等待策略CI 友好度适合场景Selenium中强需要自己封装一般需要覆盖全部浏览器老版本Cypress低弱内置好纯前端应用、无跨域痛点Playwright中低强内置极好中后台项目、复杂业务链路2.2 用例设计不要按页面写要按用户任务写这是我在做 e2e 设计时最重要的心得测试用例的粒度必须对齐用户任务而不是对齐页面。很多初学者喜欢给每个页面建一个 spec比如 login.spec.ts、cart.spec.ts、order.spec.ts。这种写法执行起来没问题但视角不对。它会让用例关注点落在“这个页面的元素能不能操作”而不是“这个任务的链路能不能走通”。一旦你开始维护会发现大量用例只是换了数据、重复走同样的路径维护成本翻倍收益却很低。我推荐的做法是按核心用户旅程user journey拆分。比如下面这几条用户注册后首次登录并修改个人信息用户将商品加入购物车、结算、支付、查看订单状态用户提交退款申请并跟踪处理进度管理员创建优惠券并验证用户端显示每个 journey 对应一个 spec里面用测试步骤串起多个页面。这样跑完一条用例你验证的是一个完整业务闭环遇到失败时指向性也更明确。2.3 再看 e2e profile1配置文件里的信息结构理解了 profile 是“环境档案”再去看“e2e profile1”这个配置信息就会清晰很多。在我常用的项目结构里profile 至少包含四类信息缺一个都容易出问题第一是环境入口信息也就是当前 profile 对应的 baseURL。这个不仅包括前端页面地址还需要 API 的基础地址和可能的第三方模拟服务地址。第二是身份认证信息。e2e 测试通常不能卡在登录上每次输账号密码效率太低。我会把测试账号的明文信息、以及通过登录接口换出来的 token 或 cookie 都存在 profile 里。如果用的是已登录态还会保存对应的 storageState 文件路径。第三是业务数据集合。比如测试环境下可用的商品 ID、优惠券编码、SKU 数量等。用 profile 管理后换一个环境直接换一套数据测试代码不用改。第四是运行参数。包括无头模式与否、视口大小、浏览器类型、重试次数、超时时间甚至报告输出路径。把这些内容按 profile 组织起来后运行测试就变成了一条指令的事playwright test --confige2e/playwright.config.ts --projectprofile1。3. 实操过程与核心环节实现3.1 项目结构初始化我建议把 e2e 测试工程独立成目录不要和业务代码混在一起。这样依赖隔离、CI 缓存、权限控制都更干净。一个比较标准的布局大概长这样e2e/ ├── playwright.config.ts # 全局配置注册多个 profile/project ├── profiles/ │ ├── profile1.dev.ts # 本地开发档 │ ├── profile1.staging.ts # 测试环境档 │ └── profile1.prod.ts # 验收/预发档 ├── fixtures/ │ └── data.ts # 统一的数据工厂 ├── pages/ │ ├── login.page.ts # 页面对象可选但推荐 │ └── checkout.page.ts ├── specs/ │ ├── auth.spec.ts │ ├── order.spec.ts │ └── refund.spec.ts ├── utils/ │ └── request.ts # 接口直连工具类 └── artifacts/ # 测试产物脚本和截图存这里这个结构看起来简单但有几个细节值得展开。profiles 里面的文件只负责导出参数不包含测试逻辑这是保证可维护性的核心。fixtures/data.ts 里的数据我会尽量用“只读种子数据”而不是每次测试去造数据因为 e2e 跑一遍本身就慢再花时间去初始化前置数据会让反馈周期拉得很长。3.2 写第一个端到端用例我挑一个凡是业务系统几乎都绕不开的场景——登录后创建订单来演示核心代码怎么写。这里用 Playwright 的语法但思路完全可以迁移到别的框架。import { test, expect } from playwright/test; import { loginPage } from ../pages/login.page; import { checkoutPage } from ../pages/checkout.page; test(用户登录后创建一笔订单, async ({ page }) { // 1. 打开登录页用 profile 里预设的账号登录 await page.goto(/login); await loginPage.login(page, process.env.E2E_USER!, process.env.E2E_PASSWORD!); // 2. 断言进入首页并出现用户昵称 await expect(page.getByTestId(user-nickname)).toHaveText(自动测试用户); // 3. 把商品加入购物车并进入结算 await page.goto(/products/1001); await page.getByRole(button, { name: 加入购物车 }).click(); await page.getByRole(button, { name: 去结算 }).click(); // 4. 填写订单并提交 const orderNo await checkoutPage.submitOrder(page, { receiver: 张三, phone: 13800138000, address: 测试园区 1 号楼 }); // 5. 验证订单列表出现该订单号 await expect(page.getByText(orderNo)).toBeVisible(); });看到没整个用例没有一行针对“按 1 秒睡一下再查元素”的传统轮询Playwright 的 locator 会自动等待元素出现这是它比 Selenium 手写等待策略舒服得多的原因。代码里我用了process.env.E2E_USER而不是写死账号也正是为了配合 profile 切换账号信息。3.3 把 profile1 配置完整落地“e2e profile1”里的这个“1”在我理解中不是固定编号而是一个默认主档位的标识。实际操作时我会把 profile1 定为“主测试环境档”它对应的是 stable 的测试环境跑在无头浏览器上作为 CI 的最基本回归档位其他 profile 可以对应本地调试、预发验收等不同场景。下面是我常用的一套配置简化版展示 profile 如何影响运行参数import type { PlaywrightTestConfig } from playwright/test; const profile1 { baseURL: process.env.E2E_BASE_URL ?? https://staging.example.com, user: process.env.E2E_USER ?? auto_test_01, password: process.env.E2E_PASSWORD ?? set_me_in_env, storageState: artifacts/storage/profile1.json, use: { headless: true, viewport: { width: 1440, height: 900 }, screenshot: only-on-failure, trace: retain-on-failure, }, }; const config: PlaywrightTestConfig { testDir: ./specs, timeout: 60_000, expect: { timeout: 10_000 }, projects: [ { name: profile1, use: { ...profile1.use, baseURL: profile1.baseURL }, storageState: profile1.storageState, retries: process.env.CI ? 2 : 0, }, // 此处可配置 profile2、profile3 等其他档位 ], }; export default config;需要注意的一个点是storageState。对于一个需要登录的测试项目每个用例都从头走一遍登录流程不仅慢还可能触发图形验证码。我的做法是先用一次性脚本登录把 Cookie 和 localStorage 存成 storageState 文件然后让大多数用例直接复用这个已登录态。只有涉及权限、账号体系本身的用例才单独走完整登录流程。3.4 数据准备profile 里最容易被忽略的一环配置和代码都就位了但如果你不管测试数据跑起来依然会花式失败。我遇到最多的场景是测试环境被前一个团队的接口联调用脏了商品库存变成 0优惠券过期用户订单状态早已不是初始值。解决这个问题我用的策略是每个 profile 里维护一个数据快照清单用脚本负责把测试数据恢复到预期初始状态。所谓测试数据不一定必须从界面上创建通过 API 直连来造数据反而更高效。我通常在 utils/request.ts 里封装一个带鉴权的请求工具用十几行代码在测试前置阶段创建或重置数据。测试结束后不要急着断言数据“被修改后的永久状态”。持久化数据很容易污染下一次运行所以我会让测试尽量去验证过程结果而不是留下痕迹后的最终结果。比如下单场景验证订单出现在列表就够了如果你连支付状态都要断言就必须做好后续数据清理否则很快会跑挂。3.5 把 e2e 接进流水线本地能跑通只是第一步e2e 真正发挥价值是接进 CI/CD 之后。我在 GitHub Actions 里配置过一套很实用的流程核心思路是定时任务跑全量回归 发布前跑冒烟集。name: E2E Regression on: schedule: - cron: 0 2 * * * # 每天凌晨两点跑 workflow_dispatch: # 允许手动触发 jobs: e2e: runs-on: ubuntu-latest steps: - uses: actions/checkoutv4 - name: 安装依赖和 Playwright 浏览器 run: | npm ci npx playwright install --with-deps chromium - name: 执行 profile1 端到端测试 env: E2E_BASE_URL: ${{ secrets.E2E_BASE_URL }} E2E_USER: ${{ secrets.E2E_USER }} E2E_PASSWORD: ${{ secrets.E2E_PASSWORD }} run: npx playwright test --projectprofile1 - name: 上传测试报告 uses: actions/upload-artifactv4 if: always() with: name: playwright-report path: playwright-report/ retention-days: 14这段配置里有一个很容易踩的细节Playwright 的浏览器二进制不会随npm ci安装必须显式执行npx playwright install。否则你会在流水线里看到一堆精彩的“浏览器启动失败”日志。另外敏感信息千万别硬编码进配置文件全部走仓库 secrets 是底线操作。3.6 如何根据 profile1 拆分冒烟与回归接进流水线之后还有个效率问题全量 e2e 用例一旦多起来一跑就是半小时起步。这时候如果每次发布都跑全量开发节奏会被严重拖慢。我常用的做法是给用例打标签让 profile1 的配置里启用“冒烟集”其他 profile 再跑全量。test.describe(订单相关, () { test(冒烟正常提交订单, async ({ page }) { test.skip(process.env.E2E_SMOKE ! true, 非冒烟模式跳过); // ... }); });更优雅的做法是在配置层面对 tag 做过滤。Playwright 提供了grep参数我习惯用smoke标记关键链路用例然后冒烟任务只跑npx playwright test --projectprofile1 --grep smoke。这样一来发布前 10 分钟的快速反馈和夜间全量回归互不干扰。4. 常见问题与排查技巧实录4.1 选择器不稳定怎么办这类问题排在 e2e 稳定性失败原因的第一名。有些测试同学习惯用page.locator(div.content div.item:nth-child(2))这种层级式选择器一旦前端加了个节点测试就全挂了。我的建议是优先给关键交互元素加上稳定的 test id测试代码里全部通过getByTestId定位。如果改不了业务代码退而求其次用getByRole和文本定位也比裸写 CSS 路径稳得多。前端同学配合加 test id 时别直接在元素上加诸如>
经常有朋友问我项目上线前手工把核心流程点一遍真的够吗我一般会反问一句你的“核心流程”覆盖了登录、下单、支付、回调这几个环节之间的衔接吗多数人卡住的不是单个功能而是功能与功能之间的链路。这也是我为什么一直强调每个项目都应该有一套e2e端到端测试兜底。今天这篇我不打算给你贴一堆官方文档而是用我实际落地时的思路从设计到编码再到排错完整拆一遍“e2e profile1”这套配置到底该怎么理解、怎么用、怎么跑进流水线。先说结论e2e 测试不是“点了按钮没报错”那么肤浅的东西它的核心价值在于把整个业务链路当成一个黑盒用自动化模拟真实用户行为验证系统内外所有依赖是否按预期协作。而 profile1 这种配置说白了就是同一套测试代码在不同环境、不同测试账号、不同数据集合之间切换的钥匙。你理解了这个再去看任何 e2e 框架的配置文件就不会觉得那是一堆魔法参数了。这套经验适合谁刚被领导要求“补一下自动化测试”的后端、前端同学或者已经在写用例但总被稳定性问题折磨的测试开发工程师都可以读一读。我尽量把每一步都讲透包括那些文档里不会写的坑。1. 内容整体设计与思路拆解1.1 e2e 测试到底解决什么问题在软件开发里测试金字塔通常分三层单元测试、集成测试、端到端测试。单元测试锁死的是“这一个函数在给定输入下的输出是否正确”集成测试关注“两个模块拼在一起时接口协议是否对得上”而 e2e 测试关心的是从用户入口到最终落库、回显整条业务链路是否闭环。举个例子你写了一个登录接口单测可以 100% 覆盖校验逻辑你写了一个订单模块单测也能验证价格计算。但用户真正使用时是先登录、再下单、然后支付回调、最后看到订单状态变更。任何一环超时、字段对不上、Cookie 没带上单测全绿也照样白屏。e2e 的价值就在这里它模拟的是“人”而不是“函数”。我一般这样分维度看待各类测试方便团队统一认知测试类型关注点执行频率失败时说明的问题单元测试函数/方法逻辑正确性每次提交某段逻辑写错了集成测试模块间接口契约每日/合并前接口或数据格式不匹配e2e 测试跨模块业务闭环发布前/定时链路断裂、环境或依赖异常这个表也是我在跟开发团队“安利” e2e 时最常用的开场。因为它能让大家都快速理解e2e 不负责抓小虫子它负责守住最后的底线。1.2 为什么需要 e2e profile1 这种机制你可能会问直接写死一套环境配置不就行了做过的人都知道不行。同一套测试代码可能在本地跑的时候连的是 localhost 的服务在测试环境跑的时候连的是 staging 的后端在验收环境跑的时候又要切换成预发布的账号和 SKU 数据。如果每次切换都改代码、改配置维护成本直接爆炸。profile1 便是这套切换机制的典型实现。它像一个“环境档案”把不同场景下的 baseURL、账号、密钥、测试数据集、浏览器参数打包在一起按需激活。你跑本地调试时选 profile1 的本地档CI 跑回归时选 profile1 的 CI 档数据和环境互不干扰。这套设计思路其实来源于服务端的“多环境配置”理念。你写后端项目时一定用过 application-dev.yml 和 application-prod.ymle2e 的 profile 机制本质上就是把这个成熟方案搬到了测试工程里。2. 核心细节解析与实操要点2.1 工具选型为什么我最后留下了 Playwright做 e2e 可选的工具不少Selenium、Cypress、Playwright 都算主流。早期我用了很长一段时间 Selenium它在多浏览器兼容上有天然优势但有两个痛点始终绕不过去环境依赖重、等待策略写起来痛苦。WebDriver 需要额外的驱动管理CI 环境里经常莫名其妙因为 driver 版本不匹配而罢工而隐式等待和显式等待的混合使用几乎每个用例里都要手写轮询逻辑项目一大了就没法看。后来换到 Cypress优点是上手快、debug 体验好时间旅行式的错误回放谁用谁知道。但它对多标签页和跨域场景的支持比较弱这一点对业务系统强依赖第三方登录或支付回调的团队来说很致命。最终我的主力框架换成了 Playwright原因很简单它把常见的等待场景全部内置了并且对多页面、多 API 的模拟能力强出一大截。如果你的团队还在纠结选型我列一个非常主观的对比表可以参考工具上手难度跨域/多页等待策略CI 友好度适合场景Selenium中强需要自己封装一般需要覆盖全部浏览器老版本Cypress低弱内置好纯前端应用、无跨域痛点Playwright中低强内置极好中后台项目、复杂业务链路2.2 用例设计不要按页面写要按用户任务写这是我在做 e2e 设计时最重要的心得测试用例的粒度必须对齐用户任务而不是对齐页面。很多初学者喜欢给每个页面建一个 spec比如 login.spec.ts、cart.spec.ts、order.spec.ts。这种写法执行起来没问题但视角不对。它会让用例关注点落在“这个页面的元素能不能操作”而不是“这个任务的链路能不能走通”。一旦你开始维护会发现大量用例只是换了数据、重复走同样的路径维护成本翻倍收益却很低。我推荐的做法是按核心用户旅程user journey拆分。比如下面这几条用户注册后首次登录并修改个人信息用户将商品加入购物车、结算、支付、查看订单状态用户提交退款申请并跟踪处理进度管理员创建优惠券并验证用户端显示每个 journey 对应一个 spec里面用测试步骤串起多个页面。这样跑完一条用例你验证的是一个完整业务闭环遇到失败时指向性也更明确。2.3 再看 e2e profile1配置文件里的信息结构理解了 profile 是“环境档案”再去看“e2e profile1”这个配置信息就会清晰很多。在我常用的项目结构里profile 至少包含四类信息缺一个都容易出问题第一是环境入口信息也就是当前 profile 对应的 baseURL。这个不仅包括前端页面地址还需要 API 的基础地址和可能的第三方模拟服务地址。第二是身份认证信息。e2e 测试通常不能卡在登录上每次输账号密码效率太低。我会把测试账号的明文信息、以及通过登录接口换出来的 token 或 cookie 都存在 profile 里。如果用的是已登录态还会保存对应的 storageState 文件路径。第三是业务数据集合。比如测试环境下可用的商品 ID、优惠券编码、SKU 数量等。用 profile 管理后换一个环境直接换一套数据测试代码不用改。第四是运行参数。包括无头模式与否、视口大小、浏览器类型、重试次数、超时时间甚至报告输出路径。把这些内容按 profile 组织起来后运行测试就变成了一条指令的事playwright test --confige2e/playwright.config.ts --projectprofile1。3. 实操过程与核心环节实现3.1 项目结构初始化我建议把 e2e 测试工程独立成目录不要和业务代码混在一起。这样依赖隔离、CI 缓存、权限控制都更干净。一个比较标准的布局大概长这样e2e/ ├── playwright.config.ts # 全局配置注册多个 profile/project ├── profiles/ │ ├── profile1.dev.ts # 本地开发档 │ ├── profile1.staging.ts # 测试环境档 │ └── profile1.prod.ts # 验收/预发档 ├── fixtures/ │ └── data.ts # 统一的数据工厂 ├── pages/ │ ├── login.page.ts # 页面对象可选但推荐 │ └── checkout.page.ts ├── specs/ │ ├── auth.spec.ts │ ├── order.spec.ts │ └── refund.spec.ts ├── utils/ │ └── request.ts # 接口直连工具类 └── artifacts/ # 测试产物脚本和截图存这里这个结构看起来简单但有几个细节值得展开。profiles 里面的文件只负责导出参数不包含测试逻辑这是保证可维护性的核心。fixtures/data.ts 里的数据我会尽量用“只读种子数据”而不是每次测试去造数据因为 e2e 跑一遍本身就慢再花时间去初始化前置数据会让反馈周期拉得很长。3.2 写第一个端到端用例我挑一个凡是业务系统几乎都绕不开的场景——登录后创建订单来演示核心代码怎么写。这里用 Playwright 的语法但思路完全可以迁移到别的框架。import { test, expect } from playwright/test; import { loginPage } from ../pages/login.page; import { checkoutPage } from ../pages/checkout.page; test(用户登录后创建一笔订单, async ({ page }) { // 1. 打开登录页用 profile 里预设的账号登录 await page.goto(/login); await loginPage.login(page, process.env.E2E_USER!, process.env.E2E_PASSWORD!); // 2. 断言进入首页并出现用户昵称 await expect(page.getByTestId(user-nickname)).toHaveText(自动测试用户); // 3. 把商品加入购物车并进入结算 await page.goto(/products/1001); await page.getByRole(button, { name: 加入购物车 }).click(); await page.getByRole(button, { name: 去结算 }).click(); // 4. 填写订单并提交 const orderNo await checkoutPage.submitOrder(page, { receiver: 张三, phone: 13800138000, address: 测试园区 1 号楼 }); // 5. 验证订单列表出现该订单号 await expect(page.getByText(orderNo)).toBeVisible(); });看到没整个用例没有一行针对“按 1 秒睡一下再查元素”的传统轮询Playwright 的 locator 会自动等待元素出现这是它比 Selenium 手写等待策略舒服得多的原因。代码里我用了process.env.E2E_USER而不是写死账号也正是为了配合 profile 切换账号信息。3.3 把 profile1 配置完整落地“e2e profile1”里的这个“1”在我理解中不是固定编号而是一个默认主档位的标识。实际操作时我会把 profile1 定为“主测试环境档”它对应的是 stable 的测试环境跑在无头浏览器上作为 CI 的最基本回归档位其他 profile 可以对应本地调试、预发验收等不同场景。下面是我常用的一套配置简化版展示 profile 如何影响运行参数import type { PlaywrightTestConfig } from playwright/test; const profile1 { baseURL: process.env.E2E_BASE_URL ?? https://staging.example.com, user: process.env.E2E_USER ?? auto_test_01, password: process.env.E2E_PASSWORD ?? set_me_in_env, storageState: artifacts/storage/profile1.json, use: { headless: true, viewport: { width: 1440, height: 900 }, screenshot: only-on-failure, trace: retain-on-failure, }, }; const config: PlaywrightTestConfig { testDir: ./specs, timeout: 60_000, expect: { timeout: 10_000 }, projects: [ { name: profile1, use: { ...profile1.use, baseURL: profile1.baseURL }, storageState: profile1.storageState, retries: process.env.CI ? 2 : 0, }, // 此处可配置 profile2、profile3 等其他档位 ], }; export default config;需要注意的一个点是storageState。对于一个需要登录的测试项目每个用例都从头走一遍登录流程不仅慢还可能触发图形验证码。我的做法是先用一次性脚本登录把 Cookie 和 localStorage 存成 storageState 文件然后让大多数用例直接复用这个已登录态。只有涉及权限、账号体系本身的用例才单独走完整登录流程。3.4 数据准备profile 里最容易被忽略的一环配置和代码都就位了但如果你不管测试数据跑起来依然会花式失败。我遇到最多的场景是测试环境被前一个团队的接口联调用脏了商品库存变成 0优惠券过期用户订单状态早已不是初始值。解决这个问题我用的策略是每个 profile 里维护一个数据快照清单用脚本负责把测试数据恢复到预期初始状态。所谓测试数据不一定必须从界面上创建通过 API 直连来造数据反而更高效。我通常在 utils/request.ts 里封装一个带鉴权的请求工具用十几行代码在测试前置阶段创建或重置数据。测试结束后不要急着断言数据“被修改后的永久状态”。持久化数据很容易污染下一次运行所以我会让测试尽量去验证过程结果而不是留下痕迹后的最终结果。比如下单场景验证订单出现在列表就够了如果你连支付状态都要断言就必须做好后续数据清理否则很快会跑挂。3.5 把 e2e 接进流水线本地能跑通只是第一步e2e 真正发挥价值是接进 CI/CD 之后。我在 GitHub Actions 里配置过一套很实用的流程核心思路是定时任务跑全量回归 发布前跑冒烟集。name: E2E Regression on: schedule: - cron: 0 2 * * * # 每天凌晨两点跑 workflow_dispatch: # 允许手动触发 jobs: e2e: runs-on: ubuntu-latest steps: - uses: actions/checkoutv4 - name: 安装依赖和 Playwright 浏览器 run: | npm ci npx playwright install --with-deps chromium - name: 执行 profile1 端到端测试 env: E2E_BASE_URL: ${{ secrets.E2E_BASE_URL }} E2E_USER: ${{ secrets.E2E_USER }} E2E_PASSWORD: ${{ secrets.E2E_PASSWORD }} run: npx playwright test --projectprofile1 - name: 上传测试报告 uses: actions/upload-artifactv4 if: always() with: name: playwright-report path: playwright-report/ retention-days: 14这段配置里有一个很容易踩的细节Playwright 的浏览器二进制不会随npm ci安装必须显式执行npx playwright install。否则你会在流水线里看到一堆精彩的“浏览器启动失败”日志。另外敏感信息千万别硬编码进配置文件全部走仓库 secrets 是底线操作。3.6 如何根据 profile1 拆分冒烟与回归接进流水线之后还有个效率问题全量 e2e 用例一旦多起来一跑就是半小时起步。这时候如果每次发布都跑全量开发节奏会被严重拖慢。我常用的做法是给用例打标签让 profile1 的配置里启用“冒烟集”其他 profile 再跑全量。test.describe(订单相关, () { test(冒烟正常提交订单, async ({ page }) { test.skip(process.env.E2E_SMOKE ! true, 非冒烟模式跳过); // ... }); });更优雅的做法是在配置层面对 tag 做过滤。Playwright 提供了grep参数我习惯用smoke标记关键链路用例然后冒烟任务只跑npx playwright test --projectprofile1 --grep smoke。这样一来发布前 10 分钟的快速反馈和夜间全量回归互不干扰。4. 常见问题与排查技巧实录4.1 选择器不稳定怎么办这类问题排在 e2e 稳定性失败原因的第一名。有些测试同学习惯用page.locator(div.content div.item:nth-child(2))这种层级式选择器一旦前端加了个节点测试就全挂了。我的建议是优先给关键交互元素加上稳定的 test id测试代码里全部通过getByTestId定位。如果改不了业务代码退而求其次用getByRole和文本定位也比裸写 CSS 路径稳得多。前端同学配合加 test id 时别直接在元素上加诸如>
