一、问题的由来：为什么需要资源管理？
在编写Playwright自动化测试脚本时，许多开发者都曾遇到过这样的场景：每个测试用例都启动一个全新的浏览器实例，执行登录操作，完成测试后再关闭浏览器。当测试用例数量增加时，这种模式的问题就会凸显出来：
- 测试执行时间越来越长
- 系统资源消耗急剧增加
- 测试稳定性因频繁的浏览器启动而下降
最近在调试一个电商项目的测试套件时，我发现了这个问题——原本30分钟的测试现在需要运行近2小时。通过性能分析发现，超过60%的时间都花在了浏览器的启动、初始化和销毁上。
二、理解浏览器上下文：不只是标签页那么简单
在深入复用策略之前，我们需要先理解Playwright中的两个核心概念：
浏览器上下文（Browser Context）
浏览器上下文是一个独立的会话环境，可以把它想象成一个独立的浏览器配置文件。每个上下文都有独立的：
- Cookie和本地存储
- 缓存数据
- 权限设置（如地理位置、通知权限）
// 创建独立的浏览器上下文 const context = await browser.newContext({ viewport: { width: 1280, height: 720 }, userAgent: '测试专用UA' });
页面（Page）
页面是上下文中的标签页，一个上下文可以包含多个页面：
// 在上下文中创建多个页面 const page1 = await context.newPage(); const page2 = await context.newPage();
三、复用策略实践：从简单到复杂
策略一：测试套件级别的上下文复用
对于相关性强的测试组，可以共享同一个浏览器上下文：
describe('用户账户相关测试', () => { let context; let page; beforeAll(async () => { // 整个测试套件共享一个上下文 context = await browser.newContext(); page = await context.newPage(); await page.goto('https://example.com/login'); await performLogin(page); // 执行一次登录 }); afterAll(async () => { await context.close(); }); test('查看个人资料', async () => { // 直接使用已登录状态的页面 await page.click('#profile-link'); // ... 验证逻辑 }); test('修改账户设置', async () => { // 复用同一个页面，无需重新登录 await page.click('#settings-link'); // ... 测试逻辑 }); });
策略二：页面池模式
当需要并行执行测试时，可以预先创建一组页面：
class PagePool { constructor(context, size = 3) { this.context = context; this.pool = []; this.size = size; this.available = []; } async initialize() { for (let i = 0; i < this.size; i++) { const page = awaitthis.context.newPage(); this.pool.push(page); this.available.push(page); } } async acquire() { if (this.available.length === 0) { // 可以等待或创建新页面 const page = awaitthis.context.newPage(); this.pool.push(page); return page; } returnthis.available.pop(); } release(page) { // 重置页面状态（根据需求决定是否清理） page.goto('about:blank'); this.available.push(page); } }
策略三：状态快照与恢复
对于需要干净状态但又要避免重复登录的场景：
async function createLoggedInContext(browser) { const context = await browser.newContext(); const page = await context.newPage(); // 执行登录 await page.goto(loginUrl); await page.fill('#username', 'testuser'); await page.fill('#password', 'password'); await page.click('#login-btn'); // 等待登录完成 await page.waitForSelector('#user-menu'); // 存储上下文状态 await context.storageState({ path: 'auth-state.json' }); await context.close(); return'auth-state.json'; } // 在其他测试中复用登录状态 const context = await browser.newContext({ storageState: 'auth-state.json' });
四、实战中的注意事项
1. 状态隔离问题
复用页面时最容易遇到的就是状态污染。上周我就踩过一个坑：测试A在购物车添加了商品，测试B运行时购物车已非空状态。
解决方案：
beforeEach(async () => { // 每个测试前清理特定状态 await page.evaluate(() => { localStorage.removeItem('shoppingCart'); sessionStorage.clear(); }); // 或者导航到中性页面 await page.goto('about:blank'); });
2. 并行测试的处理
使用上下文和页面复用时要特别注意并行测试的冲突：
// 为每个并行工作进程创建独立上下文 test.describe.configure({ mode: 'parallel' }); test.describe('并行测试套件', () => { test.beforeEach(async ({ browser }) => { // Playwright Test 会自动为每个并行测试提供隔离的上下文 }); });
3. 内存泄漏预防
长时间运行的测试套件需要注意内存管理：
// 定期清理不再使用的页面 async function cleanupOldPages(context, maxPages = 10) { const pages = context.pages(); if (pages.length > maxPages) { const oldPages = pages.slice(0, pages.length - maxPages); for (const oldPage of oldPages) { if (!oldPage.isClosed()) { await oldPage.close(); } } } }
五、性能对比数据
在项目中实施复用策略后，我们得到了明显的改进：
| 场景 | 执行时间（复用前） | 执行时间（复用后） | 内存使用减少 |
| 100个UI测试 | 42分钟 | 18分钟 | 约65% |
| 登录相关测试 | 8分钟 | 1.5分钟 | 约80% |
六、复用还是不复用？决策指南
在实际项目中，我通常会根据以下因素做决策：
适合复用的场景：
- 同一用户的连续操作流程测试
- 需要保持登录状态的测试组
- 性能测试和负载测试
- 本地开发环境的快速反馈测试
需要谨慎或避免复用的场景：
- 权限和角色验证测试
- 清除Cookie和本地存储的测试
- 浏览器扩展功能测试
- 可能产生冲突的并行测试
七、最佳实践建议
- 分层复用策略：在项目级别使用登录状态复用，在测试类级别使用上下文复用，在测试方法级别保持独立性。
- 清晰的命名和文档：
// 不好的做法 const context1 = await browser.newContext(); // 好的做法 const adminUserContext = await browser.newContext({ storageState: 'admin-auth.json' }); const customerContext = await browser.newContext({ storageState: 'customer-auth.json' });
- 实现智能清理：
// 创建可自动清理的上下文包装器 asyncfunction createManagedContext(browser, options) { const context = await browser.newContext(options); const originalNewPage = context.newPage; const pages = []; context.newPage = asyncfunction(...args) { const page = await originalNewPage.apply(this, args); pages.push(page); // 设置自动清理 page.on('close', () => { const index = pages.indexOf(page); if (index > -1) pages.splice(index, 1); }); return page; }; context.cleanup = asyncfunction() { for (const page of pages) { if (!page.isClosed()) await page.close(); } awaitthis.close(); }; return context; }
结语
浏览器上下文和页面复用不是银弹，而是一种需要在项目中进行权衡的技术选择。在我的经验中，适度的复用——特别是在资源密集型的测试场景中——往往能带来显著的效率提升。
关键是要建立清晰的复用策略和隔离机制，确保测试的独立性和可维护性。毕竟，测试的最终目的是提供快速、可靠的反馈，而不是成为开发流程中的瓶颈。
最近在重构测试框架时，我们团队通过合理的复用策略将CI/CD流水线的执行时间从45分钟缩短到了15分钟。这个过程中最深的体会是：技术方案需要服务于实际需求，而不是盲目追求复用率。每个项目都需要找到适合自己的平衡点。
