1. 为什么选择PlayWright构建测试脚手架第一次接触PlayWright是在去年重构公司电商平台的测试体系时。当时我们还在用SeleniumTestNG的老架构每次版本迭代都要花大量时间维护脆弱的定位脚本。直到偶然发现微软开源的PlayWright其跨浏览器支持、自动等待机制和丰富的调试工具让我眼前一亮。相比传统方案PlayWright有三个杀手级特性特别适合企业级测试多语言支持我们团队有Java和Python背景的测试工程师PlayWright的跨语言API让技术栈不再成为协作障碍可靠的选择器内置的text、css等定位策略比XPath稳定得多配合自动等待彻底告别了sleep噩梦全栈调试录制工具和GUI调试器大幅降低了编写和维护成本实测下来新同学上手PlayWright的平均时间比Selenium缩短了60%而脚本稳定性提升了近3倍。特别是在处理SPA应用时其内置的auto-wait机制让异步加载不再是痛点。2. 脚手架基础工程搭建2.1 初始化项目结构先来看一个经过多个项目验证的目录结构模板e2e/ ├── config/ # 环境配置 │ ├── dev.json │ └── prod.json ├── fixtures/ # 测试夹具 │ └── auth.json ├── pages/ # 页面对象 │ └── login.page.js ├── tests/ # 测试用例 │ └── login.spec.js ├── utils/ # 工具类 │ └── browser.js └── playwright.config.js关键设计原则环境隔离通过config目录区分不同环境的URL、账号等配置职责分离页面操作与断言逻辑完全解耦符合POM模式复用优先公共操作如浏览器启动封装到utils层2.2 核心配置文件封装在playwright.config.js中建议做这些关键配置const { devices } require(playwright/test); module.exports { timeout: 30000, retries: 2, workers: 3, reporter: [[html, { open: never }]], use: { headless: true, screenshot: only-on-failure, video: retain-on-failure }, projects: [ { name: chromium, use: { ...devices[Desktop Chrome] } }, { name: firefox, use: { ...devices[Desktop Firefox] } } ] };踩坑经验设置合理的retries能有效应对偶发性的网络问题多项目配置可以一键实现跨浏览器测试视频录制建议只在失败时保留以避免存储爆炸3. 工程化实践进阶3.1 浏览器上下文管理在utils/browser.js中封装浏览器实例const { chromium } require(playwright); class BrowserManager { static async createContext() { const browser await chromium.launch(); const context await browser.newContext({ viewport: { width: 1920, height: 1080 }, recordVideo: { dir: videos/ } }); return { browser, context }; } static async close({ browser, context }) { await context.close(); await browser.close(); } }这样在测试用例中就可以优雅地管理生命周期const { browser, context } await BrowserManager.createContext(); try { const page await context.newPage(); // 测试逻辑... } finally { await BrowserManager.close({ browser, context }); }3.2 页面对象模式实现以登录页面为例展示POM最佳实践class LoginPage { constructor(page) { this.page page; this.username page.locator(#username); this.password page.locator(#password); this.submit page.locator(button:has-text(登录)); } async navigate() { await this.page.goto(/login); } async login(user, pass) { await this.username.fill(user); await this.password.fill(pass); await this.submit.click(); } }在测试用例中使用const loginPage new LoginPage(page); await loginPage.navigate(); await loginPage.login(admin, 123456);这种模式带来的好处元素定位与业务操作解耦修改UI时只需调整对应页面类业务步骤可读性大幅提升4. 企业级扩展方案4.1 测试数据管理推荐使用Faker.jsJSON方案// fixtures/user.json { admin: { username: admincompany.com, password: Pssw0rd123 }, guest: { username: guesttest.org, password: Test1234 } } // 在测试中引用 const testData require(../fixtures/user.json); await loginPage.login(testData.admin.username, testData.admin.password);4.2 自动化流水线集成在GitLab CI中的典型配置test:e2e: stage: test image: mcr.microsoft.com/playwright:v1.25.0-focal script: - npm install - npx playwright install-deps - npx playwright test artifacts: when: always paths: - test-results/ - videos/关键点使用官方Docker镜像确保环境一致必须安装系统依赖(playwright install-deps)持久化测试报告和录屏便于问题排查5. 常见问题排查指南遇到元素找不到的问题时建议按这个顺序检查确认页面是否完全加载完成用page.waitForLoadState()检查iframe嵌套情况可能需要frame.locator()验证选择器是否唯一用Playwright Inspector调试查看是否有动态ID改用text定位或其他属性一个实用的调试技巧是在脚本开头加入const { chromium } require(playwright); (async () { const browser await chromium.launch({ headless: false }); const context await browser.newContext(); const page await context.newPage(); // 进入调试模式 await page.pause(); // 你的测试代码... })();这会在浏览器打开时暂停执行方便逐步调试。我在处理一个动态加载的表格时就是靠这个方法发现了异步渲染导致的选择器失效问题。