1. 为什么说 pytest 和 playwright 是“黄金组合”如果你做过 Web 自动化测试肯定经历过这样的痛苦写一个测试脚本光是处理各种等待sleep就让人头大浏览器兼容性问题更是“玄学”今天 Chrome 能跑通明天 Firefox 就报错。测试用例一多管理起来也是一团乱麻哪个失败了、为什么失败排查起来像大海捞针。我做了这么多年测试用过不少工具从早期的 Selenium 到后来的 Puppeteer直到遇到了pytest和playwright这对组合才真正体会到什么叫“无缝”和“高效”。这俩工具单独拿出来都很能打但组合在一起产生的化学反应远超你的想象。简单来说pytest 就像一个经验丰富的测试指挥官负责排兵布阵、制定规则、汇总战报而 playwright 则是一个全能的特种兵能同时在 Chrome、Firefox、Safari 等多个“战场”上精准执行命令而且自带“预判”能力不用你反复催促。这个组合的核心优势我总结为三点写起来简单、跑起来稳定、管起来省心。你不用再写一大堆time.sleep(5)来等页面加载playwright 的自动等待机制能智能判断元素是否就绪。你也不用为每个浏览器写一套不同的脚本playwright 的 API 是跨浏览器一致的。更重要的是pytest 提供了从用例组织、数据驱动、到报告生成的一整套“基础设施”让你能把精力真正放在测试逻辑本身而不是繁琐的框架搭建上。接下来我就带你从零开始一步步搭建这个“黄金组合”并分享我在实际项目中踩过的坑和总结的最佳实践保证你跟着做就能上手。2. 环境搭建5分钟搞定你的第一个测试万事开头难但这次开头真的不难。我们先把舞台搭好。2.1 安装依赖一行命令的事打开你的命令行终端CMD、PowerShell 或 Terminal创建一个新的项目目录然后执行下面两条命令。我强烈建议你使用虚拟环境比如venv或conda避免包版本冲突。# 安装 pytest 和 playwright 的 Python 包 pip install pytest playwright # 安装 playwright 所需的浏览器内核Chromium, Firefox, WebKit playwright install第一行命令会安装核心的 Python 包。第二行命令playwright install非常关键它会自动下载 Chromium、Firefox 和 WebKitSafari 内核的可执行文件到本地。这个过程需要一点时间取决于你的网络但请确保它顺利完成。如果卡住可以试试设置国内镜像源或者使用playwright install chromium先只安装最常用的 Chromium。安装完成后你可以快速验证一下pytest --version playwright --version能看到版本号就说明基础环境 OK 了。2.2 编写你的第一个测试脚本环境有了我们来写一个最简单的测试感受一下这个组合的流畅度。创建一个名为test_quick_start.py的文件。import pytest from playwright.sync_api import Page, expect def test_visit_playwright_homepage(page: Page): 测试访问 Playwright 官网并验证标题 # 1. 导航到页面 page.goto(https://playwright.dev/python) # 2. 使用 expect 进行断言这是 Playwright 推荐的异步安全断言 expect(page).to_have_title(Fast and reliable end-to-end testing for modern web apps | Playwright Python) # 3. 也可以结合 pytest 的原生 assert assert Playwright in page.title() # 4. 点击一个链接并验证跳转 docs_link page.get_by_role(link, nameDocs) docs_link.click() expect(page).to_have_url(https://playwright.dev/python/docs/intro)这个脚本里已经包含了几个核心概念pageFixture这是 pytest-playwright 插件提供的你不用自己创建浏览器实例和页面框架已经帮你管理好了。直接在测试函数参数里声明page: Page就能用。自动等待page.goto()、click()这些操作playwright 会自动等待网络请求完成、元素可交互等条件省去了无数sleep。expectAPI这是 playwright 的断言库它是异步安全的并且能提供更友好的错误信息。当然你依然可以用传统的assert。定位器page.get_by_role(link, nameDocs)是一种推荐的定位方式它基于可访问性角色比脆弱的 CSS 选择器更稳定。现在在终端运行这个测试pytest test_quick_start.py -v你会看到浏览器默认是 Chromium自动打开快速执行操作然后关闭终端打印出绿色的PASSED。是不是比想象中简单这还只是开胃菜。3. 核心技巧让测试更健壮、更易维护脚本能跑起来只是第一步写出能在团队协作和持续集成中稳定运行的测试才是关键。下面这几个技巧是我从无数个“坑”里总结出来的。3.1 善用 Fixture管理测试的生命周期pytest 的 Fixture 是管理测试依赖和资源的利器。结合 playwright我们可以自定义一些非常强大的 Fixture。比如我不想每次测试都打开新的浏览器太慢了但所有测试用一个浏览器又怕互相干扰。怎么办可以设置浏览器上下文级别的隔离。创建一个conftest.py文件pytest 会自动发现这个文件import pytest from playwright.sync_api import Playwright, Browser, BrowserContext pytest.fixture(scopesession) def playwright_instance(): 在整个测试会话中只启动一次 Playwright 实例 with sync_playwright() as p: yield p pytest.fixture(scopesession) def browser(playwright_instance: Playwright): 会话级浏览器实例所有测试共享一个浏览器进程 # 这里可以配置启动参数比如无头模式、慢速模拟等 browser playwright_instance.chromium.launch(headlessTrue, slow_mo500) # headlessTrue 表示无界面适合CI环境 yield browser browser.close() pytest.fixture(scopefunction) def context(browser: Browser): 函数级的浏览器上下文每个测试函数一个独立的‘隐身模式’会话 context browser.new_context( viewport{width: 1920, height: 1080}, ignore_https_errorsTrue ) yield context context.close() pytest.fixture(scopefunction) def page(context: BrowserContext): 函数级的页面这是最常用的 Fixture page context.new_page() yield page page.close()这样配置后你的测试函数只需要请求page这个 Fixture。每个测试都会获得一个干净的、独立的页面环境包括独立的 cookies、localStorage但背后共享同一个浏览器进程速度大大提升。scope参数控制生命周期session整个 pytest 执行过程一次、function每个测试函数一次是最常用的。3.2 参数化测试用一份代码覆盖多种场景这是 pytest 的杀手级功能。假设你要测试一个登录功能需要验证正常登录、密码错误、用户名不存在等多种情况。不用写多个重复的函数一个参数化搞定。import pytest # 测试数据可以放在这里也可以从文件如JSON, CSV中读取 LOGIN_TEST_DATA [ (correct_user, correct_password, True, 登录成功), (wrong_user, some_password, False, 用户名不存在), (correct_user, wrong_password, False, 密码错误), (, some_password, False, 用户名为空), ] pytest.mark.parametrize(username, password, expected_success, expected_message, LOGIN_TEST_DATA) def test_login_with_parameters(page: Page, username, password, expected_success, expected_message): page.goto(https://your-app.com/login) page.fill(#username, username) page.fill(#password, password) page.click(#submit-btn) if expected_success: # 期望登录成功跳转到首页 expect(page).to_have_url(https://your-app.com/dashboard) welcome_text page.locator(.welcome-message) expect(welcome_text).to_contain_text(username) else: # 期望登录失败显示错误信息 error_toast page.locator(.error-message) expect(error_toast).to_be_visible() expect(error_toast).to_contain_text(expected_message)运行测试时pytest 会自动将这个函数展开成 4 个独立的测试用例来执行并在报告里清晰显示每条数据对应的结果。这极大地提升了测试覆盖率和代码复用度。3.3 元素定位策略告别“选择器地狱”UI 自动化测试最不稳定的一环就是元素定位。页面结构一变你的 CSS 选择器可能就失效了。Playwright 提供了一系列面向用户的定位器优先级应该从高到低如下get_by_role()通过 ARIA 角色定位如button、link、textbox。这是最推荐的方式因为它最接近用户感知方式且与实现细节解耦。page.get_by_role(button, name登录) page.get_by_role(textbox, name用户名)get_by_text()和get_by_label()通过文本内容或关联的 label 文本定位。page.get_by_text(同意并继续) page.get_by_label(电子邮件地址)get_by_test_id()这是最强力的定位方式。你需要让开发同学在元素上添加data-testid属性如button>page.get_by_test_id(login-submit).click()CSS 和 XPath作为最后的手段。尽量使用有语义的 CSS 选择器避免使用长的、脆弱的 XPath。注意永远优先使用前三种定位器。和前端团队约定使用data-testid是提升自动化测试稳定性的最有效投资。4. 高级实战处理复杂场景与集成当你的测试套件逐渐庞大你会遇到更多挑战如何处理文件上传怎么模拟键盘操作测试报告太丑怎么办别急都有解。4.1 处理常见“棘手”操作文件上传Playwright 让这个曾经很麻烦的操作变得极其简单。# 假设有一个 input typefile 元素 page.locator(input[typefile]).set_input_files(/path/to/your/file.jpg) # 甚至可以上传多个文件 page.locator(input[typefile]).set_input_files([file1.jpg, file2.png])键盘与鼠标操作# 键盘操作 page.locator(#search-box).press(ControlA) # 全选 page.locator(#search-box).press(Delete) # 删除 page.keyboard.type(Hello World!) # 直接键盘输入 # 鼠标操作 page.locator(.draggable).hover() # 悬停 page.locator(.draggable).drag_to(page.locator(.drop-target)) # 拖放iframe 处理直接定位到 iframe 内部进行操作。# 通过 iframe 的 name 属性或选择器定位 iframe page.frame(namechat-widget) # 然后在 iframe 上下文里操作 iframe.fill(input, 消息内容) iframe.click(button)4.2 生成漂亮的测试报告pytest 有丰富的报告插件。我最常用的是pytest-html和pytest-allure。安装pytest-htmlpip install pytest-html运行测试并生成报告pytest --htmlreport.html --self-contained-html这会生成一个独立的report.html文件打开后可以看到清晰的测试结果汇总、通过/失败列表甚至每个失败用例的截图需要额外配置。对于团队分享和问题追溯非常有用。如果你想更专业可以集成 Allure2它能生成非常炫酷的交互式报告展示测试趋势、环境信息等。4.3 集成到 CI/CD 流水线自动化测试只有集成到持续集成/持续部署流程中才能最大化其价值。以 GitHub Actions 为例一个简单的.github/workflows/test.yml配置如下name: Web Automation Tests on: [push, pull_request] jobs: test: runs-on: ubuntu-latest steps: - uses: actions/checkoutv3 - name: Set up Python uses: actions/setup-pythonv4 with: python-version: 3.10 - name: Install dependencies run: | pip install -r requirements.txt playwright install --with-deps chromium # 在CI中通常只安装一个浏览器以加快速度 - name: Run tests run: | pytest --htmlreport.html --self-contained-html - name: Upload test report uses: actions/upload-artifactv3 with: name: html-report path: report.html这个配置会在每次代码推送或拉取请求时自动在一个干净的 Ubuntu 环境中安装依赖、运行你的 pytest playwright 测试套件并将生成的 HTML 报告保存为工件供你下载查看。这样代码的质量门禁就建立起来了。5. 避坑指南我踩过的那些“雷”最后分享几个我实际项目中遇到的典型问题和解决方案希望能帮你少走弯路。坑1测试在 CI 上失败本地却成功。原因最常见的是环境差异。CI 服务器是无头headless模式且可能屏幕分辨率、时区、语言环境与本地不同。解决永远在 CI 镜像或配置中明确指定浏览器启动参数。使用viewport设置固定分辨率使用locale设置语言并在 CI 脚本中安装所有必需的浏览器依赖playwright install --with-deps。另外在本地也尽量用headlessTrue模式跑一遍提前发现问题。坑2元素定位器偶尔失效报TimeoutError。原因除了页面真的加载慢更多时候是动态内容如 Vue/React 组件还没完全渲染好或者元素被遮挡、状态未改变。解决首先检查是否使用了推荐的get_by_role、get_by_test_id等定位器。其次善用 Playwright 的等待策略而不是粗暴的page.wait_for_timeout(5000)。# 等待元素出现并可交互 element page.locator(button.submit) element.wait_for(stateattached) # 等待附加到DOM element.wait_for(statevisible) # 等待可见 element.wait_for(statehidden) # 等待隐藏 # 或者直接使用带自动等待的操作 element.click() # 这个click内部已经包含了等待可交互的逻辑坑3测试数据互相污染。原因多个测试用例使用了同一个用户账号或者操作了同一份数据导致后续测试失败。解决这就是为什么我们要用BrowserContext见 3.1 节。每个测试函数一个独立的 Context天然隔离。对于更复杂的数据依赖可以考虑在测试开始前通过 API 创建唯一的数据如随机生成用户名测试结束后再清理。坑4异步操作处理不当。原因Playwright 的 API 默认是同步的sync_api但现代网页大量使用异步请求。有时你的断言执行得太快数据还没从服务器返回。解决对于明确需要等待网络请求的场景使用page.wait_for_response()或page.wait_for_request()。# 点击删除按钮并等待对应的API请求完成 with page.expect_response(**/api/item/delete) as response_info: page.click(button.delete) response response_info.value assert response.ok # 然后再断言页面上的元素被移除 expect(page.locator(.item-list)).to_have_count(0)把这些点都注意到你的 pytest playwright 测试套件就能从“能跑”进化到“跑得稳”真正成为项目开发中值得信赖的安全网。这套组合拳打下来你会发现编写和维护自动化测试不再是负担而是一种高效的质量保障手段。