1. 为什么需要优化Playwright测试性能
最近在团队内部做了一次测试效率调研，发现平均每个UI自动化测试用例执行时间高达45秒。按200个用例计算，完整跑一遍需要两个半小时，严重影响了CI/CD流水线的效率。这促使我开始深入研究Playwright的性能优化方案。
Playwright作为新一代浏览器自动化工具，虽然本身执行速度已经比Selenium快很多，但在实际项目中仍然存在大量可优化的空间。经过两周的实测和数据分析，我总结出以下10个经过验证的优化技巧，将这些方法应用到我们的测试套件后，整体执行时间缩短了68%，效果非常显著。
2. 测试环境层面的优化技巧
2.1 选择正确的浏览器类型
Playwright支持Chromium、Firefox和WebKit三种浏览器引擎。在我们的对比测试中：
| 浏览器类型 | 平均启动时间(ms) | 平均页面加载时间(ms) |
|---|---|---|
| Chromium | 320 | 850 |
| Firefox | 410 | 920 |
| WebKit | 380 | 890 |
虽然差异看起来不大，但当测试用例数量达到数百个时，选择Chromium作为主要测试浏览器可以节省可观的执行时间。不过需要注意，如果项目要求多浏览器兼容性测试，这个优化就需要权衡。
实际项目中我们发现，Chromium的DevTools协议实现最为完善，Playwright对其优化也最好。对于不需要多浏览器验证的测试场景，建议统一使用Chromium。
2.2 合理配置浏览器启动参数
通过调整浏览器启动参数可以获得显著的性能提升：
const browser = await chromium.launch({ headless: true, // 必须使用无头模式 args: [ '--disable-gpu', '--no-sandbox', '--disable-setuid-sandbox', '--disable-dev-shm-usage', // 这个参数对Docker环境特别重要 '--disable-accelerated-2d-canvas', '--disable-software-rasterizer' ] });我们在AWS c5.large实例上测试发现，经过这些优化后，浏览器启动时间从平均520ms降低到了320ms。特别是--disable-dev-shm-usage参数，在Docker环境中避免了使用共享内存，防止了因/dev/shm空间不足导致的崩溃。
3. 测试用例设计层面的优化
3.1 实现智能等待而非固定sleep
最常见的性能浪费来自于不合理的等待时间。对比以下两种写法：
// 反例：固定等待 await page.click('#submit'); await page.waitForTimeout(3000); // 固定等待3秒 // 正例：条件等待 await page.click('#submit'); await page.waitForSelector('.success-message', { timeout: 5000 });在我们的测试中，使用条件等待平均每个操作节省了1.8秒的无效等待时间。对于包含20个步骤的测试用例，这意味着36秒的时间节省。
3.2 复用浏览器上下文而非创建新实例
Playwright的BrowserContext比启动新浏览器轻量得多：
// 反例：每个测试都启动新浏览器 beforeEach(async () => { browser = await chromium.launch(); page = await browser.newPage(); }); // 正例：复用浏览器上下文 let context; beforeAll(async () => { browser = await chromium.launch(); context = await browser.newContext(); }); beforeEach(async () => { page = await context.newPage(); });实测数据显示，使用BrowserContext复用策略后，测试套件的初始化时间从原来的12秒降低到了3秒。对于包含钩子函数的测试框架（如Jest、Mocha），这种优化效果尤为明显。
4. 网络层面的优化技巧
4.1 阻断不必要的资源加载
大多数测试不需要加载图片、样式表等资源：
await page.route('**/*', route => { const type = route.request().resourceType(); const blockResources = ['image', 'stylesheet', 'font', 'media']; if (blockResources.includes(type)) { route.abort(); } else { route.continue(); } });应用此优化后，页面加载时间从平均1.2秒降低到了0.6秒。特别是在测试电商网站时，由于减少了大量商品图片的加载，效果更加显著。
4.2 使用API Mock减少后端依赖
结合Playwright的路由拦截和Mock功能：
await page.route('**/api/products', route => { route.fulfill({ status: 200, contentType: 'application/json', body: JSON.stringify([{ id: 1, name: 'Mock Product' }]) }); });在我们的一个项目中，通过Mock关键的5个API接口，测试用例执行时间从8分钟缩短到了2分钟。这种方法特别适合在开发早期阶段，当后端API还不稳定时使用。
5. 测试执行策略的优化
5.1 并行化测试执行
Playwright Test runner原生支持并行执行：
// playwright.config.js module.exports = { workers: process.env.CI ? 4 : 2, // CI环境使用4个worker };在8核CPU的机器上，将workers设置为4后，200个测试用例的总执行时间从32分钟降低到了9分钟。需要注意的是，并行测试要求用例之间完全独立，不能有共享状态。
5.2 实现测试分片(Sharding)
对于超大型测试套件，可以使用分片技术：
npx playwright test --shard=1/3 npx playwright test --shard=2/3 npx playwright test --shard=3/3我们的端到端测试套件包含1200个测试，通过分片在3台CI机器上并行执行，总时间从原来的2小时降低到了45分钟。每台机器只需要执行400个测试。
6. 其他实用优化技巧
6.1 选择高效的选择器策略
选择器性能对比（测试100次执行平均时间）：
| 选择器类型 | 执行时间(ms) |
|---|---|
| text='Submit' | 420 |
| #submit-button | 120 |
| [data-testid="submit"] | 150 |
优先使用ID和data-testid属性选择器，比文本选择器快3-4倍。我们在重构选择器后，整体测试时间减少了15%。
6.2 优化测试数据准备
使用内置的storageState机制复用登录状态：
// 保存状态 await page.context().storageState({ path: 'auth.json' }); // 复用状态 const browser = await chromium.launch(); const context = await browser.newContext({ storageState: 'auth.json' });通过避免每次测试都执行登录流程，我们的测试套件节省了约8分钟的执行时间。这对于需要身份验证的测试场景特别有用。
6.3 定期清理无用测试
建立测试有效性评估机制：
- 标记6个月内未失败的测试为"低价值"
- 分析测试覆盖率和业务关键度的关联
- 移除重复测试和过度细粒度的测试
经过清理，我们移除了约30%的测试用例，而关键覆盖率只下降了2%，测试套件执行时间从50分钟降到了35分钟。
7. 性能监控与持续优化
建立测试性能监控仪表盘，跟踪以下指标：
- 单个测试用例平均执行时间
- 测试套件总执行时间趋势
- 最耗时的10个测试用例
- 浏览器启动时间分布
我们每周分析这些指标，发现某个测试用例的执行时间从2秒逐渐增加到了8秒，调查后发现是因为新增了不必要的截图操作。通过持续监控，可以及时发现性能退化问题。
