告别Selenium：5分钟用Playwright录制Web自动化测试脚本

1. 项目概述：为什么是Playwright，以及为什么现在可以“告别”Selenium

如果你和我一样，在Web自动化测试这个领域摸爬滚打了几年甚至十几年，那么“Selenium”这个名字对你来说，可能既是老朋友，也是“甜蜜的负担”。我们用它写过无数脚本，见证了Web从简单的静态页面到如今复杂SPA（单页应用）的演变。但不知道你有没有这种感觉：维护一个庞大的Selenium测试套件，尤其是应对现代Web应用层出不穷的动态加载、Shadow DOM、复杂交互时，那种心力交瘁感越来越强。脚本动不动就因元素定位失败而“飘红”，为了一个稳定的等待策略绞尽脑汁，更别提跨浏览器测试时那令人头疼的兼容性问题了。这感觉就像是用一把瑞士军刀去修理一台精密的数控机床，不是刀不好，而是场景变了，工具也需要进化。

这正是“告别Selenium”这个标题背后真正的呼声。它不是一个简单的口号，而是反映了测试工程师们对更高效、更稳定、更能适应现代Web开发范式的自动化工具的迫切需求。而Playwright，正是微软开源团队给出的一个强有力的答案。它不是一个简单的“Selenium替代品”，而是一个为现代Web“量身打造”的下一代自动化框架。它的设计哲学从底层就不同：Selenium是通过WebDriver协议与浏览器“对话”，而Playwright则是直接与Chromium、Firefox、WebKit这些浏览器的“开发工具协议”（DevTools Protocol）通信。这个根本性的差异，带来了体验上的天壤之别。

那么，为什么说Playwright能让我们在5分钟内搞定Web自动化测试呢？核心就在于它的“录制”功能。传统的自动化脚本编写，需要我们手动分析页面结构，编写定位器（XPath、CSS Selector），再组织逻辑。这个过程不仅耗时，而且对新手极不友好。Playwright的录制器（Codegen）则彻底改变了这个流程。你只需要像普通用户一样操作浏览器，它就能在后台实时生成对应的代码。这不仅仅是“录制-回放”那么简单，它生成的是结构清晰、可维护性高的代码，并且自带了Playwright框架强大的智能等待、自动重试等机制。对于快速创建冒烟测试、回归测试用例，或者为复杂的手动测试流程建立自动化基线，这个功能堪称“神器”。无论是前端开发者想为自己的组件快速写个集成测试，还是测试工程师需要快速覆盖一个新功能，甚至是产品经理想自动化一个固定的验收流程，Playwright录制都能在极短时间内交付一个可工作的脚本。

2. Playwright核心优势与Selenium的痛点对比

在决定投入一个新工具之前，我们必须清楚地知道它解决了哪些旧工具的痛点，以及它带来了哪些新的可能性。下面这个表格直观地对比了Playwright和Selenium在一些关键维度上的差异，这能帮助我们理解为什么迁移是值得的。

从表格可以看出，Playwright并非在单个功能上小修小补，而是在架构层面进行了重新设计，以应对现代Web应用的复杂性。其中最让我个人感触最深的是“智能等待”和“网络拦截”。以前用Selenium，超过一半的调试时间都花在处理元素加载时机和异步请求上。现在，page.click('button#submit')这一行代码，Playwright会帮你等到按钮确实可见、可点击时才执行点击，如果超时则抛出清晰的错误信息。这种“把复杂留给自己，把简单留给用户”的设计，极大地提升了开发体验和脚本的稳定性。

3. 手把手实战：5分钟用Playwright录制第一个自动化脚本

理论说得再多，不如亲手操作一遍。我们以在一个模拟的电商网站（例如https://demo.playwright.dev/todomvc或任何一个你熟悉的登录页面）上实现一个“登录-添加商品到购物车”的流程为例，来看看Playwright录制到底有多快。

3.1 环境准备与安装

首先，我们需要一个干净的环境。Playwright支持多种语言，这里以最流行的Python为例，JavaScript（Node.js）的流程几乎完全一致。

步骤1：创建项目并安装Playwright打开你的终端（命令行），执行以下命令。我强烈建议使用虚拟环境（如venv或conda）来管理依赖，避免污染全局环境。

# 1. 创建一个新的项目目录并进入 mkdir playwright-quickstart && cd playwright-quickstart # 2. （可选但推荐）创建Python虚拟环境 python -m venv venv # 激活虚拟环境 # Windows: venv\Scripts\activate # macOS/Linux: source venv/bin/activate # 3. 使用pip安装Playwright的Python包 pip install playwright # 4. 安装Playwright所需的浏览器（Chromium, Firefox, WebKit） # 这一步会下载浏览器二进制文件，请确保网络通畅。如果慢，可以尝试设置镜像源。 playwright install

注意：playwright install命令会下载所有三个浏览器。如果你只需要Chromium，可以运行playwright install chromium。国内用户如果遇到下载慢的问题，可以设置环境变量PLAYWRIGHT_DOWNLOAD_HOST为国内镜像源，例如https://npmmirror.com/mirrors/playwright/，但这需要查看Playwright官方文档确认当前可用的镜像地址。

步骤2：启动录制器（Codegen）安装完成后，录制功能已经内置。我们不需要打开任何IDE插件，直接在命令行启动即可。

# 启动录制器，并打开一个浏览器窗口 playwright codegen

执行这个命令后，会同时发生两件事：

1. 一个干净的浏览器窗口会打开（默认是Chromium）。
2. 一个名为“Playwright Inspector”的浮动窗口会打开，里面有一个代码编辑器区域。

这个Inspector窗口就是你的控制中心和代码生成器。浏览器里你的所有操作，都会被实时转换成代码显示在这里。

3.2 录制操作与代码生成解析

现在，让我们开始“表演”。假设我们要录制的流程是：访问一个登录页 -> 输入用户名密码 -> 登录 -> 搜索商品 -> 点击加入购物车。

1. 在打开的浏览器地址栏，输入目标网址，例如https://www.example.com/login（请替换为实际网址）。
2. 在登录页面：
   • 将鼠标移动到用户名输入框，点击。你会发现Inspector里自动生成了一行代码，比如page.get_by_label("Username").click()。Playwright会智能地选择一个最合适的定位器（这里用了get_by_label）。
   • 直接输入你的用户名，代码会变成page.get_by_label("Username").fill("my_username")。
   • 同理，完成密码输入和登录按钮点击。代码可能类似：

     page.get_by_label("Password").fill("my_password") page.get_by_role("button", name="Sign in").click()

3. 等待页面跳转：点击登录后，Playwright会自动处理导航等待。你不需要做任何事。
4. 在登录后的主页：
   • 找到搜索框，输入商品名称，如 “laptop”。
   • 从搜索结果列表中，点击一个商品。
   • 在商品详情页，点击“Add to Cart”按钮。

你的所有这些操作，都会被实时地、一行一行地转换成代码，显示在Inspector的编辑区。整个过程就像是在“教”Playwright如何操作，而它是个极聪明的学生，不仅记住了步骤，还用最佳实践写出了代码。

录制时的核心技巧与注意事项：

• 慢一点，清晰一点：操作不要太快，给页面一点反应时间，也让录制器能准确捕获你的意图。
• 关注生成的定位器：Playwright会优先使用get_by_role、get_by_text、get_by_label等语义化定位器，这比脆弱的XPath好得多。如果它生成了一个很长的XPath，你可以停下来，在Inspector里点击该元素，在右侧面板手动选择一个更好的定位方式。
• 使用“Assert”按钮：在Inspector中，你可以点击“Assert”按钮，然后点击页面上的某个元素（比如登录后的用户昵称），来生成一个断言代码，如expect(page.get_by_text("Welcome, User!")).to_be_visible()。这对于创建验证点至关重要。
• 保存你的脚本：录制完成后，直接点击Inspector窗口顶部的“Save”按钮，将生成的代码保存为一个.py文件（例如test_shopping.py）。

至此，一个完整的自动化测试脚本就在你指尖流淌而生，时间可能真的不到5分钟。但这生成的代码到底是什么样子的？我们接下来就深入看看。

3.3 生成的代码结构解读与优化

保存后，你的test_shopping.py文件内容大致如下（经过整理）：

import re from playwright.sync_api import Page, expect def test_example(page: Page): # 访问登录页 page.goto("https://www.example.com/login") # 登录操作 page.get_by_label("Username").click() page.get_by_label("Username").fill("my_username") page.get_by_label("Password").click() page.get_by_label("Password").fill("my_password") page.get_by_role("button", name="Sign in").click() # 验证登录成功（假设跳转到主页） expect(page).to_have_url("https://www.example.com/dashboard") # 搜索商品 page.get_by_placeholder("Search products...").fill("laptop") page.get_by_role("button", name="Search").click() # 点击第一个搜索结果 page.locator(".product-list a").first.click() # 加入购物车 page.get_by_role("button", name="Add to Cart").click() # 验证购物车数量更新 expect(page.locator(".cart-count")).to_have_text("1")

代码解读与优化建议：

1. 导入与结构：Playwright推荐使用Pytest作为测试运行器。生成的函数通常以test_开头，并接收一个pagefixture作为参数。这个page对象是你与浏览器标签页交互的主要接口。
2. 定位器（Locators）：这是Playwright的精华。page.get_by_role()、page.get_by_text()、page.get_by_label()等API，让定位变得语义化和稳定。你应该优先使用这些定位器，而不是page.locator(“//div[@id=‘xxx’]”)这样的XPath。
3. 自动等待：注意，代码里没有time.sleep或显式的WebDriverWait。click(),fill()等操作内部已经包含了等待。
4. 断言（Assertions）：使用expectAPI进行断言，语法清晰，并且也内置了等待机制（例如to_have_text会等待直到文本匹配或超时）。
5. 优化空间：
   • 提取配置：将URL、用户名密码等硬编码提取到配置文件或环境变量中。
   • 使用Page Object Model (POM)：对于复杂项目，将页面元素和操作封装成类，提高代码复用性和可维护性。录制生成的代码是很好的起点，你可以将其重构到POM类的方法中。
   • 添加注释：为复杂的业务逻辑添加注释。
   • 处理弹窗/新页面：如果操作打开了新标签页或弹窗，Playwright也能很好地处理，你需要使用page.context.on(“page”)事件监听或page.wait_for_event(“popup”)。

4. 超越录制：Playwright核心API与高级特性实战

录制功能让我们快速入门，但要构建健壮、可维护的自动化测试套件，我们必须深入理解Playwright提供的核心API和高级特性。录制生成的代码是一个很好的脚手架，但我们需要在其基础上进行“加固”和“升级”。

4.1 稳如磐石的定位器策略

元素定位是自动化测试的基石，也是脚本脆弱的根源。Playwright提供了多种定位策略，我们的目标是使用最稳定、最不易变化的那种。

1. 角色定位 (get_by_role)：这是首选。它通过ARIA角色（如button、link、textbox）和可访问名称来定位。这是最语义化的方式，只要前端开发遵循了基本的可访问性规范，它就非常稳定。

   # 优于 page.locator(“button.submit-btn”) page.get_by_role(“button”, name=“Submit”).click()

2. 文本定位 (get_by_text)：根据元素内的可见文本定位。非常适合按钮、链接、标题。

   page.get_by_text(“Login”).click() # 点击文本为Login的元素 page.get_by_text(“Welcome”, exact=False).click() # 非精确匹配

3. 标签定位 (get_by_label)：通过关联的<label>标签文本来定位表单控件。这是定位输入框的最佳实践。

   page.get_by_label(“Email Address”).fill(“test@example.com”)

4. 占位符定位 (get_by_placeholder)：定位带有placeholder属性的输入框。

5. 测试ID定位 (get_by_test_id)：这是最强大、最推荐的定位方式，但需要开发配合。前端在元素上添加一个专门的测试属性，如># 前端元素：<button># 1. 拦截并修改请求 page.route(“**/api/user”, lambda route: route.fulfill( status=200, body=json.dumps({“name”: “Mock User”, “id”: 123}) # 返回模拟数据 )) # 2. 模拟慢速网络（3G速度） context = browser.new_context( **playwright.devices[“iPhone 12”], # 同时模拟设备 locale=“zh-CN”, # 模拟语言环境 timezone_id=“Asia/Shanghai”, # 模拟时区 geolocation={“longitude”: 121.47, “latitude”: 31.23}, # 模拟上海地理位置 permissions=[“geolocation”] # 授予地理位置权限 ) slow_page = context.new_page() slow_page.goto(“https://maps.example.com”) # 页面将认为用户在上海

   模拟移动设备与视口：

   # 直接使用预定义的设备描述符，非常方便 iphone = playwright.devices[“iPhone 13 Pro”] context = browser.new_context(**iphone) mobile_page = context.new_page() mobile_page.goto(“https://m.example.com”) expect(mobile_page).to_have_screenshot(“mobile-home.png”) # 甚至可以截图对比

   4.3 处理弹窗、框架与多页面

   复杂Web应用中的弹窗、iframe和多标签页是测试的难点，Playwright处理起来却异常优雅。

   处理弹窗（对话框）： Playwright会自动监听并接受dialog事件，但最佳实践是预先设置监听器。

   # 在可能触发弹窗的操作前，设置监听器 page.on(“dialog”, lambda dialog: dialog.accept()) # 自动接受所有弹窗（如alert, confirm） # 或者更精确地处理 page.on(“dialog”, lambda dialog: print(f“Dialog message: {dialog.message}”) if “confirm” in dialog.type: dialog.accept() # 点击确认 else: dialog.dismiss() # 点击取消 ) page.get_by_text(“Delete Item”).click() # 这个点击可能会触发确认框

   操作iframe内的元素：

   # 通过iframe的name属性或URL定位iframe本身 frame = page.frame(name=“payment-form”) # 或 page.frame(url=re.compile(r“.*stripe.com.*”)) # 然后在frame对象上进行操作，就像操作page一样 frame.fill(“#card-number”, “4242 4242 4242 4242”)

   多标签页/多上下文：

   # 创建一个新的浏览器上下文（完全隔离的会话，如无痕模式） context2 = browser.new_context() page2 = context2.new_page() page2.goto(“https://example.com”) # page1和page2的cookies、localStorage完全隔离 # 处理通过点击链接打开的新标签页 with page.expect_popup() as popup_info: page.get_by_text(“Open New Window”).click() new_page = popup_info.value new_page.bring_to_front() # 切换到新页面 new_page.click(“button”)

   5. 集成到CI/CD与常见问题排查

   一个不能集成到持续集成/持续部署（CI/CD）流程的自动化测试是没有灵魂的。Playwright在这方面提供了强大的支持，同时，在实际运行中，我们也会遇到一些典型问题。

   5.1 在CI环境中运行Playwright

   在GitHub Actions、GitLab CI、Jenkins等环境中运行Playwright，核心是解决浏览器依赖和运行模式。

   GitHub Actions 配置示例 (.github/workflows/playwright.yml)：

   name: Playwright Tests on: [push, pull_request] jobs: test: timeout-minutes: 10 # 设置超时 runs-on: ubuntu-latest # 或 windows-latest, macos-latest steps: - uses: actions/checkout@v4 - uses: actions/setup-node@v4 with: node-version: ‘18’ - name: Install Python uses: actions/setup-python@v4 with: python-version: ‘3.10’ - name: Install dependencies run: | pip install -r requirements.txt # 包含playwright playwright install --with-deps chromium # 只安装Chromium及其系统依赖，加快速度 - name: Run your tests run: | # 以无头模式运行，并生成HTML报告 pytest --browser chromium --headed=False --html=report.html env: # 可以在这里设置测试所需的环境变量，如BASE_URL, USERNAME等 BASE_URL: ${{ secrets.BASE_URL }} - name: Upload test report uses: actions/upload-artifact@v4 if: always() # 即使测试失败也上传报告 with: name: playwright-report path: | report.html test-results/ # 包含截图、追踪等

   关键点：

   • playwright install --with-deps：这个命令会同时安装浏览器和其所需的操作系统依赖库（如字体、图形库），这在干净的CI环境中是必须的。
   • --headed=False：在CI中通常以无头模式运行以节省资源。
   • 并行化：Playwright Test runner（如果你使用它）原生支持并行运行测试，可以极大缩短测试套件总耗时。在CI配置中，你可以通过shard或工作器（worker）数量来控制。
   • 报告与制品：生成HTML、JUnit格式的报告并上传为制品，便于失败时查看日志、截图和视频（Playwright可自动录制失败测试的视频）。

   5.2 常见问题与排查技巧实录

   即使有了强大的工具，踩坑仍是难免的。以下是我在实际项目中遇到的一些典型问题及解决方案。

   问题1：元素定位失败，但页面看起来已经加载好了。

   • 可能原因：元素在Shadow DOM内部；元素在iframe里；页面使用了复杂的动态框架（如某些单页应用），DOM在初始加载后仍在变化。
   • 排查步骤：
     1. 使用Playwright Inspector调试：在运行命令中加入--debug参数（如pytest --debug），或使用PWDEBUG=1环境变量。这会在无头模式下打开浏览器并暂停，让你可以逐行执行代码并检查页面状态。
     2. 检查定位器：在浏览器开发者工具中，使用$()（对应page.locator()）和$$()（对应page.locator().all()）来验证你的定位器是否能准确找到元素。
     3. 尝试更稳定的定位器：放弃XPath和脆弱的CSS选择器，改用get_by_role、get_by_test_id。
     4. 显式等待：虽然Playwright操作内置等待，但在某些极端情况下，你可能需要更精细的控制。使用page.wait_for_selector()或page.wait_for_function()等待特定条件满足。

        # 等待一个具有特定文本的元素出现 page.wait_for_selector(“text=‘Operation Successful’”) # 等待一个复杂的JS条件成立 page.wait_for_function(““”() => { return document.querySelector(“.spinner”) === null && window.dataLoaded === true; }““”)

   问题2：测试在本地通过，但在CI上失败。

   • 可能原因：CI环境缺少浏览器依赖；CI机器性能差导致超时；网络环境或测试数据不同。
   • 解决方案：
     1. 确保安装了系统依赖：务必使用playwright install --with-deps。
     2. 增加超时时间：在CI配置或测试代码中全局增加timeout。

        # 在pytest配置中 # pytest.ini [tool:pytest] timeout = 30000 # 30秒

     3. 使用更稳定的定位器（再次强调）：CI环境可能比本地慢，脆弱的定位器更容易失败。
     4. 隔离测试数据：确保CI环境有独立、可预测的测试数据。避免使用可能被其他并行测试修改的共享数据。
     5. 查看CI日志和制品：失败时，下载并查看自动生成的截图、视频和追踪文件。Playwright的追踪功能可以像录像一样回放整个测试过程，是排查CI失败的神器。

        # 运行测试时启用追踪 pytest --tracing=on # 失败后，追踪文件会保存在`test-results/`目录，可以用`playwright show-trace`命令打开查看。

   问题3：如何处理动态内容（如随机生成的ID、类名）？这是现代Web应用自动化测试最常见的挑战之一。录制脚本最常见的失败原因就是动态内容。

   • 策略：
     1. 绝对避免使用包含动态部分的定位器：不要用page.locator(“#ember1234”)，其中1234是动态的。
     2. 使用相对定位或邻近元素：Playwright定位器支持链式调用和相对定位。

        # 找到一个静态的父元素，再在其中找目标元素 page.locator(“.static-container”).locator(“button”).click() # 使用filter()根据属性过滤 page.locator(“tr”).filter(has_text=“Product A”).locator(“button.delete”).click()

     3. 使用正则表达式：对于部分动态的属性值，可以使用正则匹配。

        page.locator(“[id^=‘dynamic-prefix-’]”) # id以‘dynamic-prefix-’开头的元素

     4. 从根本上解决：与开发协作使用测试ID：再次强调，># 错误的做法：直接获取文本然后判断 # text = page.locator(“.status”).text_content() # assert text == “Done” # 可能text还是“Processing” # 正确的做法：使用expect断言 expect(page.locator(“.status”)).to_have_text(“Done”) # 会自动等待直到文本匹配 # 或者等待元素出现/消失 expect(page.locator(“.loading-spinner”)).not_to_be_visible()

   从“告别Selenium”的畅想到用Playwright在5分钟内录制出第一个脚本，再到深入其核心API和应对各种实战挑战，这条路径的核心在于思维的转变。Playwright不仅仅是一个工具，它代表了一种更现代、更开发者友好的自动化测试理念。它通过降低编写稳定脚本的心智负担，让我们能更专注于测试逻辑本身和用户体验。对于长期受困于Selenium各种“怪问题”的团队来说，迁移到Playwright带来的稳定性和效率提升是立竿见影的。当然，任何迁移都有成本，但考虑到它大幅减少的维护时间和显著提升的测试可靠性，这个投资回报率无疑是极高的。我个人在多个项目中推动并完成了从Selenium到Playwright的迁移，最深的体会是：测试脚本的“幸福感”提高了，团队对自动化测试的信心也更强了。如果你还在观望，不妨就用上面介绍的5分钟方法，亲自录制一个你最熟悉的业务流程试试看，那种流畅的体验或许就是你说服自己团队开始尝试的最佳理由。