1. 为什么选择Playwright进行端到端测试

在Web自动化测试领域，Selenium曾经是无可争议的王者，但随着现代Web应用复杂度的提升，传统的测试工具开始暴露出各种局限性。三年前我在一个电商项目中使用Selenium时，经常遇到元素定位不稳定、测试执行缓慢等问题，直到发现了Playwright这个后起之秀。

Playwright由Microsoft开发，是一个真正为现代Web设计的测试框架。它最让我惊艳的特性是原生的自动等待机制 - 不像Selenium需要手动添加sleep，Playwright会智能等待元素可交互状态。上周我为一个客户搭建测试环境时，同样的测试用例，Playwright的执行速度比Selenium快了近40%，而且稳定性显著提高。

2. 环境搭建与基础配置

2.1 Python环境准备

虽然Playwright支持多种语言，但我强烈推荐使用Python版本。Python简洁的语法加上Playwright强大的API，能让你用最少的代码完成复杂的测试场景。我习惯使用Python 3.8+版本，这个版本在兼容性和性能上都有不错的表现。

安装步骤很简单：

pip install playwright playwright install

但这里有个容易踩的坑：某些企业网络环境下，直接安装可能会失败。我通常建议先配置好pip的国内镜像源，比如清华源：

pip config set global.index-url https://pypi.tuna.tsinghua.edu.cn/simple

2.2 Playwright浏览器配置

Playwright默认会安装Chromium、Firefox和WebKit三大浏览器引擎。在我的实际项目中，90%的情况使用Chromium就足够了，但如果你需要测试跨浏览器兼容性，建议保留全部引擎。

有个实用技巧：通过环境变量可以控制浏览器下载位置，这对磁盘空间有限的CI服务器很有帮助：

export PLAYWRIGHT_BROWSERS_PATH=$HOME/pw_browsers

3. 编写第一个端到端测试脚本

3.1 基本测试结构

让我们从一个真实的电商网站测试案例开始。假设我们要测试用户登录流程，以下是典型的测试脚本结构：

import re from playwright.sync_api import expect, Page def test_login(page: Page): # 导航到登录页面 page.goto("https://example.com/login") # 填写登录表单 page.get_by_label("用户名").fill("testuser") page.get_by_label("密码").fill("password123") # 点击登录按钮 page.get_by_role("button", name="登录").click() # 验证登录成功 expect(page).to_have_url(re.compile(r".*/dashboard")) expect(page.get_by_text("欢迎回来")).to_be_visible()

这个例子展示了Playwright的几个核心优势：

1. 直观的定位器API（get_by_label, get_by_role）
2. 内置的断言库（expect）
3. 自动等待机制（无需显式等待）

3.2 元素定位最佳实践

经过多个项目的实践，我总结出以下元素定位的经验：

1. 优先使用语义化定位器：如get_by_role和get_by_text，这些定位器最接近用户视角，可读性也最好。

2. 谨慎使用CSS和XPath：虽然Playwright支持传统定位方式，但语义化定位器在页面变更时更健壮。上周我重构一个项目时，将CSS选择器改为get_by_testid后，测试稳定性提高了60%。

3. 自定义属性：对于重要元素，建议开发团队添加data-testid属性，这是最稳定的定位方式：

page.get_by_test_id("login-submit").click()

4. 高级测试场景实战

4.1 处理iframe和弹窗

现代Web应用中，iframe和弹窗非常常见。Playwright处理这些场景特别优雅：

# 处理iframe with page.frame_locator("#payment-iframe").get_by_role("button", name="支付"): page.get_by_text("支付成功").click() # 处理弹窗 page.on("dialog", lambda dialog: dialog.accept()) page.get_by_text("删除").click()

4.2 模拟移动设备

Playwright内置了多种移动设备模拟，测试响应式设计非常方便：

from playwright.sync_api import sync_playwright def test_mobile_view(): with sync_playwright() as p: iphone = p.devices["iPhone 12"] browser = p.chromium.launch() context = browser.new_context(**iphone) page = context.new_page() page.goto("https://example.com") # 验证移动端布局 expect(page.locator(".mobile-menu")).to_be_visible()

4.3 网络请求拦截

这是Playwright最强大的功能之一，可以模拟各种网络条件：

# 拦截API请求 def handle_route(route): if "/api/user" in route.request.url: route.fulfill(json={"name": "Mock User"}) else: route.continue_() page.route("**/api/**", handle_route)

5. 测试报告与持续集成

5.1 生成HTML测试报告

Playwright自带的HTML报告非常实用，我通常这样配置：

pytest --browser chromium --headed --html=report.html

报告会包含：

• 测试步骤截图
• 执行时间线
• 控制台日志
• 网络请求记录

5.2 GitHub Actions集成

这是我常用的CI配置模板：

name: E2E Tests on: [push, pull_request] jobs: test: runs-on: ubuntu-latest steps: - uses: actions/checkout@v2 - uses: actions/setup-python@v2 - run: pip install -r requirements.txt - run: playwright install - run: pytest tests/ - uses: actions/upload-artifact@v2 if: always() with: name: playwright-report path: playwright-report/

6. 性能优化技巧

经过多个大型项目的实践，我总结了这些性能优化经验：

1. 复用浏览器上下文：每个测试用例创建新浏览器会显著拖慢速度。我通常会在pytest的fixture中复用上下文：

@pytest.fixture(scope="session") def browser(): with sync_playwright() as p: browser = p.chromium.launch() yield browser browser.close()

2. 并行执行：Playwright原生支持并行测试，使用pytest-xdist可以轻松实现：

pytest -n 4 # 使用4个worker并行执行

3. 禁用不必要的资源：对于不测试静态资源的场景，可以拦截请求提升速度：

context.route("**/*.{png,jpg,jpeg}", lambda route: route.abort())

7. 常见问题排查

在实施Playwright测试的过程中，我遇到过各种"坑"，这里分享几个典型问题的解决方案：

1. 元素无法定位：

   • 检查是否在iframe中
   • 使用playwright inspector调试定位器
   • 增加超时时间：page.click("button", timeout=10000)

2. 测试在CI上失败但在本地通过：

   • 确保CI环境安装了所有依赖：playwright install-deps
   • 添加启动参数：browser = p.chromium.launch(headless=True, args=["--no-sandbox"])

3. 跨域问题：

   • 创建上下文时指定权限：context.grant_permissions(["geolocation"])

最近在一个金融项目中，测试突然开始随机失败，最终发现是因为页面使用了Web Components。解决方案是调整定位策略，使用page.locator("::shadow-dom")语法来穿透Shadow DOM。

8. 项目结构建议

经过多个项目的迭代，我总结出这套高效的测试目录结构：

e2e/ ├── conftest.py # 公共fixtures ├── pages/ # 页面对象模型 │ ├── login.py │ └── dashboard.py ├── tests/ │ ├── smoke/ # 冒烟测试 │ ├── regression/ # 回归测试 │ └── api/ # API测试 ├── utils/ # 工具函数 │ ├── auth.py │ └── report.py └── playwright.config.py # 全局配置

这种结构的关键优势在于：

• 清晰的关注点分离
• 便于维护和扩展
• 适合大型项目

在实际项目中，我还会添加一个commands.py来封装常用的复杂操作，比如多步骤的结账流程，这样测试用例可以保持简洁。