★ FEATURED ARTICLE 1. 当“e2e”不再只是三个字母从热词到落地场景的拆解第一次看到“e2e”这个词很多人脑子里蹦出来的可能是“端到端”这三个字然后就没有然后了。但如果你最近在技术社区、产品圈或者测试群里泡过就会发现“e2e”出现的频率高得离谱尤其是“e2e profile1”这个组合几乎成了某种默认的入门暗号。我最早接触e2e是在一个后台管理系统的重构项目里当时团队里有人提了一句“咱们得补一套e2e”结果会议室里一半人点头另一半人眼神放空。后来我才意识到e2e这个词被用得太泛了泛到每个人理解的边界都不一样。所以这篇内容我想干一件事把“e2e”从热搜词还原成可操作、可复现的具体实践。不管你是刚入行的测试新人还是写了几年业务代码想补测试短板的开发或者是对质量保障感兴趣的产品经理都能从这里拿到能直接用的东西。我不会只讲概念而是把“e2e profile1”这种热词背后的实际含义、常见工具链、落地步骤、踩坑记录全部摊开来讲。核心关键词就一个e2e。但围绕它展开的是一整套从环境搭建到用例设计再到持续集成的完整链路。先给一个最朴素的界定e2e就是end-to-end的缩写中文叫端到端。它描述的是一种测试视角——从用户真实使用路径的起点出发一路走到终点验证整个系统串联起来之后是否还能正常工作。注意这里的关键词是“串联”。单元测试验证的是单个零件集成测试验证的是几个零件拼在一起而e2e验证的是整台机器通电之后能不能跑起来、跑得对不对。这个区别听起来简单但实际操作中很多人会把集成测试当成e2e来做结果就是用例写了一堆真出问题的时候一个都拦不住。那“e2e profile1”又是什么我在几个技术社区翻了一圈发现这个说法并没有一个官方标准定义更多是社区里约定俗成的一种叫法。通常它指的是一套最基础、最核心的e2e测试配置档案包含默认的浏览器环境、基础的用户路径集合、以及一套最小可用的断言规则。你可以把它理解成“e2e测试的出厂设置”——先跑通profile1再根据业务需要扩展profile2、profile3。这个思路很实用因为它把e2e从“大而全”的泥潭里拉了出来变成可以分阶段推进的事情。接下来的内容会围绕几个核心问题展开e2e到底该测什么、不该测什么profile1这种基础配置怎么搭工具选型背后的取舍逻辑用例设计怎么避免“写得多但没用”以及在实际项目里e2e怎么和CI/CD流水线配合而不变成拖累。每一部分都会配上我实际用过的配置片段和踩坑记录尽量让不同基础的读者都能找到能直接抄作业的部分。2. e2e的边界感哪些场景值得测哪些纯属浪费2.1 从一次“全量e2e”翻车说起我见过最典型的一个反面案例是之前合作过的一个团队他们决定“把所有功能都覆盖e2e”。听起来很有魄力结果三个月后e2e用例数量涨到四百多条每次全量跑一遍要四十多分钟而且失败率高达三成。更要命的是这三十%的失败里大部分是环境抖动、测试数据污染、或者某个无关紧要的文案改动导致的。团队每天早上的第一件事变成了“看昨天夜里e2e挂了哪些然后判断是不是真bug”。到最后大家对e2e的信任度降到冰点有人甚至提议直接关掉。这个案例的核心问题不是e2e本身不好而是边界没划清楚。e2e的价值在于验证“用户完成一个完整目标”的路径是否通畅而不是验证每一个按钮的颜色、每一个字段的校验规则。那些细枝末节的验证应该下沉到单元测试或集成测试里去。e2e要抓的是“主干道”上的问题登录能不能成功、下单流程能不能走通、支付回调之后订单状态对不对、核心数据能不能正确落库并展示。所以我在设计e2e用例时会先画一张“用户核心任务地图”。比如一个电商系统核心任务可能只有四条浏览商品并搜索、加入购物车并下单、完成支付、查看订单状态。这四条路径覆盖了用户百分之八十的使用场景也覆盖了系统百分之九十的核心风险点。剩下的边缘功能比如修改头像、切换语言、查看帮助文档用集成测试覆盖就够了没必要塞进e2e里。2.2 判断一条用例该不该进e2e的三个问题每次有人问我“这个场景要不要写e2e”我都会让他先回答三个问题。第一个问题这个场景如果坏了用户会不会立刻感知到并且无法完成核心任务如果答案是“会”那它值得进e2e。第二个问题这个场景是否跨越了多个系统或服务比如从前端页面到后端API再到数据库再到消息队列如果只涉及一个模块内部那它更适合集成测试。第三个问题这个场景的验证成本是否可控如果为了测它需要准备大量测试数据、模拟复杂的外部依赖、或者等待很长的异步时间那就要慎重因为e2e的维护成本会随着这类用例的增加而指数级上升。这三个问题本质上是在做风险与成本的权衡。e2e测试跑得慢、维护贵所以它必须用在刀刃上。我通常会把e2e用例控制在二十到三十条之间最多不超过五十条。这个数量足够覆盖核心链路又不至于让维护变成噩梦。每条用例都对应一个明确的用户目标而不是一个技术实现细节。2.3 profile1的定位最小可用e2e集合回到“e2e profile1”这个概念。我理解的profile1就是上面说的那二十到三十条核心用例的集合加上一套最简化的运行配置。它的目标不是“全面”而是“跑通”。具体来说profile1通常包含以下要素一个默认的浏览器环境比如Chromium headless模式、一套基础的用户认证方式比如通过API直接注入登录态而不是每次都走UI登录、一个干净的测试数据库快照、以及一组按优先级排序的核心用例。为什么要把profile1单独拎出来因为在实际项目里e2e的推进往往是渐进的。一开始就搞一套大而全的配置很容易因为环境问题、数据问题、依赖问题而卡住。profile1的思路是先用最小的成本把主链路跑起来让团队看到e2e的价值然后再逐步扩展。这就像盖房子先搭主体结构再搞装修而不是一开始就纠结墙纸的颜色。我在自己的项目里profile1的配置文件通常长这样// e2e.config.profile1.js module.exports { browser: chromium, headless: true, baseUrl: process.env.E2E_BASE_URL || http://localhost:3000, timeout: 30000, retries: 1, workers: 2, reporter: [[list], [html, { outputFolder: e2e-report }]], use: { trace: on-first-retry, screenshot: only-on-failure, video: retain-on-failure, }, projects: [ { name: profile1-core, testMatch: /core\/.*\.spec\.js/, }, ], };这个配置里几个关键点值得展开说。headless: true是为了在CI环境里跑本地调试时可以临时改成false。retries: 1是给一次重试机会因为e2e偶尔会因为网络抖动或渲染延迟而失败一次重试能过滤掉大部分假失败。workers: 2是并发数不要设太高否则测试数据容易互相干扰。trace和video只在失败时保留避免每次跑完都产生一堆没用的文件。testMatch只匹配core目录下的用例这就是profile1的边界。3. 工具链选型为什么我最终留在了Playwright3.1 从Selenium到Cypress再到Playwright的迁移史我最早做e2e用的是Selenium那时候还是WebDriver协议写一个简单的登录测试要配一堆东西。后来Cypress出来了开发体验确实好了一大截自动等待、时间旅行调试、内置断言这些特性让写e2e的门槛降低了很多。但Cypress有几个硬伤它运行在浏览器内部所以多标签页、多域名的场景处理起来很别扭它的并发能力也有限跑大量用例时速度上不去。再后来Playwright出现了我抱着试试看的心态迁移了一个项目结果就再也没回去过。Playwright最打动我的地方是它的架构设计。它通过WebSocket与浏览器通信而不是注入到页面里所以天然支持多标签页、多上下文、多域名。它的自动等待机制比Cypress更细粒度可以针对不同元素设置不同的等待策略。它的并发模型是基于浏览器上下文的每个测试用例可以拥有独立的上下文互不干扰。这些特性在profile1这种核心用例集合里可能感受不明显但一旦用例数量上去、场景复杂起来优势就非常突出了。3.2 选型时我实际对比的五个维度当时做选型的时候我列了一个对比表从五个维度来评估。第一个维度是跨浏览器支持Playwright原生支持Chromium、Firefox、WebKitCypress主要支持Chromium系和FirefoxSelenium虽然支持最广但配置最繁琐。第二个维度是自动等待能力Playwright和Cypress都做得不错但Playwright的等待策略更透明可以通过expect的轮询机制精确控制。第三个维度是并发执行Playwright的worker模型最成熟Cypress需要付费的Dashboard才能较好地支持并行。第四个维度是调试体验Cypress的时间旅行确实独树一帜但Playwright的trace viewer在事后分析上更强。第五个维度是生态和社区Selenium最老牌Cypress的插件生态最丰富Playwright虽然年轻但官方维护的组件质量很高。最终我选择Playwright核心原因是它在“并发能力”和“跨浏览器支持”这两个维度上明显领先而这两个维度恰好是profile1向profile2扩展时最关键的瓶颈。当然如果你的团队已经深度绑定了Cypress而且用例规模不大那继续用Cypress也完全没问题。工具选型没有绝对的对错只有适不适合当前的场景。3.3 安装与初始化三行命令背后的细节Playwright的安装看起来很简单但有几个细节如果不注意后面会踩坑。标准的安装流程是这样的npm init playwrightlatest # 或者手动安装 npm install -D playwright/test npx playwright install第一行命令会引导你创建一个Playwright项目包括配置文件、示例测试、以及GitHub Actions的工作流文件。如果你选择手动安装那npx playwright install这一步会下载Chromium、Firefox、WebKit三个浏览器的二进制文件总共大概几百兆。在国内网络环境下这一步可能会比较慢可以设置镜像源来加速。安装完成之后我建议先跑一下自带的示例测试确认环境没问题npx playwright test --projectchromium如果示例测试能跑通说明浏览器安装和基础配置都正常。接下来就可以开始搭建profile1的目录结构了。我通常会把测试用例按业务模块分目录比如tests/core/auth.spec.js、tests/core/order.spec.js然后在配置文件里用testMatch来区分profile1和后续的扩展profile。注意Playwright的浏览器二进制文件默认安装在用户目录下的缓存文件夹里如果CI环境每次都是全新的容器记得把npx playwright install加到流水线的构建步骤里否则会报找不到浏览器的错误。4. 用例设计实战从登录到下单的完整链路4.1 登录态注入绕过UI登录的两种可靠方案在e2e测试里如果每个用例都从UI登录开始那会浪费大量时间而且登录页面的任何改动都会导致所有用例失败。所以profile1里通常会把登录态注入作为一个前置步骤。Playwright提供了两种主流方案。第一种是使用storageState先跑一个专门的登录用例把登录后的cookies和localStorage保存下来后续用例直接复用这个状态。第二种是通过API直接获取token然后在context里设置对应的header或cookie。我两种都用过各有适用场景。storageState方案更接近真实用户行为适合验证登录流程本身的用例以及那些依赖前端存储状态的场景。API注入方案更快更稳定适合大多数不需要验证登录UI的用例。在实际项目里我通常会把两者结合起来用一个专门的auth.setup.js来生成storageState然后在全局配置里引用它。// tests/setup/auth.setup.js const { test: setup, expect } require(playwright/test); setup(authenticate as standard user, async ({ page }) { await page.goto(/login); await page.fill([data-testidusername], process.env.E2E_USER); await page.fill([data-testidpassword], process.env.E2E_PASS); await page.click([data-testidlogin-submit]); await expect(page.locator([data-testiduser-avatar])).toBeVisible(); await page.context().storageState({ path: e2e/.auth/user.json }); });然后在playwright.config.js里配置globalSetup或者用projects的dependencies来引用这个setup。这样每个用例启动时都会自动带上登录态省去了重复登录的时间。实测下来这个优化能让整个profile1的运行时间缩短百分之四十左右。4.2 核心链路用例的编写结构以电商下单为例一条完整的e2e用例应该覆盖从搜索商品到支付成功的全过程。但这里有个取舍是把所有步骤写在一个test里还是拆成多个test我的经验是如果这些步骤共享同一个用户会话和同一份测试数据那就写在一个test里用test.step来划分阶段。这样既能保证链路的完整性又能在报告里清晰地看到每一步的耗时和状态。const { test, expect } require(playwright/test); test(user can complete purchase flow, async ({ page }) { await test.step(search for product, async () { await page.goto(/); await page.fill([data-testidsearch-input], 无线耳机); await page.click([data-testidsearch-button]); await expect(page.locator([data-testidproduct-card]).first()).toBeVisible(); }); await test.step(add to cart and checkout, async () { await page.locator([data-testidproduct-card]).first().click(); await page.click([data-testidadd-to-cart]); await page.click([data-testidcart-icon]); await expect(page.locator([data-testidcart-item])).toHaveCount(1); await page.click([data-testidcheckout-button]); }); await test.step(complete payment, async () { await page.fill([data-testidaddress-input], 测试地址); await page.click([data-testidsubmit-order]); await expect(page.locator([data-testidpayment-success])).toBeVisible({ timeout: 15000 }); }); await test.step(verify order status, async () { await page.goto(/orders); await expect(page.locator([data-testidorder-status]).first()).toHaveText(已支付); }); });这个结构的好处是当用例失败时报告里会直接告诉你是在哪个step失败的排查起来非常快。另外test.step里的断言要尽量具体不要只断言“页面加载了”而要断言“某个关键元素出现了”或者“某个文本内容正确”。这样能避免用例“假通过”——页面虽然加载了但显示的是错误信息。4.3 测试数据的准备与清理e2e测试最头疼的问题之一就是测试数据。如果多个用例共用同一份数据很容易出现互相干扰。比如用例A把商品库存买光了用例B再去买就失败了。解决这个问题的思路有三种第一种是每个用例创建独立的数据用完就删第二种是使用数据库快照每个用例开始前恢复到干净状态第三种是使用专门的测试环境数据隔离做得更彻底。在profile1阶段我通常推荐第一种方案因为它最简单、最可控。具体做法是在用例开始前通过API创建所需的数据在用例结束后通过API删除。Playwright提供了test.beforeEach和test.afterEach钩子来实现这个逻辑。如果API创建数据太慢也可以考虑在测试数据库里预置一批数据然后每个用例只操作其中独立的部分。test.beforeEach(async ({ request }) { const response await request.post(/api/test-data/product, { data: { name: 测试商品, stock: 100, price: 99.00 }, }); const product await response.json(); test.info().annotations.push({ type: productId, description: product.id }); }); test.afterEach(async ({ request }) { const productId test.info().annotations.find(a a.type productId)?.description; if (productId) { await request.delete(/api/test-data/product/${productId}); } });提示测试数据的创建和清理一定要走API不要直接操作数据库。因为直接操作数据库会绕过业务逻辑可能产生不一致的数据状态而且当数据库结构变化时测试代码也要跟着改维护成本很高。5. 让e2e跑得稳环境隔离与失败重试的实战配置5.1 环境隔离的三个层次e2e测试跑不稳十有八九是环境问题。我见过太多团队把e2e跑在开发环境上结果开发一提交代码e2e就挂了或者跑在预发环境上但预发环境的数据被人工操作污染了。要解决这个问题环境隔离必须做到三个层次。第一个层次是环境独立e2e应该跑在一个专门的环境里这个环境不对外提供服务只给自动化测试用。第二个层次是数据独立e2e环境应该使用独立的数据库或schema避免和人工测试数据混在一起。第三个层次是依赖独立e2e环境依赖的外部服务比如支付网关、短信服务应该使用mock或sandbox版本避免产生真实费用或副作用。在profile1阶段如果资源有限至少要做到第一个层次。可以用Docker Compose在本地或CI里快速拉起一套完整的e2e环境包括应用服务、数据库、缓存等。这样每次跑e2e之前环境都是全新的不会受到之前测试的影响。# docker-compose.e2e.yml version: 3.8 services: app: build: . ports: - 3000:3000 environment: - NODE_ENVe2e - DATABASE_URLpostgres://e2e:e2edb:5432/e2e depends_on: - db db: image: postgres:15 environment: - POSTGRES_USERe2e - POSTGRES_PASSWORDe2e - POSTGRES_DBe2e ports: - 5432:5432这个Compose文件定义了一个最小的e2e环境应用服务和数据库都在独立的容器里。跑测试之前先docker-compose -f docker-compose.e2e.yml up -d跑完之后down掉环境就干净了。如果CI环境支持还可以在每个流水线里动态创建和销毁这套环境做到完全隔离。5.2 失败重试与假失败的区分e2e测试的失败分为两种真失败和假失败。真失败是代码真的有bug假失败是环境抖动、网络延迟、渲染时机等非代码因素导致的。如果不加区分地对待所有失败团队很快就会被假失败淹没进而对e2e失去信心。Playwright提供了retries配置来处理这个问题但重试策略需要仔细设计。我的经验是profile1的用例可以设置retries: 1也就是失败后自动重试一次。如果重试通过了那大概率是假失败可以在报告里标记为“flaky”但不阻塞流水线。如果重试仍然失败那就需要人工介入判断。但要注意重试不能滥用。如果一个用例频繁需要重试才能通过那说明它本身就不稳定应该去修复它的根本原因而不是靠重试来掩盖。// playwright.config.js module.exports { retries: process.env.CI ? 1 : 0, reporter: [ [list], [json, { outputFile: e2e-results.json }], [html, { outputFolder: e2e-report, open: never }], ], };在CI环境里设置retries: 1本地开发时设置retries: 0这样本地跑的时候能第一时间看到真实失败CI里则能过滤掉一部分假失败。另外trace: on-first-retry这个配置也很关键它会在第一次重试时记录完整的trace包括网络请求、DOM快照、控制台日志排查假失败的原因时非常有用。5.3 超时设置的取舍Playwright的默认超时是30秒对于大多数e2e用例来说够用了。但有些场景需要更长的超时比如等待异步任务完成、等待第三方回调、等待文件上传处理等。这时候不要全局调大超时而是针对具体的断言或操作设置局部超时。// 全局超时保持30秒 // 针对特定操作设置更长超时 await expect(page.locator([data-testidasync-result])).toBeVisible({ timeout: 60000 });全局超时设得太大会导致真失败时等待时间过长拖慢整个流水线。局部超时则可以在需要的地方灵活调整。另外page.waitForTimeout()这种硬等待要尽量避免因为它不管条件是否满足都会等满时间。应该用waitForSelector、waitForResponse、expect().toBeVisible()这些基于条件的等待方式。6. 接入CI/CDe2e在流水线里的正确位置6.1 触发时机什么时候跑profile1e2e跑在流水线的哪个阶段直接决定了它的价值和成本。如果每次提交都跑全量e2e那流水线会变得很慢开发体验很差。如果只在发版前跑那又失去了及时反馈的意义。我的建议是分阶段触发profile1的核心用例在每次合并请求时跑但只跑受影响模块相关的用例全量e2e在合并到主分支后跑完整的跨浏览器e2e在发版前跑。具体来说可以利用Playwright的--grep或--project参数来筛选用例。比如在合并请求阶段只跑smoke标记的用例这些用例覆盖最核心的几条链路运行时间控制在五分钟以内。合并到主分支后跑完整的profile1运行时间控制在十五分钟以内。发版前再跑profile2和profile3包括跨浏览器和性能相关的用例。# 合并请求阶段只跑冒烟用例 npx playwright test --grep smoke --projectprofile1-core # 主分支合并后跑完整profile1 npx playwright test --projectprofile1-core # 发版前跑所有profile npx playwright test6.2 报告与通知让失败信息触达对的人e2e跑完之后报告怎么呈现、失败怎么通知这些细节决定了团队能不能快速响应。Playwright自带的HTML报告已经很好用了可以展示每个用例的状态、耗时、截图、trace。但在CI环境里还需要把报告归档并且把失败信息推送到团队的沟通工具里。我通常会在CI配置里加两步一步是上传HTML报告作为构建产物另一步是解析JSON结果把失败的用例名称和错误信息提取出来发送到对应的频道。这样开发同学不需要登录CI平台就能看到哪些用例挂了、挂在哪里。# .github/workflows/e2e.yml - name: Run e2e tests run: npx playwright test --projectprofile1-core continue-on-error: true - name: Upload report uses: actions/upload-artifactv3 if: always() with: name: e2e-report path: e2e-report/ - name: Notify on failure if: failure() run: | node scripts/notify-failure.js e2e-results.json注意continue-on-error: true这个配置很重要它保证e2e失败时后续的上传报告和通知步骤仍然会执行。否则一旦e2e挂了报告就丢了排查起来很麻烦。6.3 性能优化让profile1跑得更快e2e跑得慢是常态但可以通过一些手段来优化。第一个手段是并发执行Playwright的workers配置可以控制并发数但要注意测试数据隔离否则并发会带来数据冲突。第二个手段是复用登录态前面已经讲过这里不再赘述。第三个手段是拦截不必要的请求比如图片、字体、分析脚本这些资源对测试目标没有影响可以在context层面拦截掉。// 拦截图片和字体请求加速页面加载 await context.route(**/*.{png,jpg,jpeg,gif,svg,woff,woff2}, route route.abort());第四个手段是使用更快的断言方式。比如expect(locator).toHaveText()比page.textContent()再手动比较要快因为前者内置了轮询和重试机制。第五个手段是合理设置actionTimeout和navigationTimeout不要设得太长避免一个卡住的用例拖慢整体。实测下来这些优化组合起来能让profile1的运行时间从二十分钟压缩到八分钟左右。对于每天要跑几十次的流水线来说这个提升非常可观。7. 那些只有踩过才知道的坑7.1 选择器漂移为什么data-testid是底线e2e用例最脆弱的环节就是选择器。用CSS类名或XPath做选择器一旦前端重构类名变了用例就全挂了。我经历过一次前端改版把所有的btn-primary改成了button--primary结果三百多条e2e用例一夜之间全红。从那以后我坚持一个原则所有e2e用例必须使用>!-- 推荐 -- button>// 不推荐可能因为元素未渲染而失败 const text await page.textContent([data-testidresult]); // 推荐内置轮询等待 await expect(page.locator([data-testidresult])).toHaveText(成功);还有一个常见的坑是动画。有些元素在动画过程中虽然可见但位置在变化点击可能会点偏。这时候可以用page.locator().click({ force: true })强制点击或者等动画结束后再操作。但force: true要慎用因为它会跳过可操作性检查可能掩盖真正的问题。7.3 测试数据污染一个订单状态引发的血案测试数据污染是e2e里最隐蔽的坑之一。我曾经遇到过一个用例单独跑的时候永远通过但放在全量跑的时候就会失败。排查了很久才发现是另一个用例修改了同一个订单的状态导致这个用例断言的时候看到了错误的状态。这种问题在用例数量少的时候不容易发现一旦用例多起来、并发跑起来就会频繁出现。解决这个问题的根本方法是数据隔离。每个用例应该操作自己独立的数据不和其他用例共享。如果做不到完全隔离那至少要做到“谁创建谁清理”并且清理逻辑要放在afterEach里确保即使用例失败也能执行。另外测试环境的数据库应该定期重置避免历史数据积累导致意外冲突。test.afterEach(async ({ request }) { // 清理当前用例创建的所有数据 await request.post(/api/test-data/cleanup, { data: { testRunId: test.info().testId }, }); });如果团队有资源可以考虑用Testcontainers这样的工具为每个测试运行动态创建一个独立的数据库实例。这样隔离级别最高但成本也最高。在profile1阶段用API清理加上定期重置数据库通常就够用了。7.4 CI环境下的浏览器依赖问题在本地跑得好好的e2e一到CI就挂很多时候是浏览器依赖的问题。Playwright安装的浏览器需要一些系统库比如libnss3、libatk-bridge2.0-0、libdrm2等。如果CI的容器镜像里没有这些库浏览器就启动不了。Playwright官方提供了一个安装依赖的命令npx playwright install-deps这个命令会自动安装所需的系统库。但在某些精简的容器镜像里可能连apt都没有那就需要手动在Dockerfile里加上这些依赖。我通常会在CI的Dockerfile里显式地安装这些库而不是依赖install-deps因为这样更可控构建缓存也更稳定。FROM node:18-slim RUN apt-get update apt-get install -y \ libnss3 libatk-bridge2.0-0 libdrm2 libxkbcommon0 \ libxcomposite1 libxdamage1 libxfixes3 libxrandr2 \ libgbm1 libasound2 \ rm -rf /var/lib/apt/lists/*提示如果CI环境是ARM架构的比如Apple Silicon的Mac mini或者某些云厂商的ARM实例需要确保Playwright的浏览器版本支持ARM。Playwright从1.30版本开始对ARM的支持已经比较完善了但还是要确认一下具体的浏览器版本。8. 从profile1到profile2e2e体系的扩展思路profile1跑稳之后下一步自然是扩展。但扩展不是简单地增加用例数量而是要有策略地覆盖更多场景。我通常会把profile2定位为“跨浏览器兼容性测试”在profile1的核心用例基础上增加Firefox和WebKit两个浏览器的运行。profile3则定位为“异常场景和边界条件”比如网络中断、接口超时、并发操作等。扩展的时候要注意不要一次性把所有场景都加进去而是按优先级逐步推进。每增加一个profile都要确保它的运行时间可控、失败率可控。如果某个profile的失败率长期高于百分之十那说明它的用例设计或环境配置有问题应该先修复再继续扩展。另外profile1的用例应该保持稳定不要频繁修改。它是整个e2e体系的基础如果基础不稳上面的扩展都是空中楼阁。我通常会把profile1的用例冻结起来只有核心链路发生变化时才更新其他场景都放到profile2和profile3里去。在实际操作中我还发现一个有用的技巧给每个用例打上标签比如smoke、regression、cross-browser。这样在CI里可以根据标签灵活组合运行哪些用例。比如合并请求时只跑smoke主分支合并后跑smoke加regression发版前跑全部。标签体系让e2e的运行策略变得非常灵活也方便团队根据实际情况调整。最后分享一个我在多个项目里验证过的经验e2e测试的价值不在于数量而在于信任度。如果团队相信e2e挂了就是真的有问题那它就有价值如果团队觉得e2e挂了“大概率是环境问题重跑一下就好”那它就失去了意义。所以与其追求覆盖更多场景不如先把profile1的二十条核心用例做到百分之九十九的稳定通过率。这个目标看起来不高但实际做起来需要持续投入包括环境治理、数据隔离、选择器规范、失败分析等。一旦做到了e2e就会成为团队质量保障体系里最可靠的一道防线。
阅读完成 · 觉得有帮助？
的排查与解决方法)
