在Web UI自动化这个圈子里Selenium称霸了好多年几乎成了代名词。但最近两年Playwright的势头确实猛尤其是和Pytest一搭配整个编写体验和运行稳定性都上了一个台阶。我自己的项目从Selenium迁移过来之后最直观的感受是代码量少了将近一半以前最头疼的等待问题和浏览器驱动管理问题几乎消失了。这篇文章就围绕“Playwright Pytest 实现 Web UI 自动化测试”这套组合把我从选型、搭建、写用例到跑稳定全过程的经验整理出来。不管你是刚接触UI自动化的新人还是被Selenium折磨多年的老手这套方案都值得看一看。1. 方案选型与整体设计思路1.1 为什么是 Playwright而不是继续用 Selenium先说结论Playwright 不是Selenium的简单升级而是从底层设计上就针对UI自动化的痛点做了重构。第一个痛点是等待策略。Selenium时代我们写time.sleep()或者WebDriverWait配expected_conditions代码里到处都是显式等待又丑又脆。Playwright内置了自动等待机制执行点击、输入这类操作前会自动检查元素的可操作性可见、稳定、可被点击等不到就超时报错。这意味着90%的等待代码可以直接删掉。第二个痛点是浏览器驱动管理。Selenium需要手动下载对应版本的chromedriver、geckodriver还要处理驱动和浏览器版本不匹配的问题。Playwright安装时会自动下载浏览器内核版本由工具内部管理基本不用操心。第三个痛点是调试体验。Playwright提供了--headed模式有头运行和--slow-mo参数放慢操作速度还有一个非常强大的Playwright Inspector调试器能随时查看页面状态、元素快照、网络请求排查问题比Selenium的截图大法高效得多。当然Selenium也有它的优势生态成熟、支持的语言和浏览器更全、老项目积累多。但如果你是从零开始或者项目允许技术选型Playwright绝对是当前更合理的选择。1.2 Pytest 在其中扮演的角色Pytest本身和UI自动化没有直接关系它是个通用的Python测试框架。但它和Playwright组合后提供了三样关键能力fixture机制用于管理浏览器实例、页面对象的创建和销毁实现“每个用例独立浏览器上下文”的隔离效果。断言体系Pytest自带的assert配合Playwright的expect()方法能写出简洁直观的断言失败信息还很详细。插件生态pytest-html出测试报告、pytest-xdist并行跑用例、pytest-rerunfailures失败重跑这些加起来才构成一个完整的自动化测试框架。在设计思路上我的建议是用Pytest管理测试生命周期和执行策略用Playwright驱动浏览器二者各司其职。测试用例只写业务逻辑底层技术细节都被封装掉这样维护起来才不累。1.3 项目结构怎么规划才合理一个清晰的项目结构比什么都重要。我常用的目录结构如下web_ui_test/ ├── conftest.py # pytest全局配置与fixture ├── pytest.ini # pytest配置文件 ├── requirements.txt # 依赖清单 ├── pages/ # Page Object模式封装层 │ ├── __init__.py │ ├── base_page.py # 页面基类 │ ├── login_page.py # 登录页封装 │ └── home_page.py # 首页封装 ├── testcases/ # 测试用例层 │ ├── __init__.py │ ├── conftest.py # 用例层的fixture │ ├── test_login.py │ └── test_home.py ├── data/ # 测试数据JSON/YAML/Excel ├── reports/ # 测试报告输出目录 └── utils/ # 通用工具模块 ├── __init__.py └── read_data.py这样分层的目的很明确用例层只描述“测什么”页面层只描述“怎么操作”数据和配置独立管理。某天页面按钮位置变了只需要改pages目录下的对应文件测试用例一行都不用动。2. 环境搭建与工程配置实操2.1 安装步骤与常见坑安装这块官方文档写得挺清楚但有几个细节容易踩坑。第一步是安装Playwright库pip install playwright pytest pytest-html pytest-rerunfailures pytest-xdist pip install playwright然后安装浏览器内核playwright install chromium这里有个坑公司内网环境、沙箱环境或者某些Linux服务器上playwright install可能会因为网络问题下载失败。解决办法是手动下载浏览器包放到指定目录后设置环境变量PLAYWRIGHT_BROWSERS_PATH指向该目录。另外如果你的服务器是精简版Linux系统运行Chromium可能报缺少系统依赖库。这时候执行playwright install-deps它会帮你把系统依赖库都装好。如果权限不够加sudo。2.2 pytest.ini 配置解读pytest.ini是Pytest的核心配置文件我一般这样写[pytest] # 用例收集规则 python_files test_*.py python_classes Test* python_functions test_* # 命令行默认参数 addopts -s -v --htmlreports/report.html --self-contained-html # 标记 markers smoke: 冒烟测试 regression: 回归测试这里的addopts表示执行pytest时默认追加的参数-s显示print输出-v显示详细日志--html自动生成HTML报告。markers用来给用例打标签执行时可以按标签筛选。2.3 conftest.py 编写与fixture设计conftest.py是整个框架的“基础设施文件”里面的fixture可以被所有用例共享。一个最基础的版本是这样import pytest from playwright.sync_api import sync_playwright pytest.fixture(scopefunction) def browser_page(): with sync_playwright() as p: browser p.chromium.launch(headlessFalse) # 无头模式改为True context browser.new_context( viewport{width: 1920, height: 1080}, localezh-CN, ignore_https_errorsTrue # 忽略证书错误内网系统常用 ) page context.new_page() yield page context.close() browser.close()这个fixture做了几件事创建浏览器实例、创建独立上下文、创建新页面、执行用例、最后关闭浏览器。scopefunction表示每个用例都开新的浏览器上下文保证用例之间的隔离互不干扰。如果要做登录态复用可以在context里添加storage_state参数把登录后的cookie状态直接注入避免每条用例都走一遍登录流程context browser.new_context( storage_stateauth/login_state.json )登录一次后把状态保存下来context.storage_state(pathauth/login_state.json)这是我强烈推荐的一个优化点UI自动化最耗时的就是重复登录用storage_state能大幅提升执行效率。3. 元素定位、操作与等待策略实战3.1 定位器的选择与优先级Playwright的定位API比Selenium丰富得多我常用的优先级是这样的get_by_role()基于ARIA角色的语义定位最贴近用户感知get_by_label()表单元素关联的label定位get_by_placeholder()按placeholder属性定位输入框get_by_text()按文本内容定位CSS选择器page.locator(.classname)或page.locator(#id)XPathpage.locator(xpath//div[idx])最后手段实际项目里我大量使用get_by_role和get_by_label原因有两个第一这些定位方式读起来像人话可读性好第二前端结构调整时按钮的角色和label通常变化不大不像class和id那样说改就改。举个例子定位登录按钮# Selenium老办法 driver.find_element(By.XPATH, //button[classlogin-btn submit]).click() # Playwright推荐做法 page.get_by_role(button, name登 录).click()后者明显更稳定。哪怕前端把login-btn submit改成btn-primary这个定位依然有效。3.2 高频操作的代码示范登录、填写表单、上传文件、下拉选择这四类操作覆盖了Web自动化的80%场景。登录表单填写def login(page, username, password): page.goto(https://example.com/login) page.get_by_label(用户名).fill(username) page.get_by_label(密码).fill(password) page.get_by_role(button, name登 录).click() page.wait_for_url(**/home) # 等待跳转到首页上传文件page.set_input_files(input[typefile], data/测试数据.xlsx)下拉选择page.select_option(#province, label广东省) page.select_option(#city, index2) # 按索引 page.select_option(#area, value4401) # 按valueiframe内元素操作Playwright对iframe的处理非常优雅不用先切来切去frame page.frame_locator(#main-iframe) frame.get_by_role(button, name保存).click()3.3 自动等待机制的底层逻辑与手动兜底Playwright的自动等待是它的核心优势但它不是万能的。理解它的机制才能用好它。自动等待会等待以下条件同时满足才执行操作元素已附加到DOM中元素可见非display:none、非visibility:hidden元素稳定比如动画中会等待动画结束元素可接受事件没有被遮罩层遮挡元素处于启用状态这背后有个“actionability check”机制默认超时时间是30秒可配置。比如页面有个loading动画在转按钮在动画下面Playwright会等到动画结束才点击不会像Selenium那样直接报“element not clickable”。但有些场景自动等待搞不定比如接口返回后页面的跳转。这时候需要手动等待# 等待某个请求完成 with page.expect_request(**/api/getUserInfo) as req: page.click(#load-data-btn) response req.value # 等待某个URL出现 page.wait_for_url(**/dashboard) # 等待某个元素消失比如loading图标 page.locator(.loading).wait_for(statedetached)还有个通用技巧优先等待接口响应而不是等固定时间。我在项目中给page对象封装了一个方法传入接口路径前缀等待对应响应返回后再继续def wait_for_api(page, api_prefix, timeout10000): 等待指定API接口响应单位毫秒 with page.expect_response(lambda r: api_prefix in r.url and r.status 200) as resp: pass return resp.value3.4 网络请求监听、Mock与拦截Playwright最让我惊艳的能力是网络层的拦截和Mock。这对前端联调、后端未就绪的场景特别有用。监听请求page.on(request, lambda req: print( 请求, req.method, req.url)) page.on(response, lambda resp: print( 响应, resp.status, resp.url))直接Mock接口返回# 拦截页面上的 /api/user/list 请求直接返回假数据 page.route(**/api/user/list, lambda route: route.fulfill( status200, content_typeapplication/json, body[{id: 1, name: 张三}, {id: 2, name: 李四}] )) page.goto(https://example.com/user-list)这个能力在UI自动化里能解决一个老大难问题用例依赖后端数据而后端数据不稳定。通过Mock接口我们可以把前端行为和后端状态解耦只验证UI交互逻辑大大提高用例稳定率。4. 测试用例编写与断言技巧4.1 用例粒度怎么控制UI自动化用例不是越多越好粒度的把控非常关键。我总结的经验是冒烟用例覆盖核心主流程比如“登录-进入首页-发起一笔业务”数量控制在总用例的10%以内每次代码提交后必跑。功能用例一个页面的一组核心功能点比如“新增用户的校验逻辑”“列表翻页搜索”。不要写超长用例一个用例跑超过两三分钟就应该拆。超长用例失败后定位问题特别痛苦。还有一个经验UI自动化不适合做大量数据的遍历验证。那种“用50组数据验证登录失败提示”的用例应该交给接口自动化去跑UI层验证3-5组代表性数据就够了否则执行时长和稳定性都会被拖垮。4.2 断言该怎么写Playwright 1.26以上版本自带断言工具from playwright.sync_api import expect配合Pytest的断言风格统一使用from playwright.sync_api import expect def test_login_success(page): login(page, admin, 123456) # 断言URL expect(page).to_have_url(https://example.com/home) # 断言元素可见 expect(page.get_by_text(欢迎回来)).to_be_visible() # 断言元素包含文本 expect(page.locator(.username)).to_contain_text(admin) # 断言输入框的值 expect(page.locator(#keyword)).to_have_value(默认搜索词)这些断言会自动等待、自动重试直到条件满足或超时。大多数情况下不需要显式等待直接断言即可。4.3 数据驱动把用例和数据分离测试数据不该硬编码在用例里。我习惯用JSON文件管理测试数据再用Pytest的parametrize做数据驱动[ {username: admin, password: 123456, expect: 登录成功}, {username: admin, password: wrong, expect: 用户名或密码错误} ]用例代码import pytest import json def load_test_data(file_path): with open(file_path, r, encodingutf-8) as f: return json.load(f) pytest.mark.parametrize(data, load_test_data(data/login_data.json)) def test_login_case(page, data): login(page, data[username], data[password]) if data[expect] 登录成功: expect(page.get_by_text(欢迎回来)).to_be_visible() else: expect(page.get_by_text(data[expect])).to_be_visible()这样新增用例不需要改代码往JSON里加一条数据就行。配合Pytest的-k参数还能按数据ID筛选pytest -k case1 or case34.4 失败重跑与用例标记UI自动化天生有脆弱性网络抖动、前端资源加载慢都可能导致偶发失败。合理使用重跑机制能显著提升CI流水线的通过率。安装pytest-rerunfailures后在配置里加上pytest --reruns 2 --reruns-delay 1但重跑不是银弹重跑多了反而掩盖真实问题。我的习惯是网络相关的偶发失败重跑2次业务流程断言失败不重跑立即定位用例标记的玩法也很实用pytest.mark.smoke def test_core_login(page): pass pytest.mark.regression def test_advanced_filter(page): pass执行时按标记筛选pytest -m smoke # 只跑冒烟 pytest -m not regression # 排除回归5. 报告生成、并行执行与CI集成5.1 PytestAllure 报告搭建pytest-html生成报告简单方便但信息量有限。想要专业级的测试报告我推荐Allure。装两个依赖pip install allure-pytest然后执行测试时加参数pytest --alluredirreports/allure-results allure generate reports/allure-results -o reports/allure-report --clean在用例里加Allure注解让报告更丰满import allure allure.feature(登录模块) allure.story(用户登录) allure.title(使用正确密码可以登录成功) allure.severity(allure.severity_level.BLOCKER) def test_login_success(page): with allure.step(打开登录页): page.goto(https://example.com/login) with allure.step(填写表单): login(page, admin, 123456) with allure.step(验证登录结果): expect(page.get_by_text(欢迎回来)).to_be_visible()Allure报告最大的价值是步骤清晰每个step都能在报告里看到失败时还能自动截图贴到报告里需要在fixture里配置截图逻辑。5.2 pytest-xdist 并行执行的正确姿势pytest-xdist能让用例并行跑用法很简单pytest -n 4-n 4表示开4个进程并行执行。但UI自动化并行有个前提用例之间必须完全独立不能共享状态。这正好验证了我们前面用function级fixture隔离的好处。更大的坑在资源占用。每个Chromium进程大概要吃200-400MB内存4个并行就是1G以上。你的CI机器如果配置不高建议用2个进程就好否则并发跑起来机器卡死得不偿失。还有一种更优的并行方案用pytest-xdist的--dist loadscope按测试模块分发让同一个模块的用例在同一个进程里执行利用率更高pytest -n 4 --dist loadscope5.3 接入Jenkins流水线的步骤UI自动化要发挥价值一定得接入CI持续跑。我用Jenkins的流水线是这样配置的pipeline { agent any stages { stage(安装依赖) { steps { sh pip install -r requirements.txt sh playwright install chromium } } stage(执行测试) { steps { sh pytest -m smoke --alluredirreports/allure-results } } stage(生成报告) { steps { sh allure generate reports/allure-results -o reports/allure-report --clean } } } post { always { allure includeProperties: false, junit: false, reportBuildPolicy: ALWAYS, results: [[path: reports/allure-results]] } } }需要注意CI服务器上必须跑无头模式headlessTrue否则没有图形界面跑不起来。前面conftest.py里配置headlessFalse的地方在CI环境上要改成True。更优雅的方式是从环境变量读取import os HEADLESS os.getenv(HEADLESS, true).lower() true browser p.chromium.launch(headlessHEADLESS)本地调试时export HEADLESSfalseCI环境保持默认无头一套代码两边通吃。6. 常见问题与排查技巧实录6.1 定位不到元素先自查这几件事这是UI自动化里出现频率最高的问题。每次遇到“playwright._impl._errors.TimeoutError: Timeout 30000ms exceeded”这类报错我都是按下面的顺序排查页面是不是没加载完先看page.goto()有没有设置wait_untilnetworkidle页面还在发请求时元素自然找不到。是不是在iframe里检查元素是否嵌套在iframe中。用page.frames看看页面有哪些frame用frame_locator定位。是不是有shadow DOMPlaywright的CSS定位可以穿透open模式的shadow DOM但要确保选择器写法正确。更稳妥的方案是用locator逐层进入。是不是有多个匹配元素尝试用.locator(...).first、.locator(...).nth(2)或修改定位器让它更精确。调试工具快照。Playwright最实用的调试手段page.locator(#target).highlight() # 高亮元素 page.screenshot(pathdebug.png) # 截图看现场截图是排查问题的第一手段强烈建议在fixture里加入失败自动截图的功能pytest.fixture() def browser_page(): ... yield page if request.node.rep_call.failed: page.screenshot(pathfreports/fail_{request.node.name}.png) context.close()配合下面这段钩子让每个用例记录执行结果状态pytest.hookimpl(tryfirstTrue, hookwrapperTrue) def pytest_runtest_makereport(item, call): outcome yield rep outcome.get_result() setattr(item, rep_ rep.when, rep)6.2 页面频繁跳转不稳定怎么办业务系统里经常有点击按钮后弹窗、跳新标签页、或者多级菜单这类交互。Playwright处理这些比Selenium顺手得多但也有一些注意点。新标签页Tab处理点按钮后打开新标签页用context.expect_page()来捕获with context.expect_page() as new_page_info: page.get_by_role(button, name打印预览).click() new_page new_page_info.value # 切换到新页面 new_page.wait_for_load_state() new_page.get_by_role(button, name打印)).click()多级菜单鼠标悬浮用hover代替Selenium的ActionChainspage.get_by_role(link, name系统管理).hover() page.get_by_role(link, name用户管理).click()弹窗alert处理Playwright默认自动接收对话框如果想验证弹窗内容with page.expect_alert() as alert_info: page.get_by_role(button, name确定删除).click() assert alert_info.value.message_text 确认删除这条记录吗6.3 测试数据清理与用例间的耦合问题UI自动化最容易被忽视的坑是脏数据。假设你跑了一条“新增用户”的用例用户名称是“test_001”下次跑的时候再新增同名的就会报“用户已存在”。我的处理经验有两板斧第一板斧测试数据随机化。用时间戳生成唯一标识import time unique_name f用户_{time.strftime(%Y%m%d%H%M%S)}第二板斧测试前置清理。在用例的前置操作里如果存在同名的测试数据就先删除掉def test_add_user(page): # 前置清理确保用户 test_del 不存在 if page.get_by_text(test_del).count() 0: page.get_by_role(button, name删除).click()虽然多写几行代码但跑100遍都不会因为数据残留失败这笔投资太值了。6.4 Playwright 同步模式与异步模式的选择很多新手在这里纠结其实很简单默认用同步APIsync_playwright就好。同步API和Pytest组合最流畅代码直观调试方便。只有当你需要大量并发请求或者有特殊性能要求时才考虑异步APIasync_playwright。还有一个容易碰到的问题如果代码里混用了两种模式或者在一个异步环境中用了同步API会报“It looks like you are using Playwright Sync API inside the asyncio loop”之类错误。我的建议很简单一个项目里选定一种模式别混用。Pytest系列一律用同步API代码最省心。一点使用体会从Selenium迁移到Playwright我最大的感受不是某个功能多强大而是整个工具的设计哲学变了。Selenium像是给你一堆零件让你自己组装Playwright则是把“合理默认值”都帮你定好了自动等待、自动驱动管理、自动截图还有那个夸张的代码生成器record mode点一下就能生成可用的测试代码。这些细节累积起来直接改变了写UI自动化的体验。当然工具只是基础。真正决定UI自动化成败的还是用例设计的好不好、数据稳不稳定、维护积不积极。哪怕换成Playwright如果用例粒度一团糟、数据写死不隔离、页面一改就全挂再强的工具也救不回来。最后分享一个小技巧给关键操作加上操作注释。不是写“点击按钮”这种废话而是写业务背景比如“点击审批通过按钮走流程到财务节点”。三个月后你回头看这个用例会无比感谢当初认真的自己。