一、问题的由来：为什么需要资源管理？
在编写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();
}
}
}
}
## 五、性能对比数据
在项目中实施复用策略后，我们得到了明显的改进：
## 六、复用还是不复用？
决策指南在实际项目中，我通常会根据以下因素做决策：
### 适合复用的场景：
- 同一用户的连续操作流程测试
- 需要保持登录状态的测试组
- 性能测试和负载测试
- 本地开发环境的快速反馈测试
### 需要谨慎或避免复用的场景：
- 权限和角色验证测试
- 清除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分钟。这个过程中最深的体会是：技术方案需要服务于实际需求，而不是盲目追求复用率。每个项目都需要找到适合自己的平衡点。