Playwright批量执行测试失败但单独运行正常的排查求助

一、先盯紧Fixtures的隔离性 #

• 检查自定义fixtures的作用域：如果你的fixture用了{ scope: 'worker' }或{ scope: 'project' }，会被多个测试复用，一旦某个测试修改了fixture内的状态（比如数据库连接、全局变量），后续测试就会踩坑。临时改成{ scope: 'test' }强制每个测试重新初始化，看问题是否消失。
• 验证teardown逻辑：确认fixture的清理操作（比如关闭页面、断开API连接、删除测试文件）在每个测试结束后都执行了。可以在teardown里加日志，比如console.log('Fixture teardown completed for test:', test.info().title)，批量跑时核对日志是否每个测试都有对应的清理记录。
• 排查fixture依赖顺序：如果多个fixture存在依赖关系，批量执行时的初始化顺序可能和单测不同，导致某个依赖未就绪就被调用。可以给fixture的关键步骤加日志，跟踪初始化顺序。

二、排查测试间的状态污染 #

• 先禁用并行：跑npx playwright test --workers=1，如果批量跑正常了，说明是并行测试之间的资源竞争（比如端口占用、数据库锁、本地文件读写冲突）。后续再针对性解决并行的资源隔离问题。
• 检查全局状态修改：测试中如果修改了process.env、浏览器全局对象（如window），单测时这些状态会被上下文重置，但批量跑时如果复用了上下文/worker，就会残留状态。确保这类修改只在当前测试内生效，或者在测试结束后恢复。
• 确认浏览器上下文隔离：Playwright默认每个测试用独立上下文，但如果手动复用了上下文（比如use({ context: existingContext })），会导致测试间共享Cookie、LocalStorage等状态，直接改成每个测试创建新上下文试试。

三、用日志精准定位问题 #

• 给失败测试加关键日志：在fixture初始化、API请求、元素操作等步骤前后加日志，比如console.log('当前测试:', test.info().title, '执行到步骤XX')，批量跑时对比单测的日志，找差异点。
• 开启Playwright调试日志：跑DEBUG=playwright:* npx playwright test，查看底层的浏览器启动、上下文创建、网络请求细节，找批量执行时的异常（比如某个请求超时、上下文创建失败）。
• 保存失败测试的Trace：在playwright.config.ts里配置use: { trace: 'retain-on-failure' }，批量跑失败后，用npx playwright show-trace trace.zip回放整个失败过程，对比单测的执行路径，看哪里出现了偏差。

四、其他常见排查方向 #

• 锁定触发失败的测试组合：用test.skip()逐个跳过测试，找到哪几个测试一起跑会失败，再分析它们的交互点（比如是否修改了同一份测试数据、占用了同一个资源）。
• 调整超时时间：批量跑时系统资源占用高，可能导致页面加载、API请求超时，单测时资源充足所以没问题。临时给失败测试加test.setTimeout(60000)，看是否能通过。
• 核对依赖版本：确认Playwright、数据库客户端等依赖的版本是否稳定，有时候批量执行时的依赖加载逻辑和单测不同，可能触发版本兼容问题。

内容的提问来源于stack exchange，提问作者Richard Lee