1. 项目概述为什么你需要一个精心配置的Playwright配置文件如果你刚开始接触Playwright可能会觉得写几个测试脚本用命令行跑起来就万事大吉了。但当你真正投入到项目里面对几十上百个测试用例需要在不同浏览器、不同环境本地开发、CI流水线下运行时你就会发现没有一份好的配置文件你的测试工作会变得一团糟。配置文件就像是你的自动化测试项目的“总指挥部”它决定了你的测试大军在哪里集结、用什么武器、以什么阵型发起进攻以及战后如何打扫战场、汇报战果。我见过不少团队测试脚本写得不错但因为配置混乱导致本地跑得好好的一上CI就各种失败或者测试报告乱七八糟出了问题根本没法快速定位。一份结构清晰、考虑周全的playwright.config.ts或.js文件能帮你省去大量重复劳动和调试时间。今天我就结合自己踩过的坑和最佳实践带你从零开始深入理解Playwright配置文件的每一个核心选项打造一份属于你自己的、高效可靠的测试配置。2. 配置文件的核心结构与初始化2.1 配置文件的创建与基础骨架Playwright的配置文件通常命名为playwright.config.tsTypeScript项目或playwright.config.jsJavaScript项目。官方推荐使用TypeScript因为它能提供更好的类型提示和错误检查。使用npx playwright init命令初始化项目时会自动生成一个基础的配置文件。我们先来看一个最精简但五脏俱全的配置骨架import { defineConfig, devices } from playwright/test; /** * 阅读 https://playwright.dev/docs/test-configuration 了解更多信息。 */ export default defineConfig({ // 测试文件所在的目录相对于此配置文件。 testDir: ./tests, // 每个测试的最大执行时间毫秒。 timeout: 30 * 1000, // 全局的expect断言超时时间毫秒。 expect: { timeout: 5000, }, // 在CI环境中如果源代码中意外留下了test.only则使构建失败。 forbidOnly: !!process.env.CI, // 仅在CI上重试失败的测试。 retries: process.env.CI ? 2 : 0, // 在CI上选择退出并行测试在本地开发时充分利用并行。 workers: process.env.CI ? 1 : undefined, // 使用的报告器例如‘html’报告器会生成一个漂亮的本地报告。 reporter: html, // 所有测试共享的配置。 use: { // 在类似 await page.goto(/) 的操作中使用的基础URL。 baseURL: http://localhost:3000, // 收集重试失败测试时的追踪信息。推荐在CI上开启以辅助调试。 trace: on-first-retry, // 为所有操作自动截图。仅在调试时开启否则会产生大量文件。 // screenshot: only-on-failure, }, // 为不同的浏览器或设备配置项目。 projects: [ { name: chromium, use: { ...devices[Desktop Chrome] }, }, { name: firefox, use: { ...devices[Desktop Firefox] }, }, { name: webkit, use: { ...devices[Desktop Safari] }, }, ], // 在开始测试前运行你的本地开发服务器。 webServer: { command: npm run start, url: http://localhost:3000, reuseExistingServer: !process.env.CI, }, });这个配置已经覆盖了80%的常见场景。defineConfig函数提供了完整的类型安全你在编辑器中就能获得智能提示。testDir定义了测试文件的根目录Playwright会递归地在这个目录下寻找匹配.*(test|spec).(js|ts|mjs)模式的文件。注意use部分配置的是测试运行时的上下文选项比如浏览器上下文和页面的默认行为。而像timeout、retries、workers这些是测试运行器本身的选项必须放在顶层不能放在use里面这是新手常犯的错误。2.2 环境变量与动态配置一个健壮的配置必须能区分本地开发和持续集成环境。上面配置中已经用到了process.env.CI。通常CI工具如GitHub Actions, Jenkins, GitLab CI会自动设置CItrue这个环境变量。你可以利用这个机制让配置动态适应不同环境import { defineConfig } from playwright/test; // 判断是否为CI环境 const isCI !!process.env.CI; // 判断是否为本地开发环境 const isLocalDev !isCI; export default defineConfig({ // CI环境下我们可能希望更严格禁止使用test.only forbidOnly: isCI, // CI环境下重试2次以提高稳定性本地快速失败以便调试 retries: isCI ? 2 : 0, // CI环境下可能资源有限只使用1个worker本地开发则根据CPU核心数并行 workers: isCI ? 1 : 50%, // ‘50%’ 表示使用一半的CPU核心 // CI环境下可能不需要打开UI界面使用‘dot’报告器更简洁 reporter: isCI ? [[dot], [html]] : html, use: { // CI环境下追踪信息始终开启本地仅在首次重试时开启 trace: isCI ? on : on-first-retry, // CI环境下可能连接的是测试服务器本地则是开发服务器 baseURL: process.env.BASE_URL || http://localhost:3000, }, });更进一步你可以创建.env文件来管理环境变量使用dotenv包在配置文件中加载# .env 文件 BASE_URLhttps://staging.example.com TEST_USERautomationexample.com TEST_PASSWORDsecurePassword123然后在配置文件中读取import { defineConfig } from playwright/test; import dotenv from dotenv; // 加载.env文件中的环境变量 dotenv.config(); export default defineConfig({ use: { baseURL: process.env.BASE_URL, // 你可以将环境变量传递给测试上下文 extraHTTPHeaders: { Authorization: Bearer ${process.env.API_TOKEN}, }, }, });在测试文件中你可以通过process.env或testInfo.config来访问这些变量。动态配置的核心思想是让配置适应环境而不是让环境去迁就写死的配置。3. 核心配置项深度解析3.1 测试发现与过滤精准控制测试范围随着测试套件增长你不可能每次都运行所有测试。Playwright提供了灵活的过滤机制。testMatch与testIgnore: 这两个选项使用glob模式或正则表达式来控制哪些文件被包含或排除。export default defineConfig({ // 匹配所有以.spec.ts或.test.ts结尾的文件但排除node_modules和dist目录 testMatch: **/*.{spec,test}.{js,ts}, // 忽略特定目录或文件 testIgnore: [ **/node_modules/**, **/dist/**, **/test-assets/**, // 忽略存放测试资源的目录 **/*.visual.spec.ts, // 忽略视觉回归测试单独运行 ], });更强大的方式是通过命令行参数动态过滤npx playwright test login运行所有标题或文件路径中包含“login”的测试。npx playwright test --grep “smoke”使用test(‘title smoke’, …)中的标签来过滤。npx playwright test tests/checkout-flow.spec.ts运行特定文件。你可以在配置中预设一些“项目”来分组测试export default defineConfig({ projects: [ { name: smoke, testMatch: /.*smoke.*/, // 运行所有包含‘smoke’的测试文件 use: { ...devices[Desktop Chrome] }, }, { name: api, testMatch: **/api/*.spec.ts, // 运行api目录下的所有测试 use: { baseURL: process.env.API_BASE_URL }, }, { name: e2e-chrome, testMatch: **/*.spec.ts, testIgnore: /.*api.*/, // 忽略api测试 use: { ...devices[Desktop Chrome] }, }, ], });实操心得我习惯在关键的端到端测试上打上critical标签在CI流水线中配置一个独立的“关键路径测试”任务只运行这些测试确保核心功能永远优先通过。这比单纯按目录划分更灵活。3.2 并行化与工作进程配置最大化测试效率并行化是缩短测试反馈周期的关键。workers选项控制并行进程数。export default defineConfig({ // 方案一固定数字。适用于对资源需求有明确认知的环境。 // workers: 4, // 方案二根据CPU核心数动态设置。最常用能充分利用本地机器性能。 workers: process.env.CI ? 2 : 50%, // CI用2个本地用一半核心数 // 方案三设置为1则完全禁用并行用于调试或资源敏感型测试。 // workers: 1, // 完全并行模式一个文件内的所有测试也会并行执行。 fullyParallel: true, });fullyParallel: true是一个强大的选项。默认情况下Playwright会并行运行不同的测试文件但单个文件内的测试是按顺序执行的。开启此选项后文件内的测试也会并行化。这能极大提升速度但要求你的测试必须是完全独立的不能有状态共享或执行顺序依赖。注意事项并行测试的稳定性挑战。当测试并行运行时它们可能竞争共享资源如数据库的同一行记录、文件系统的同一个目录或者同一个用户账号。这会导致偶发性失败。解决方法包括测试隔离每个测试使用独立的数据。可以通过在测试前置钩子中生成随机用户ID、订单号来实现。使用事务对于数据库操作确保每个测试在独立的事务中运行并在测试后回滚。资源池对于有限的资源如测试账号实现一个简单的资源池管理机制。关闭并行对于确实无法并行的测试套件可以将其放入一个单独的project并为该项目设置workers: 1。3.3 超时与重试策略平衡稳定性与反馈速度超时和重试是处理“闪烁测试”的利器。export default defineConfig({ // 全局测试超时单个测试用例包括beforeEach/afterEach的总执行时间上限。 timeout: 30 * 1000, // 30秒 // 全局expect断言超时等待某个条件成立的最长时间。 expect: { timeout: 10 * 1000, // 10秒 // 截图对比的容差配置 toHaveScreenshot: { maxDiffPixels: 100, // 允许最多100个像素不同 }, toMatchSnapshot: { maxDiffPixelRatio: 0.01, // 允许1%的像素差异 }, }, // 重试策略仅在CI环境下重试本地快速失败。 retries: process.env.CI ? 2 : 0, });超时设置的层次结构 Playwright的超时设置是有层次的更具体的设置会覆盖更通用的设置。全局超时(config.timeout)默认30秒。项目级超时(project.timeout)可以为特定浏览器项目设置不同超时。测试级超时(test.setTimeout(timeout))在测试函数内设置优先级最高。断言超时(config.expect.timeout)专门用于expect语句的等待默认5秒。重试的哲学 重试不是为了掩盖bug而是为了应对不稳定的测试环境如网络瞬时波动、第三方服务偶尔超时。在CI中设置retries: 2意味着一个失败的测试会再运行最多两次。如果重试后通过测试结果会被标记为“通过重试后”这能有效减少因环境问题导致的CI红屏。踩坑记录不要滥用重试。如果一个测试因为真实的代码缺陷而失败重试只会延迟问题的发现。我建议将重试与详细的trace记录结合。在配置中设置trace: ‘on-first-retry’或‘on’这样当测试失败时你可以获得一个包含完整操作、网络请求和console日志的追踪文件用于精准定位是环境问题还是代码问题。3.4 报告器配置让测试结果一目了然测试报告是沟通测试状态的核心工具。Playwright支持多种报告器并可同时使用多个。export default defineConfig({ reporter: [ // 1. List报告器在控制台输出简洁的进度列表适合CI日志。 [list], // 2. HTML报告器生成交互式HTML报告非常适合本地调试和结果分享。 [html, { outputFolder: playwright-report, // 报告输出目录 open: never // 不要自动打开浏览器。在CI中设为‘never’本地可设为‘on-failure’ }], // 3. JUnit报告器生成XML格式报告便于集成到Jenkins等CI系统中展示趋势图。 [junit, { outputFile: test-results/junit.xml }], // 4. GitHub Actions专用的注释报告器直接在PR中显示结果摘要。 process.env.GITHUB_ACTIONS ? [github] : [], // 5. 自定义报告器 [./my-custom-reporter.ts], ], });HTML报告深度使用 生成的HTML报告不仅展示通过/失败还包含时间线精确显示每个测试步骤的耗时。追踪查看器如果配置了trace可以直接在报告中回放测试操作查看每一步的截图、网络请求和Console日志。这是调试失败测试的神器。测试源文件点击测试名可以直接跳转到源代码。过滤与搜索可以按状态、标签、项目进行过滤。为了生成更清晰的报告建议配置outputDir来统一管理所有测试产物export default defineConfig({ // 所有测试产物截图、视频、追踪文件、报告都放在这个目录下 outputDir: test-results/, // 在use中配置截图和视频策略 use: { // 仅在测试失败时截图和录像节省空间 screenshot: only-on-failure, video: retain-on-failure, // 追踪文件也输出到同一目录下 trace: retain-on-failure, }, });这样test-results/目录结构会非常清晰便于归档或在CI中作为制品上传。4. 多项目与复杂环境配置实战4.1 为不同浏览器和设备配置项目projects是Playwright配置中最强大的功能之一它允许你定义多套测试环境。import { defineConfig, devices } from playwright/test; export default defineConfig({ projects: [ // 项目1桌面端Chrome的“烟雾测试” { name: smoke-chrome, testMatch: **/*.smoke.spec.ts, // 只运行烟雾测试 use: { ...devices[Desktop Chrome], viewport: { width: 1920, height: 1080 }, // 可以覆盖全局的use配置 baseURL: https://staging.example.com, // 模拟慢速网络测试加载性能 contextOptions: { permissions: [geolocation], // 授予地理位置权限 }, }, }, // 项目2桌面端Firefox的完整测试套件 { name: firefox, testMatch: **/*.spec.ts, testIgnore: **/*.mobile.spec.ts, // 忽略移动端测试 use: { ...devices[Desktop Firefox] }, }, // 项目3移动端SafariiOS模拟 { name: mobile-safari, testMatch: **/*.mobile.spec.ts, use: { ...devices[iPhone 14], // 可以进一步定制设备属性 isMobile: true, hasTouch: true, defaultBrowserType: webkit, }, }, // 项目4API测试无头浏览器专注于接口 { name: api-tests, testMatch: **/api/**, use: { baseURL: process.env.API_BASE_URL, // 对于纯API测试可以设置一个极简的浏览器上下文 bypassCSP: true, // 绕过内容安全策略 javaScriptEnabled: false, // 甚至禁用JS以提升速度 }, }, ], });运行测试时你可以选择运行特定项目npx playwright test --projectfirefox只运行Firefox项目。npx playwright test --projectsmoke-chrome --projectmobile-safari运行多个项目。如果不指定则运行所有项目。4.2 全局启动与清理钩子globalSetup和globalTeardown用于在所有测试开始前和结束后执行一次性操作非常适合做资源准备和清理。典型场景启动一个共享的测试数据库或Docker容器。进行用户认证并获取令牌供所有测试用例使用。清理旧的测试报告或临时文件。// playwright.config.ts export default defineConfig({ globalSetup: require.resolve(./global-setup), globalTeardown: require.resolve(./global-teardown), }); // global-setup.ts import { FullConfig } from playwright/test; import { startTestServer, createTestDatabase } from ./test-utils; async function globalSetup(config: FullConfig) { console.log(开始全局设置...); // 1. 启动一个用于所有测试的本地开发服务器如果webServer配置不够灵活 const serverProcess await startTestServer(); // 2. 创建测试数据库并运行迁移 await createTestDatabase(); // 3. 执行用户登录获取认证令牌并存储到环境变量中 const authToken await performGlobalLogin(); process.env.AUTH_TOKEN authToken; // 4. 将需要传递给测试的全局状态返回 return { authToken, serverProcessPid: serverProcess.pid, }; } export default globalSetup; // global-teardown.ts import { FullConfig } from playwright/test; import { stopTestServer, cleanupDatabase } from ./test-utils; async function globalTeardown(config: FullConfig) { console.log(开始全局清理...); // 1. 停止测试服务器 await stopTestServer(); // 2. 清理测试数据库 await cleanupDatabase(); // 3. 删除临时文件 // ... } export default globalTeardown;globalSetup返回的对象会被序列化并传递给每个工作进程你可以通过testInfo.config.globalSetupData在测试中访问这些数据。4.3 配置Web服务器与依赖服务webServer配置项允许你在测试运行前自动启动一个或多个本地服务器。export default defineConfig({ webServer: [ // 主前端应用服务器 { command: npm run start, // 启动命令 url: http://localhost:3000, // 用于检测服务是否就绪的URL timeout: 120 * 1000, // 启动超时时间2分钟 reuseExistingServer: !process.env.CI, // 本地开发时复用已有服务器 stdout: pipe, // 将服务器日志输出到管道便于调试 stderr: pipe, env: { // 传递给子进程的环境变量 NODE_ENV: test, PORT: 3000, }, }, // 模拟的后端API服务器 { command: npm run start:mock-api, url: http://localhost:3001/api/health, timeout: 30 * 1000, reuseExistingServer: !process.env.CI, }, ], });关键参数解析reuseExistingServer这个选项非常实用。在本地开发时你可能已经手动启动了开发服务器。设置为true或非CI环境时Playwright会检查端口是否已被占用如果已有服务器在运行则不会启动新进程避免端口冲突。在CI环境中我们通常希望每次都是全新的环境所以设置为false。stdout: ‘pipe’和stderr: ‘pipe’这会将服务器的控制台输出捕获到Playwright的日志中。当测试因服务器启动失败而报错时你能在Playwright的输出中看到具体的服务器错误信息极大方便了调试。健康检查URLurl选项不仅用于拼接baseURL更重要的是作为健康检查的端点。Playwright会持续轮询这个URL直到收到2xx或3xx状态码才认为服务器已就绪然后才开始运行测试。确保你提供一个轻量级、稳定的健康检查端点。5. 高级配置技巧与最佳实践5.1 使用TypeScript与路径别名对于TypeScript项目合理的配置能提升开发体验。// playwright.config.ts import { defineConfig } from playwright/test; import path from path; export default defineConfig({ // 告诉Playwright测试文件是TypeScript // 如果你的测试文件是.ts这个配置不是必须的但显式声明更清晰 // Playwright test runner 内部会处理TS编译 // 配置全局的测试夹具或工具函数的路径别名 // 这需要在tsconfig.json中也配置相应的paths // 但Playwright运行测试时可能需要通过Babel或ts-node插件来解析别名 // 一种更简单的方式是使用require.resolve globalSetup: require.resolve(./global-setup), // 如果你的测试工具函数放在特定目录可以这样引用 // 假设有一个测试工具模块在 test-utils/index.ts // 在测试文件中你可以通过相对路径或配置的别名导入 }); // 对应的 tsconfig.json 片段 { compilerOptions: { baseUrl: ., paths: { test-utils/*: [./test-utils/*], fixtures/*: [./test-fixtures/*] } } }为了让Playwright的测试运行器能正确解析TypeScript的路径别名你可能需要在项目根目录创建一个playwright.babelrc或playwright.tsconfig.json文件或者使用playwright/test自带的加载器它通常能很好地与项目的tsconfig.json协同工作。5.2 环境隔离与测试数据管理测试配置的核心目标之一是实现环境隔离。我推荐使用“配置即代码”的方式将不同环境开发、预发布、生产的配置完全分离。// playwright.config.base.ts - 基础共享配置 import { defineConfig, PlaywrightTestConfig } from playwright/test; const baseConfig: PlaywrightTestConfig { testDir: ./tests, timeout: 30000, expect: { timeout: 10000 }, forbidOnly: !!process.env.CI, retries: process.env.CI ? 2 : 0, reporter: [[list], [html, { open: never }]], use: { trace: on-first-retry, screenshot: only-on-failure, video: retain-on-failure, }, }; export default baseConfig; // playwright.config.staging.ts - 预发布环境配置 import { defineConfig, mergeConfig } from playwright/test; import baseConfig from ./playwright.config.base; const stagingConfig mergeConfig(baseConfig, { use: { baseURL: https://staging.example.com, // 预发布环境可能需要不同的认证头 extraHTTPHeaders: { X-Environment: staging, }, }, webServer: undefined, // 预发布环境不需要启动本地服务器 }); export default defineConfig(stagingConfig); // playwright.config.local.ts - 本地开发环境配置 import { defineConfig, mergeConfig } from playwright/test; import baseConfig from ./playwright.config.base; const localConfig mergeConfig(baseConfig, { use: { baseURL: http://localhost:3000, }, webServer: { command: npm run dev, url: http://localhost:3000, reuseExistingServer: true, }, // 本地可以开启更多worker和UI模式 workers: 50%, }); export default defineConfig(localConfig);然后在package.json中创建不同的脚本命令{ scripts: { test: playwright test, // 默认使用playwright.config.ts test:local: playwright test --configplaywright.config.local.ts, test:staging: BASE_URLhttps://staging.example.com playwright test --configplaywright.config.staging.ts, test:ci: CItrue playwright test --configplaywright.config.ci.ts } }测试数据管理 配置文件也可以与测试数据策略结合。例如通过环境变量指定测试数据的“种子”或“版本”// 在globalSetup中 async function globalSetup() { const dataSeed process.env.TEST_DATA_SEED || default; await seedTestDatabase(dataSeed); process.env.TEST_DATA_VERSION await getCurrentDataVersion(); }在测试中你可以根据这个版本号来断言数据的正确性或者在不同的测试运行中使用不同的隔离数据集。5.3 性能与稳定性调优大型测试套件对配置的稳定性要求很高。1. 资源限制与清理export default defineConfig({ // 限制每个测试用例使用的资源 use: { // 设置视口大小避免因分辨率不同导致布局问题 viewport: { width: 1280, height: 720 }, // 忽略HTTPS错误常用于测试环境使用自签名证书 ignoreHTTPSErrors: true, // 设置较长的导航超时应对慢速环境 navigationTimeout: 60 * 1000, // 设置动作如click, fill的超时 actionTimeout: 30 * 1000, }, // 配置全局的测试上下文确保资源释放 // 可以通过fixture或beforeEach/afterEach实现更细粒度的控制 });2. 并行化下的稳定性增强// 使用testInfo.parallelIndex实现测试间的隔离 // 在测试文件中 import { test, expect } from playwright/test; test(isolated test, async ({ page }, testInfo) { // 使用parallelIndex生成唯一标识避免数据冲突 const uniqueUser user_${testInfo.parallelIndex}_${Date.now()}test.com; await page.goto(/signup?testId${testInfo.parallelIndex}); // ... 使用uniqueUser进行测试 });3. 智能等待与超时策略 不要盲目增加全局超时。更好的方法是结合Playwright的自动等待机制和自定义等待逻辑。// 在配置中设置合理的expect超时 expect: { timeout: 10000, }, // 在测试中对特定缓慢操作使用自定义等待 await page.waitForLoadState(networkidle); // 等待网络空闲 await page.waitForFunction(() document.readyState complete); // 等待页面完全加载 // 或者使用locator的等待方法它集成了自动等待 await page.locator(button.submit).click(); await expect(page.locator(.success-message)).toBeVisible({ timeout: 15000 }); // 针对特定元素设置更长超时6. 常见问题排查与调试配置6.1 测试失败时的诊断信息收集当测试在CI中失败时最痛苦的是缺乏现场信息。以下配置能帮你收集丰富的诊断数据export default defineConfig({ // 输出目录集中管理 outputDir: test-results/, use: { // 追踪配置失败时保留首次重试时也记录便于分析间歇性失败 trace: retain-on-failure, // 或 on 以始终记录会占用更多磁盘空间 // 截图配置仅在失败时截图 screenshot: only-on-failure, // 视频录制配置仅在失败时保留视频 video: retain-on-failure, // 额外收集浏览器控制台日志和网络请求 // 这些信息会整合到追踪文件中 launchOptions: { // 如果浏览器崩溃输出更详细的日志 args: [--enable-logging, --v1], }, }, // 配置一个自定义的报告器在测试失败时输出额外上下文 reporter: [ [list], [html, { outputFolder: playwright-report, open: never }], // 自定义报告器示例将失败测试的上下文信息输出到文件 [./reporter/failure-context-reporter.ts], ], });追踪文件的使用 运行测试时如果配置了trace: ‘on-first-retry’或‘on’会在test-results/目录下生成.zip格式的追踪文件。使用以下命令查看npx playwright show-trace test-results/trace-file.zip追踪查看器会以时间线的形式展示所有操作、网络请求、Console日志和快照你可以一步步回放测试过程是定位异步问题、网络问题或渲染问题的终极工具。6.2 配置问题自查清单当你遇到配置相关的问题时可以按以下清单排查测试找不到检查testDir路径是否正确相对于配置文件。检查testMatch和testIgnore模式是否意外排除了你的测试文件。运行npx playwright test --list查看Playwright发现了哪些测试。浏览器无法启动运行npx playwright install确保浏览器已安装。检查是否有其他进程占用了浏览器端口。在CI环境中确保已安装必要的系统依赖如libgbm、libnss3等。测试在CI上慢或超时检查CI机器的资源CPU、内存是否充足。调整workers数量在CI上可能不宜设置过高。检查webServer的启动超时timeout是否足够。确认baseURL在CI环境中可达网络没有限制。并行测试随机失败检查测试是否完全独立没有共享状态。为可能冲突的资源如测试用户、文件添加唯一标识使用testInfo.parallelIndex或Date.now()。考虑对某些脆弱的测试套件设置workers: 1。HTML报告没有生成或内容不全检查outputDir目录的写入权限。确认reporter配置中包含了‘html’。如果测试被中断报告可能不完整。确保测试正常结束。环境变量不生效确认环境变量在运行Playwright命令的shell中已正确设置。在配置文件中使用console.log(process.env.YOUR_VAR)进行调试。注意CI环境如GitHub Actions中设置环境变量的方式。6.3 调试专用配置模板创建一个专门用于本地调试的配置文件会非常高效// playwright.config.debug.ts import { defineConfig } from playwright/test; import baseConfig from ./playwright.config.base; export default defineConfig({ ...baseConfig, // 禁用并行和重试让测试顺序执行便于观察 workers: 1, retries: 0, // 超时设置长一些方便下断点调试 timeout: 120 * 1000, expect: { timeout: 30 * 1000, }, // 始终开启追踪、截图和视频即使测试通过 use: { ...baseConfig.use, trace: on, screenshot: on, video: on, // 关闭无头模式看到浏览器界面 headless: false, // 减慢操作速度观察执行过程 launchOptions: { slowMo: 500, }, }, // 使用更详细的报告器 reporter: [[list], [html, { open: always }], [line]], // 只运行当前正在调试的测试文件 // testMatch: [**/debug-me.spec.ts], });使用npx playwright test --configplaywright.config.debug.ts来运行这个配置。headless: false和slowMo能让你亲眼看到浏览器的每一步操作是调试交互逻辑的利器。一份好的Playwright配置文件不是一蹴而就的它随着你的项目、测试套件和团队经验一起成长。从基础配置开始遇到问题解决问题然后将解决方案沉淀到配置中。记住配置文件的最终目标是让测试更可靠、更快速、更易于维护而不是增加复杂性。当你发现自己在重复进行某些手动设置或调试步骤时就应该考虑能否通过配置将其自动化。