Playwright vs Selenium：迁移策略与重要注意事项

霍格沃兹测试开发
3 阅读6分钟

去年，我们团队面临一个艰难抉择：继续维护已经使用了五年的Selenium测试套件，还是迁移到当时刚崭露头角的Playwright。我们的测试套件包含了近2000个端到端测试，每天运行在多个浏览器上，但维护成本越来越高。最终我们决定迁移，而这个过程让我深刻理解了两种工具的差异。

为什么考虑迁移？

先说个真实经历。我们有一个测试，在Chrome 89上运行良好，但Chrome 90发布后突然开始随机失败。排查了两天，发现是Selenium的点击行为与浏览器更新后的默认行为有细微差异。这种“浏览器更新导致测试失效”的情况，在Selenium时代我们每个月都会遇到几次。

核心差异一览

架构设计的代际差距

Selenium基于WebDriver协议，需要为每个浏览器安装对应的驱动。这就像你需要为每个品牌的电视准备不同的遥控器。而Playwright直接通过DevTools协议与浏览器通信，更像是内置了万能遥控器。

# Selenium的典型启动代码from selenium import webdriverfrom selenium.webdriver.chrome.service import Serviceservice = Service('/path/to/chromedriver')driver = webdriver.Chrome(service=service)# 还需要处理版本兼容性问题# Playwright则简单得多from playwright.sync_api import sync_playwrightwith sync_playwright() as p:    browser = p.chromium.launch()    # 无需管理驱动版本

等待机制的彻底革新

这是迁移中最需要适应的一点。Selenium的显式等待经常让我们写出这样的代码：

# Selenium风格的等待from selenium.webdriver.support.ui import WebDriverWaitfrom selenium.webdriver.support import expected_conditions as ECfrom selenium.webdriver.common.by import Byelement = WebDriverWait(driver, 10).until(    EC.presence_of_element_located((By.ID, "dynamic-element")))# 还有隐式等待、强制等待……容易混乱

Playwright采用了更智能的自动等待：

# Playwright自动等待元素可操作page.click("#submit-button")  # 自动等待直到元素可点击page.fill("#username", "test")  # 自动等待输入框可编辑# 需要自定义等待时也更直观page.wait_for_selector(".success-message", state="visible", timeout=10000)

迁移的四个阶段

第一阶段：并行运行（1-2周）

不要直接替换，而是先让两者共存。我们在CI流水线中同时运行两套测试：

# 你的CI配置文件可能类似这样test_suite:parallel:    -name:"Selenium Legacy Tests"      command:"pytest selenium_tests/"        -name:"Playwright New Tests"      command:"pytest playwright_tests/"        -name:"Comparison Tests"      command:"python compare_results.py"# 对比关键路径测试结果

这个阶段的目标是建立信心。我们挑选了10个核心业务流程测试，用Playwright重写，然后对比两者的执行结果和稳定性。

第二阶段：选择器迁移策略

选择器是迁移中最耗时的部分。我们的经验是：

优先迁移CSS选择器

# Selenium的选择器方式多样，不统一driver.find_element(By.ID, "login-btn")driver.find_element(By.CSS_SELECTOR, ".login-button")driver.find_element(By.XPATH, "//button[contains(@class, 'login')]")# Playwright推荐使用更稳定的定位方式page.locator("button:has-text('登录')")  # 文本定位page.locator("[data-testid='login-submit']")  # 测试专用属性page.locator(".login-form >> button.primary")  # 链式选择

创建选择器映射表，这是我们的实际做法：

SELECTOR_MAPPING = {    "login_button": {        "selenium": ("id", "loginBtn"),        "playwright": "button:has-text('登录')",        "fallback": "[data-test-id='login-button']"    },    # ... 其他元素映射}def get_locator(page, element_name):    """统一的元素定位方法"""    mapping = SELECTOR_MAPPING[element_name]    return page.locator(mapping["playwright"])

第三阶段：处理框架差异

页面对象模式的重构

Selenium的页面对象通常这样写：

# Selenium风格的Page Objectclass LoginPage:    def __init__(self, driver):        self.driver = driver        self.username = (By.ID, "username")        self.password = (By.ID, "password")        def login(self, user, pwd):        self.driver.find_element(*self.username).send_keys(user)        self.driver.find_element(*self.password).send_keys(pwd)        # 还需要处理各种等待和异常

Playwright的页面对象更简洁：

# Playwright风格的页面对象class LoginPage:    def __init__(self, page):        self.page = page        self.username = page.locator("#username")        self.password = page.locator("#password")        self.submit = page.locator("button[type='submit']")        async def login(self, user, pwd):        await self.username.fill(user)        await self.password.fill(pwd)        await self.submit.click()        # Playwright会自动等待导航完成

截图和录像的改进

Playwright的截图能力强大得多：

# 不仅仅是全屏截图await page.screenshot(path="screenshot.png", full_page=True)await element.screenshot(path="element.png")  # 元素级别截图await page.screenshot(path="mobile.png", viewport={"width": 375, "height": 667})# 视频录制（Selenium很难实现）context = await browser.new_context(record_video_dir="videos/")

第四阶段：分批替换和优化

我们采用“新测试用Playwright，旧测试逐步迁移”的策略：

  1. 按优先级迁移：先迁移最不稳定、维护成本最高的测试

  2. 保持接口兼容：创建适配层，减少迁移影响

  3. 性能对比：监控迁移前后的执行时间和稳定性

迁移中的常见坑

1. 异步处理的思维转换

这是最大的思维转变。Selenium主要是同步的，而Playwright默认异步：

# 错误：混合使用同步和异步def test_login():    page.click("#button")  # 错误！需要await    # 正确：统一异步风格async def test_login(page):    await page.click("#button")    # 或者使用同步API    def test_login_sync(page):        page.click("#button")  # 同步API

2. 网络拦截的差异

Playwright的网络拦截更强大，但用法不同：

# Selenium处理网络请求很有限# 通常需要配合其他工具# Playwright可以直接拦截和修改await page.route("**/api/login", lambda route: route.fulfill(    status=200,    body=json.dumps({"success": True})))# 或者监听所有请求page.on("request", lambda request: print(f">> {request.method} {request.url}"))

3. 多浏览器测试的简化

# Selenium需要为每个浏览器配置不同驱动# Playwright一行代码切换浏览器@pytest.mark.parametrize("browser_type", ["chromium", "firefox", "webkit"])def test_multi_browser(browser_type):    with sync_playwright() as p:        browser = getattr(p, browser_type).launch()        # 相同代码在不同浏览器运行

迁移后的收益

迁移完成三个月后，我们的数据对比：

  1. 执行时间：从平均45分钟减少到18分钟

  2. 稳定性：随机失败率从12%降低到2%以下

  3. 维护成本：每周修复测试的时间从15小时减少到3小时

  4. 代码量：测试代码减少约40%

你应该迁移吗？

根据我们的经验，以下情况建议迁移：

✅ 你的测试套件超过100个用例

✅ 需要测试现代Web功能（PWA、WebSocket等）

✅ 对执行速度和稳定性有更高要求

✅ 团队愿意学习新的测试模式

以下情况可以暂缓：

⏸️ 项目即将结束维护

⏸️ 团队对Selenium非常熟悉且当前稳定

⏸️ 主要测试遗留系统，Playwright支持有限

开始你的迁移

如果决定迁移，我的建议是：

  1. 先从一个小的、独立的模块开始

  2. 建立对比基准，确保功能对等

  3. 培训团队成员，特别是异步编程概念

  4. 逐步推进，不要试图一次性完成

迁移的过程就像给行驶中的汽车换轮胎——需要谨慎，但一旦完成，你会感受到显著的性能提升。我们从Selenium到Playwright的迁移花了四个月，虽然过程中有些阵痛，但回头看，这是去年我们做的最正确的技术决策之一。

记住，工具只是手段，保证软件质量才是目的。选择最适合你当前和未来需求的工具，然后优雅地完成过渡。

avatar
文章
阅读
粉丝