从零构建现代Web自动化测试：Playwright核心原理与实战指南

1. 项目概述为什么是Playwright如果你正在寻找一个能彻底改变你Web自动化测试体验的工具那么Playwright很可能就是答案。作为一名在测试领域摸爬滚打了十多年的老兵我经历过从Selenium的辉煌到其瓶颈期的阵痛也试用过不少号称“下一代”的框架。最终当我把项目的主力自动化框架切换到Playwright后那种“终于找对了工具”的感觉非常强烈。它不仅仅是一个测试框架更是一个为现代Web应用和开发流程量身定制的完整解决方案。简单来说Playwright是一个由微软开发的开源浏览器自动化库。它允许你使用单一的API来驱动ChromiumChrome、Edge、Firefox和WebKitSafari三大浏览器引擎进行端到端的测试、脚本编写甚至为AI代理提供浏览器控制能力。它的核心价值在于其“可靠性”和“开发者体验”。在自动化测试中最让人头疼的莫过于“不稳定测试”Flaky Tests——那些时而成功时而失败的用例。Playwright通过其“自动等待”和“Web优先断言”机制从设计根源上大幅减少了这类问题的发生。这意味着你可以花更少的时间去调试和维护测试脚本而将更多精力投入到创造更有价值的测试用例上。这个项目适合谁无论你是刚入行的测试新人希望建立一个稳固、现代的自动化测试知识体系还是资深的自动化测试工程师正在为现有Selenium框架的维护成本和高脆弱性而苦恼亦或是全栈开发者需要在CI/CD流水线中快速集成可靠的UI测试Playwright都值得你投入时间从零开始学习。它支持TypeScript/JavaScript、Python、Java和.NET几乎覆盖了主流的开发生态。接下来我将带你从最基础的安装配置开始一步步深入到核心原理、最佳实践和那些官方文档里不会写的“坑”帮你构建一套扎实的Playwright实战能力。2. 环境准备与核心安装指南工欲善其事必先利其器。Playwright的安装过程非常顺畅但其中有一些选项和细节理解清楚能让你后续的开发和调试事半功倍。这里我以最常用的Node.jsTypeScript/JavaScript和Python环境为例进行说明。2.1 Node.js环境下的安装与初始化对于前端或全栈开发者Node.js是首选。Playwright提供了两种主要的安装方式一种是用于测试的playwright包和测试运行器另一种是用于脚本和AI代理的CLI工具。首先创建一个新的项目目录并初始化npm如果你还没有package.jsonmkdir my-playwright-project cd my-playwright-project npm init -y核心安装命令官方推荐使用init命令来搭建一个完整的测试项目骨架。这是我最推荐新手上手的方式因为它不仅安装包还会生成一套标准的目录结构和配置文件。npm init playwrightlatest执行这个命令后你会看到一个交互式的命令行界面。它会问你几个问题选择测试语言是TypeScript还是JavaScript我强烈建议选择TypeScript即使你不熟悉它。Playwright对TypeScript的支持是一流的其类型定义能提供卓越的代码提示和错误预防能极大提升开发效率。选择测试运行器是Playwright Test还是Jest/Vitest等务必选择Playwright Test。这是Playwright官方的、功能全面的测试运行器深度集成了自动等待、追踪、并行等特性是发挥Playwright全部威力的关键。选择默认浏览器通常全选Chromium, Firefox, WebKit即可这样能确保跨浏览器测试能力。是否安装GitHub Actions工作流建议选择“是”。这会生成一个基础的CI配置文件让你能一键将测试集成到GitHub的自动化流程中非常方便。这个命令完成后你的项目会生成以下关键文件和目录playwright.config.ts核心配置文件。你可以在这里设置全局超时时间、配置并行执行、指定测试目录、设置基础URL、配置视口大小等。tests/默认的测试文件存放目录。tests-examples/一些示例测试文件供你参考。package.json其中会添加playwright/test依赖和npm run test等脚本。注意npm init playwrightlatest命令会自动安装浏览器。这些浏览器是Playwright专门打包的、版本匹配的“专有浏览器”它们被安装在~/Library/Caches/ms-playwrightmacOS或%USERPROFILE%\AppData\Local\ms-playwrightWindows等系统缓存目录中与你自己安装的Chrome或Edge是隔离的。这保证了测试环境的绝对一致性和可复现性是Playwright稳定性的基石之一。如果你想单独安装Playwright库例如用于编写非测试的自动化脚本可以npm install playwright但作为测试框架学习我们主要使用playwright/test。2.2 Python环境下的安装对于后端或测试工程师更熟悉的Python生态安装同样简单。首先确保你已安装Python3.7及以上和pip。使用pip安装pip install pytest-playwright这个命令会安装Playwright的Python库以及pytest插件。Playwright Test运行器在Python中是通过pytest加上pytest-playwright插件来实现的。安装浏览器安装库之后你需要安装浏览器二进制文件。这是必须的一步。playwright install这个命令会下载Chromium、Firefox和WebKit的匹配版本。同样它们被安装在用户目录的缓存中。如果你想只安装特定浏览器可以使用playwright install chromium或playwright install firefox。实操心得在CI/CD环境如GitHub Actions, GitLab CI或Docker容器中安装时经常需要处理浏览器依赖。对于基于Debian/Ubuntu的系统Playwright提供了一个便捷脚本来安装系统依赖playwright install-deps对于CentOS 7等老系统你可能会遇到GLIBC版本问题如搜索热词中的glibc 2.17。这时Playwright安装的浏览器可能需要更高的GLIBC。解决方案通常是1) 在更现代的Linux发行版上运行2) 使用Docker镜像Playwright官方提供了mcr.microsoft.com/playwright镜像3) 或者尝试寻找兼容的旧版本Playwright和浏览器组合但这不推荐可能会失去新特性支持。2.3 验证安装与第一个测试安装完成后让我们快速运行一个示例测试来验证一切正常。在Node.js项目中查看package.json你应该能看到类似这样的脚本{ scripts: { test: playwright test, test:ui: playwright test --ui, test:debug: playwright test --debug } }运行npm run test它会执行tests目录下所有的测试。首次运行会花点时间之后就会很快。更棒的是使用npm run test:ui可以启动Playwright的测试UI模式。这是一个图形化的测试运行器可以直观地看到测试列表、运行状态、追踪信息并且可以点击运行单个测试对于调试和学习来说是无价之宝。在Python环境中你可以创建一个简单的测试文件test_example.pyimport re from playwright.sync_api import Page, expect def test_has_title(page: Page): page.goto(https://playwright.dev) # 断言页面标题包含“Playwright” expect(page).to_have_title(re.compile(Playwright)) def test_get_started_link(page: Page): page.goto(https://playwright.dev) # 点击一个文本为“Get started”的链接 link page.get_by_role(link, nameGet started) link.click() # 断言URL包含“/docs/intro” expect(page).to_have_url(re.compile(.*/docs/intro))然后使用pytest运行pytest test_example.py或者使用Playwright Test运行器如果使用playwright test命令初始化了项目playwright test3. Playwright核心概念与设计哲学解析要高效使用Playwright不能只停留在API调用层面理解其背后的设计哲学和核心概念至关重要。这能帮助你在遇到复杂场景时做出正确的技术选型和问题排查。3.1 浏览器、上下文与页面三层隔离模型这是Playwright架构的基石理解它们的关系对编写可靠测试至关重要。浏览器Browser对应一个浏览器进程实例如一个Chrome浏览器。通过await chromium.launch()启动。启动时可以配置无头模式、窗口大小、代理等。浏览器上下文Browser Context这是Playwright中一个极其重要的概念。你可以把它想象成一个全新的、独立的浏览器会话。每个上下文都有独立的cookie、本地存储、缓存和证书但共享同一个浏览器进程。创建上下文的开销远小于启动一个新浏览器。const context await browser.newContext();为什么这很重要它实现了完美的测试隔离。每个测试用例都在自己独立的上下文中运行互不干扰。一个测试登录另一个测试未登录状态它们可以并行运行而不会串号。这从根本上解决了传统自动化测试中常见的状态污染问题。页面Page对应一个浏览器标签页。一个上下文中可以包含多个页面。const page await context.newPage();这种三层模型带来了巨大的灵活性。例如你可以模拟两个完全独立的用户在同一浏览器中同时操作创建两个Context也可以模拟同一个用户打开多个标签页在一个Context下创建多个Page。3.2 自动等待告别“sleep”和“flaky tests”这是Playwright相较于Selenium等老牌工具最革命性的改进之一。在Selenium中你需要频繁地使用WebDriverWait或硬编码的time.sleep()来等待元素出现、可点击或加载完成这既繁琐又容易导致测试不稳定。Playwright的绝大多数操作如click,fill,hover和断言如expect(locator).toBeVisible()都内置了智能等待。具体来说操作等待在执行一个操作如点击之前Playwright会进行一系列可操作性检查。例如对于locator.click()它会等待该元素被附加到DOM中。可见非隐藏、非0尺寸。稳定停止动画。可接收事件未被其他元素遮挡。启用非disabled。 只有所有这些条件都满足它才会执行点击。如果超时默认30秒仍未满足则抛出错误。断言等待Playwright的断言是“异步”且“重试”的。当你执行expect(locator).toHaveText(something)时断言不会立即失败而是会在超时时间内不断重试检查直到条件满足或超时。这意味着在绝大多数情况下你完全不需要在测试代码中编写显式的等待语句。你的代码可以写得像用户操作一样直接、线性。注意事项虽然自动等待解决了大部分问题但在一些极端场景下仍需注意网络请求如果操作触发了一个较慢的API调用页面内容才会更新你可能需要等待特定的网络响应。可以使用page.waitForResponse(url)。导航page.goto()会等待页面触发load事件。但如果你的页面是单页应用SPA主要内容通过JavaScript异步加载load事件触发时内容可能还未就绪。此时更可靠的做法是goto之后再等待一个特定的、能代表页面加载完成的元素出现例如await page.getByText(Welcome).waitFor()。自定义等待如果确实需要等待一个非标准条件可以使用page.waitForFunction()或locator.waitFor()但应作为最后的手段。3.3 定位器Locator强大而稳健的元素查找方式定位元素是自动化测试的基石。Playwright强烈推荐使用其定位器API而不是直接使用CSS或XPath字符串。定位器API更贴近用户视角也更健壮。核心定位器方法page.getByRole():首选方法。通过ARIA角色如button,link,textbox和可访问名称来定位。这最符合无障碍规范也最稳定。await page.getByRole(button, { name: Submit }).click();page.getByText(): 通过文本内容定位。page.getByLabel(): 通过关联的label文本定位表单控件。page.getByPlaceholder(): 通过占位符文本定位。page.getByAltText(): 通过图片的alt属性定位。page.getByTitle(): 通过title属性定位。page.getByTestId():强烈推荐用于关键交互元素。这是最稳定的方式。你需要给HTML元素添加一个>// 先找到表格再在表格里找包含特定文本的行 const row page.getByRole(table).getByRole(row).filter({ hasText: John Doe }); // 在那一行里点击编辑按钮 await row.getByRole(button, { name: Edit }).click();与Selenium定位的对比Selenium主要依赖findElement(By.css(...))或By.xpath(...)。这些定位器非常脆弱前端微小的样式或结构改动比如div改成span或者加了一层包装就可能导致定位失败。Playwright的定位器API特别是getByRole和getByTestId极大地提升了测试的健壮性。4. 编写你的第一个端到端测试用例理论说得再多不如动手写一个。让我们以一个经典的场景——在某个模拟的待办事项Todo应用中添加和完成项目——来编写一个完整的测试用例。我们将使用TypeScript和Playwright Test运行器。4.1 测试场景设计与结构假设我们有一个简单的Todo应用有以下功能有一个文本输入框用于输入新的待办事项。有一个“Add”按钮点击后将输入的内容添加到下方的列表。列表中的每个项目前面有一个复选框点击可以标记为完成文本出现删除线。有一个“Clear completed”按钮点击后删除所有已完成的项。我们的测试用例将覆盖添加新的待办事项。验证事项被正确添加。标记一个事项为完成。验证完成状态。清理已完成的事项。验证清理后列表的正确性。4.2 测试代码实现详解首先在tests目录下创建文件todo.spec.ts。// 导入必要的模块 import { test, expect } from playwright/test; // 使用 test.describe 对相关测试进行分组使报告更清晰 test.describe(Todo App 端到端测试, () { // test.beforeEach 钩子每个测试用例执行前都会运行 // 这里我们导航到测试应用的URL test.beforeEach(async ({ page }) { // 在实际项目中这个URL应该配置在 playwright.config.ts 的 baseURL 中 // 这里我们使用一个在线的模拟Todo应用例如http://demo.playwright.dev/todomvc await page.goto(http://demo.playwright.dev/todomvc); // 等待页面核心输入框加载完成确保页面就绪 await page.getByPlaceholder(What needs to be done?).waitFor(); }); // 第一个测试添加单个待办事项 test(应该能成功添加一个新的待办事项, async ({ page }) { // 1. 定位输入框并输入文本 const inputBox page.getByPlaceholder(What needs to be done?); await inputBox.fill(学习Playwright自动化测试); await inputBox.press(Enter); // 按Enter键添加也可以点击旁边的Add按钮 // 2. 定位待办事项列表并断言新添加的项目存在且文本正确 const todoItems page.getByTestId(todo-item); // 假设每个事项都有>npx playwright test todo.spec.ts或者使用UI模式进行更直观的调试npx playwright test todo.spec.ts --uiUI模式会打开一个窗口你可以看到所有测试用例点击即可运行单个测试并实时查看浏览器操作和结果。如果测试失败Playwright提供了强大的追踪Trace功能。在playwright.config.ts中你可以配置在测试失败时自动记录追踪信息import { defineConfig } from playwright/test; export default defineConfig({ use: { trace: on-first-retry, // 首次重试时记录trace也可设为 on始终记录或 retain-on-failure失败时保留 }, });追踪文件是一个ZIP包包含了测试执行时间轴中每一步的DOM快照、网络请求、控制台日志和截图。你可以使用命令npx playwright show-trace trace.zip来打开一个可视化查看器像调试器一样逐步回放测试过程精准定位问题所在。5. 高级特性与实战技巧掌握了基础之后我们来深入一些能极大提升测试效率和可靠性的高级特性。5.1 模拟网络与请求拦截现代Web应用大量依赖API。Playwright允许你模拟网络条件、拦截和修改HTTP请求这对于测试以下场景非常有用测试加载状态和错误处理模拟API响应慢或失败。屏蔽第三方资源屏蔽广告、分析脚本让测试更快更稳定。准备测试数据拦截对后端API的请求直接返回预设的模拟数据实现测试环境的隔离。示例拦截API请求并返回模拟数据import { test, expect } from playwright/test; test(拦截用户列表API并返回模拟数据, async ({ page }) { // 监听并拦截特定的网络请求 await page.route(**/api/users, async route { // 构造一个模拟的JSON响应 const mockResponse { users: [ { id: 1, name: Mocked Alice }, { id: 2, name: Mocked Bob } ] }; // 继续请求但返回我们模拟的响应 await route.fulfill({ status: 200, contentType: application/json, body: JSON.stringify(mockResponse), }); }); await page.goto(http://example.com/user-management); // 现在页面上显示的用户名应该是“Mocked Alice”和“Mocked Bob”而不是真实API返回的数据 await expect(page.getByText(Mocked Alice)).toBeVisible(); });5.2 文件上传与下载处理文件操作是自动化测试中的常见难点。Playwright使其变得简单。文件上传对于input typefile元素直接使用setInputFiles方法。// 单个文件 await page.getByLabel(上传文件).setInputFiles(/path/to/myfile.pdf); // 多个文件 await page.getByLabel(上传文件).setInputFiles([/path/to/file1.pdf, /path/to/file2.jpg]); // 清空已选文件 await page.getByLabel(上传文件).setInputFiles([]);文件下载等待下载并获取下载文件路径。// 1. 在点击下载按钮前先启动对下载事件的监听 const downloadPromise page.waitForEvent(download); await page.getByText(下载报告).click(); // 2. 等待下载事件发生 const download await downloadPromise; // 3. 获取下载文件的建议文件名和保存路径 const suggestedFilename download.suggestedFilename(); // 4. 将文件保存到指定路径 const savePath ./downloads/${suggestedFilename}; await download.saveAs(savePath); console.log(文件已下载至: ${savePath});5.3 跨域与多页面/多上下文操作处理新标签页/窗口// 在点击会打开新窗口的链接前监听‘popup’事件 const [newPage] await Promise.all([ page.context().waitForEvent(page), // 等待新页面事件 page.getByText(在新窗口打开).click(), // 触发打开新页面的操作 ]); await newPage.waitForLoadState(); // 等待新页面加载 // 现在可以在 newPage 上操作了 console.log(await newPage.title());多上下文模拟不同用户import { test } from playwright/test; test(模拟两个用户同时操作, async ({ browser }) { // 创建两个独立的浏览器上下文模拟两个用户会话 const userContext1 await browser.newContext(); const userContext2 await browser.newContext(); const page1 await userContext1.newPage(); const page2 await userContext2.newPage(); // 用户1登录 await page1.goto(/login); await page1.fill(#username, alice); await page1.fill(#password, password123); await page1.click(button[typesubmit]); // 用户2登录或保持未登录状态 await page2.goto(/); // 两个页面完全独立cookie、localStorage互不干扰 // 可以并行进行测试... });5.4 使用Fixture进行测试数据准备与复用Playwright Test支持Fixture这是一种强大的依赖注入机制可以让你在测试之间共享设置和拆卸代码。最常用的Fixture就是page和context但你也可以自定义。自定义Fixture示例登录状态在tests目录下创建或修改fixtures.ts文件import { test as baseTest } from playwright/test; // 定义一个自定义Fixture返回一个已登录的页面 export const test baseTest.extend{ loggedInPage: any }({ loggedInPage: async ({ browser }, use) { // 创建独立上下文和页面 const context await browser.newContext(); const page await context.newPage(); // 执行登录流程 await page.goto(/login); await page.fill(#username, testuser); await page.fill(#password, testpass); await page.click(button[typesubmit]); // 等待登录成功跳转例如导航到首页 await page.waitForURL(**/dashboard); // 将这个已登录的page提供给测试用例使用 await use(page); // 测试用例结束后清理关闭上下文 await context.close(); }, }); export { expect } from playwright/test;然后在测试文件中导入自定义的test// 注意从我们的fixtures文件导入而不是 playwright/test import { test, expect } from ./fixtures; test(使用已登录状态访问仪表盘, async ({ loggedInPage }) { // loggedInPage 已经是一个登录后的页面了 await expect(loggedInPage.getByText(欢迎回来testuser)).toBeVisible(); });这种方式将通用的准备逻辑如登录抽象出来让测试用例更简洁、更专注于业务逻辑。6. 配置、并行执行与持续集成一个成熟的测试套件离不开良好的工程化配置。6.1 深入理解playwright.config.ts配置文件是Playwright项目的控制中心。以下是一些关键配置项解析import { defineConfig, devices } from playwright/test; export default defineConfig({ // 1. 测试目录和匹配模式 testDir: ./tests, testMatch: **/*.spec.ts, // 匹配所有 .spec.ts 文件 // 2. 全局超时设置 timeout: 30 * 1000, // 每个测试用例的超时时间毫秒 expect: { timeout: 5000, // 每个断言的最大等待时间 }, // 3. 全局失败重试策略在CI中很有用 retries: process.env.CI ? 2 : 0, // 在CI环境中重试2次本地不重试 // 4. 全局测试隔离每个测试一个全新的上下文最安全 fullyParallel: true, // 尽可能并行运行测试 forbidOnly: !!process.env.CI, // 在CI环境中禁止使用 test.only // 5. 报告器配置 reporter: [ [html], // 生成漂亮的HTML报告 [list], // 在控制台输出简洁列表 [junit, { outputFile: test-results/junit.xml }] // 生成JUnit格式报告供CI系统集成 ], // 6. 全局使用选项适用于所有项目 use: { baseURL: https://my-app.staging.com, // 设置基础URLpage.goto(/path) 会拼接成完整URL trace: on-first-retry, // 追踪配置 screenshot: only-on-failure, // 仅在失败时截图 video: retain-on-failure, // 仅在失败时保留录像 // 模拟视口和设备 // viewport: { width: 1280, height: 720 }, // ignoreHTTPSErrors: true, // 忽略HTTPS证书错误用于测试环境 }, // 7. 多项目配置定义在不同浏览器/设备上运行的测试套件 projects: [ { name: chromium, use: { ...devices[Desktop Chrome] }, }, { name: firefox, use: { ...devices[Desktop Firefox] }, }, { name: webkit, use: { ...devices[Desktop Safari] }, }, // 模拟移动端 { name: Mobile Chrome, use: { ...devices[Pixel 5] }, }, ], });6.2 并行测试与分片执行Playwright Test默认会并行运行测试充分利用多核CPU。你可以在配置文件中通过workers选项控制并行工作进程的数量。export default defineConfig({ workers: process.env.CI ? 4 : undefined, // CI环境用4个worker本地根据CPU核心数自动决定 });对于超大型测试套件还可以使用分片Sharding将测试分配到多台机器上并行执行进一步缩短CI流水线时间。# 将测试分成3片当前机器执行第1片索引从0开始 npx playwright test --shard1/3在GitHub Actions等CI中你可以启动多个Job每个Job执行一个分片最后合并报告。6.3 集成到CI/CD流水线以GitHub Actions为例Playwright与CI/CD工具集成非常顺畅。使用npm init playwrightlatest时如果选择了安装GitHub Actions工作流会自动生成.github/workflows/playwright.yml文件。其核心内容如下name: Playwright Tests on: push: branches: [ main, master ] pull_request: branches: [ main, master ] jobs: test: timeout-minutes: 60 # 整体Job超时时间 runs-on: ubuntu-latest # 使用最新的Ubuntu运行器 steps: - uses: actions/checkoutv4 # 检出代码 - uses: actions/setup-nodev4 # 设置Node.js环境 with: node-version: 18 - name: Install dependencies run: npm ci # 使用ci命令安装依赖比npm install更快更稳定 - name: Install Playwright Browsers run: npx playwright install --with-deps chromium # 通常CI中只安装必要的浏览器如Chromium以加快速度 - name: Run Playwright tests run: npx playwright test # 运行所有测试 - uses: actions/upload-artifactv4 # 上传测试产物报告、追踪、截图等 if: always() # 即使测试失败也上传 with: name: playwright-report path: playwright-report/ retention-days: 30这个工作流会在每次推送到主分支或创建Pull Request时自动运行你的Playwright测试并将HTML报告作为产物上传方便查看失败详情。7. 常见问题排查与性能优化实战即使有了强大的工具在实际项目中还是会遇到各种问题。这里分享一些我踩过的坑和解决方案。7.1 元素定位失败原因与对策这是最常见的问题。除了使用更稳健的定位器getByRole,getByTestId外还需要系统化排查。排查清单时机问题元素真的在DOM中并可见了吗使用page.pause()或--debug模式暂停测试手动检查页面状态。确保在操作前有足够的等待通常Playwright的自动等待已足够但需确认页面是SPA还是传统页面。iframe你的元素在iframe里面吗如果是需要先切换到iframe上下文。const frame page.frame({ name: my-iframe }); // 通过name或URL定位iframe // 或者 page.frameLocator(iframe[titlexxx]) await frame.locator(button).click(); // 在frame内定位Shadow DOM元素在Shadow Root内部Playwright可以穿透Shadow DOM但定位器可能需要调整。使用或/deep/选择器已废弃标准但Playwright可能支持或者更好的方式是使用element.locator()从Shadow Host内部开始定位。动态内容元素是JavaScript动态生成的且其>await page.getByText(/订单 #\d/).click(); // 匹配“订单 #12345”页面有多个匹配项你的定位器匹配到了多个元素但操作如click()默认作用于第一个。使用first(),last(),nth(index)进行筛选或者使用filter()进行更精确的过滤。实操心得当定位器频繁失败时打开Playwright Inspector是最快的调试方式。运行测试时加上--debug标志或者使用PWDEBUG1环境变量它会启动一个带控件的浏览器并高亮显示定位器匹配的元素让你实时调整定位策略。7.2 测试不稳定Flaky Tests的终极处理即使有自动等待Flaky Tests也可能出现。处理思路如下启用追踪和录像这是最重要的工具。确保playwright.config.ts中配置了trace: on-first-retry和video: retain-on-failure。当测试失败时仔细分析追踪查看器看在哪一步出现了意外例如网络请求慢了0.5秒或者一个动画还没完全结束。审查等待策略对于单页应用SPApage.goto()可能只等待load事件而你的应用可能在那之后才通过API加载数据。在关键断言或操作前增加一个对特定页面状态的等待而不是通用的sleep。// 不好的做法 await page.waitForTimeout(2000); // 硬等待不稳定 // 好的做法 await page.waitForSelector(.data-loaded, { state: visible }); // 等待一个代表数据加载完成的元素 // 或者等待特定的网络请求完成 await page.waitForResponse(response response.url().includes(/api/data) response.ok());隔离测试数据确保每个测试用例使用独立的数据避免因数据残留导致的状态依赖。可以在beforeEach中清理数据库或使用API准备干净的数据。使用重试机制在CI配置中设置retries: 2让不稳定的测试有第二次机会。但这只是缓解根本原因仍需找到。降低并行度有时测试间存在隐性的资源竞争如共用测试账号、数据库行锁。尝试将workers设置为1如果问题消失说明是测试隔离不彻底。7.3 性能优化让测试跑得更快当测试套件增长到数百个时执行时间会成为瓶颈。并行执行确保fullyParallel: true并根据机器CPU核心数合理设置workers通常是CPU核心数。使用更快的浏览器在CI中如果不需要跨浏览器测试可以只安装和运行Chromium它通常是性能最好的。复用认证状态登录操作往往很耗时。可以使用browser.newContext()时传入storageState来复用之前保存的cookie和localStorage。// 在登录测试中保存状态 await page.context().storageState({ path: auth-state.json }); // 在其他测试中复用状态 const context await browser.newContext({ storageState: auth-state.json }); const page await context.newPage(); // page 现在已经是登录状态了拦截不必要的请求使用page.route()拦截并中止对图片、字体、分析脚本、广告等非必要资源的请求可以显著提升页面加载速度。await page.route(**/*.{png,jpg,jpeg,svg,gif,woff,woff2}, route route.abort()); // 或者更精细地只允许同域请求 await page.route(**/*, route { const url route.request().url(); if (!url.startsWith(https://my-app.com)) { route.abort(); } else { route.continue(); } });测试分片如前所述在CI中使用分片将测试分配到多台机器。7.4 与Selenium/Puppeteer/Pyppeteer的对比与选型这是搜索热词中常见的问题。简单总结一下vs Selenium: Playwright在稳定性、速度、现代API设计、调试工具上全面胜出。Selenium的WebDriver协议需要浏览器驱动中转通信开销大且自动等待机制需要手动实现。Playwright直接通过CDP等协议与浏览器通信更高效且设计理念更先进。除非你维护着一个庞大且稳定的Selenium遗产项目否则新项目强烈建议Playwright。vs Puppeteer: Puppeteer是Chrome团队开发的只支持Chromium。Playwright由原Puppeteer团队创建但支持多浏览器且测试运行器Playwright Test功能更强大断言、并行、追踪等。如果你只需要测试Chrome且对官方测试运行器需求不强Puppeteer也是一个好选择。但Playwright的跨浏览器支持和更丰富的功能集使其成为更通用的解决方案。vs Pyppeteer: Pyppeteer是Puppeteer的Python非官方端口已基本停止维护。Playwright的Python版本是官方维护的功能同步生态更好是Python生态中浏览器自动化的首选。选择Playwright你获得的是一个为现代Web测试而生的、功能全面、稳定可靠且持续活跃的框架。从零开始学习它无疑是构建未来几年自动化测试能力的一项高回报投资。