Selenium还在等页面加载？Playwright已经跑完100个测试用例了_千锋教育

01 浏览器自动化的"旧王"与"新贵"

Selenium诞生于2004年，一个Web应用还停留在表单提交和页面跳转的年代。它用一套统一的API，让测试人员摆脱了手动点击的噩梦。16年积累，Selenium成为行业标准，几乎所有自动化测试教程都以它为例。

但时代变了。单页应用、微前端、实时交互...现代Web应用的复杂度远超当年。Selenium的设计哲学——模拟真实用户操作——在今天成了最大的性能瓶颈。

慢不是Selenium的错，错在你还用它去做它不擅长的事。

Playwright由微软于2020年开源，从诞生起就瞄准现代Web的挑战。它不模拟用户，而是直接控制浏览器底层。这意味着：更快的执行速度、更稳定的元素定位、更强大的网络拦截能力。

看一组数据对比：

• ►Selenium启动浏览器：平均2.3秒
• ►Playwright启动浏览器：平均0.8秒
• ►Selenium执行100个测试用例（中等复杂度）：约45分钟
• ►Playwright执行相同测试：约12分钟

差距不是一点点，是3-4倍。

架构差异是根本原因。Selenium通过WebDriver协议与浏览器通信，每个命令都要经过HTTP请求-响应。Playwright使用DevTools协议直接与浏览器进程通信，命令走的是WebSocket，延迟降低了90%。

02 易用性：从入门到放弃还是从入门到精通？

写自动化测试最痛苦的事：定位元素。Selenium的等待机制让无数新人崩溃。

# Selenium - 隐式等待和显式等待
from selenium import webdriver
from selenium.webdriver.common.by import By
from selenium.webdriver.support.ui import WebDriverWait
from selenium.webdriver.support import expected_conditions as EC

driver = webdriver.Chrome()
driver.implicitly_wait(10)  # 全局隐式等待

# 显式等待 - 代码瞬间膨胀3倍
element = WebDriverWait(driver, 10).until(
    EC.presence_of_element_located((By.ID, "submit-btn"))
)
element.click()

再看Playwright：

# Playwright - 自带智能等待
from playwright.sync_api import sync_playwright

with sync_playwright() as p:
    browser = p.chromium.launch()
    page = browser.new_page()
    page.goto("https://example.com")
    
    # 自动等待元素可交互，无需额外代码
    page.click("#submit-btn")

代码量减少60%，可读性提升200%。Playwright的自动等待机制会检测元素是否可见、可用、稳定，只有所有条件满足才会执行操作。

少写代码不是偷懒，是把精力留给真正需要思考的地方。

断言方面，Playwright也碾压Selenium：

• ►Selenium：需要手动获取元素属性，再调用assert
• ►Playwright：内置to_have_text(), to_be_visible()等断言方法

# Selenium断言
element = driver.find_element(By.CSS_SELECTOR, ".result")
assert element.text == "Success"

# Playwright断言
expect(page.locator(".result")).to_have_text("Success")

错误信息可读性：Playwright会告诉你"期望文本'Success'，实际文本'Succees'"，Selenium只会抛出一个AssertionError。

03 性能对决：谁在真正拖慢你的CI/CD？

CI/CD流水线中，测试执行时间是关键指标。测试跑得慢，开发就得等。等得久了，就有人开始跳过测试直接上线。

测试100个元素交互场景：

• ►Selenium：平均每个场景2.1秒，总耗时210秒
• ►Playwright：平均每个场景0.6秒，总耗时60秒

差距来源：

1. 命令执行方式：Selenium每个操作都要经过HTTP往返，Playwright通过WebSocket流式传输，延迟降低90%

2. 浏览器控制：Selenium模拟用户操作，Playwright直接调用浏览器API

3. 并发能力：Playwright原生支持多浏览器上下文，Selenium需要额外管理多个WebDriver实例

# Playwright并发执行测试
import asyncio
from playwright.async_api import async_playwright

async def run_test(browser_context, test_id):
    page = await browser_context.new_page()
    await page.goto("https://example.com")
    # 执行测试逻辑
    await page.click("#submit-btn")
    result = await page.text_content(".result")
    return f"Test {test_id}: {result}"

async def main():
    async with async_playwright() as p:
        browser = await p.chromium.launch()
        # 创建3个独立的浏览器上下文，类似3个独立浏览器
        contexts = [await browser.new_context() for _ in range(3)]
        
        # 并发执行3个测试
        tasks = [run_test(contexts[i], i) for i in range(3)]
        results = await asyncio.gather(*tasks)
        print(results)

asyncio.run(main())

Selenium要并发执行，得手动启动3个ChromeDriver进程，管理端口、处理资源竞争...代码量翻倍，稳定性下降。

不会并发的测试框架，就是CI/CD流水线上的乌龟。

内存占用方面：

• ►Selenium：每个浏览器实例约占用150-200MB内存
• ►Playwright：每个浏览器上下文约占用80-120MB内存

这意味着同样配置的服务器，Playwright可以跑2倍的并行测试。

04 实战场景：你的项目该选谁？

没有银弹。选框架看场景。

场景一：跨浏览器兼容性测试

• ►Selenium：支持所有主流浏览器（Chrome、Firefox、Safari、Edge、IE），包括IE11
• ►Playwright：支持Chrome、Firefox、Safari（WebKit），不支持IE

结论：需要测试IE兼容性，选Selenium。否则，Playwright更优。

场景二：单页应用（SPA）测试

• ►Selenium：需要频繁处理显式等待，代码臃肿
• ►Playwright：自动等待机制完美匹配SPA的动态加载

结论：SPA项目选Playwright，减少50%的等待相关代码。

场景三：API + UI混合测试

• ►Selenium：需要额外引入requests库
• ►Playwright：内置API请求能力

# Playwright - 在同一个测试中拦截API并验证UI
from playwright.sync_api import sync_playwright

def test_api_and_ui():
    with sync_playwright() as p:
        browser = p.chromium.launch()
        page = browser.new_page()
        
        # 拦截所有API请求
        api_responses = []
        page.on("response", lambda response: api_responses.append(response))
        
        page.goto("https://example.com")
        page.click("#load-data")
        
        # 验证UI
        expect(page.locator(".data-table")).to_be_visible()
        
        # 验证API响应
        assert api_responses[-1].status == 200
        assert api_responses[-1].json()["success"] == True

场景四：移动端测试

• ►Selenium：通过Appium支持iOS和Android
• ►Playwright：不支持移动端原生应用，仅支持移动端Web

结论：需要测试原生移动应用，选Selenium+Appium。

场景五：大型测试套件维护

• ►Selenium：社区成熟，文档丰富，但配置复杂
• ►Playwright：API设计简洁，维护成本低

选框架不是选技术，是选团队未来3年的维护成本。

05 迁移成本与未来趋势

从Selenium迁移到Playwright，需要投入多少成本？

代码重写率：约70-80%。虽然API设计思路不同，但测试逻辑可以复用。关键差异点：

• ►元素定位方式：基本兼容CSS选择器和XPath
• ►等待机制：删除所有显式等待代码
• ►浏览器管理：从WebDriver切换到launch()方法

学习曲线：

• ►Selenium熟练工程师：3-5天适应Playwright
• ►新人从零开始：Playwright比Selenium快40%上手

生态对比：

• ►Selenium：插件丰富，但很多已经过时
• ►Playwright：微软背书，更新频率高（每月2-3次版本更新）

行业趋势：

• ►2023年Stack Overflow调查：Playwright使用率增长300%
• ►GitHub星星数：Playwright 58k，Selenium 28k
• ►招聘需求：Playwright岗位同比增长220%

技术选型最贵的成本不是学习，而是坚持错误的选择。

未来18个月，Playwright大概率会成为Web自动化测试的事实标准。Selenium会继续存在，但会像今天jQuery一样——依然有人用，但不再是首选。

---

测试框架的战争没有输赢，只有谁更适配你的场景。但如果你还在为等待元素加载而熬夜加班，Playwright就是那个能让你准点下班的选择。

声明：本站部分稿件版权来源于网络，如有侵犯版权，请及时联系我们。