Playwright Python 用了很久之后我最大的感触是自动化测试这行拼的其实不是“会写定位器”而是“会控制整条用例链”。几年前我刚接触自动化时也经历过一条用例要跑30秒、一百条用例要跑一上午、还时不时因为页面加载慢了半拍直接挂掉的阶段。后来把整套 Playwright 测试重新排了一遍没有增加多少新代码只是改变了执行方式和等待策略回归时长就从40多分钟降到了10分钟左右。这让我确信效率提升大部分来自执行策略而不是用例逻辑本身。这篇文章会完整复盘我在业务系统上实践过的5个技巧并行执行与分片、登录态复用、网络层拦截与API造数、智能等待、数据驱动参数化。每个都会给直接能抄的代码也说清楚哪些坑我不希望你再踩。如果你已经能独立写几条 Playwright 用例但整套回归跑起来总感觉“又慢又不稳”这篇基本就是照着操作就能提效。1. 先把“慢”和“不稳”拆开看很多团队一遇到自动化测试效率低第一反应是用例写得有问题于是开始研究更花哨的选择器或者换框架。但我在项目里复盘下来真正拖后腿的往往是执行模型而不是单个选择器。三个瓶颈最典型串行排队。pytest 默认用一个进程、一个浏览器上下文按顺序跑所有用例。前一条用例要等页面加载、等接口返回、等动画走完后一条用例才干等着。一条用例平均15秒一百条就是25分钟这里的等待时间几乎全是“排队”造成的。重复准备。登录、造数、清理数据这些动作如果每次都在 UI 里点就会反复吃掉时间。很多用例真正要断言的功能只有两步却被迫先把登录流程完整走一遍。等待策略低效。time.sleep是最典型的反面教材。等少了在慢机器上会超时等多了在快机器上纯属浪费。用例越多这种固定等待造成的浪费就越明显。如果把这三个问题比作超市收银串行排队等于只开一个收银台重复准备等于每位顾客进店都要重新办会员卡等待策略则是不管队伍多长都按固定节奏慢慢扫码。最终的体验就是一条龙慢吞吞整体更慢。1.1 为什么不能靠“多写断言”解决效率问题有些人会尝试加断言、加长超时来提升稳定性但这只是把问题往后推。断言增加会让单条用例更慢超时加长会让失败用例拖到最后一刻才报错。效率问题的根源在执行架构层面用例如何并行、登录态如何复用、网络请求如何绕过、等待如何自适应。只有这几个维度同时优化才可能接近“效率翻倍”的效果。1.2 五个技巧的总体设计思路我最终在项目里采用的一套组合方案是技巧解决的核心问题直接收益并行执行与分片串行排队回归时间压缩到原来的三分之一甚至更低登录态复用每条用例重新登录每条用例省下5到20秒登录时间网络层拦截与API造数UI前置链路太长减少无关资源加载跳过重复的点击路径智能等待time.sleep硬等快的时候不等慢的时候自动多等稳定性更好数据驱动参数化用例重复、维护成本高一套逻辑覆盖多组场景新增场景不用复制代码这个顺序是我反复调过的。建议先做登录态复用再上并行然后才是网络层和等待策略。原因很简单并行会让用例之间更容易互相干扰如果每条用例还要自己重新登录冲突概率会更高登录态复用之后并行执行的副作用小很多。网络层和智能等待属于“微调加速”在回归能稳定跑通的前提下做收益最明显。2. 技巧一并行执行与分片把排队时间直接砍掉并行是提升整体效率最直接的方法。如果你的用例彼此之间没有共享状态完全可以开多个 worker 同时跑。以前是100条用例排队跑现在4个进程同时跑理论耗时只有原来的四分之一。当然实际不会那么完美机器资源、浏览器进程开销、网络带宽都会带来竞争但即便只压缩掉一半也非常可观。我在一个业务系统的回归套件上做过对比60条用例平均每条大约15秒串行跑完大概15分钟。用4个 worker 并行后平均耗时降到5分半左右用8个 worker 时能到3分多钟但机器内存占用已经接近上限偶尔出现浏览器崩溃。所以“并发数越多越好”在这里并不成立要综合考虑 CPU 核心数和内存容量。2.1 并行执行的前提条件用例隔离并行不是把所有用例堆到一起就能自动变快。前提是每条用例的数据、账号、状态相互隔离。如果两条用例同时操作同一个测试账号一条用例退出登录另一条用例还在页面上执行就会出现大量偶发失败。我在工程里常用的隔离手段有三个。第一数据上尽量不共用单一固定账号而是通过参数化的方式生成每轮独立的数据记录第二引用数据库记录时带上唯一后缀避免重复主键第三如果实在要用共享账号就在写入操作前加锁或串行化不过这通常是下策。判断隔离是否到位的标准很简单把任意一条用例单独拿出来跑和一起跑结果必须一致。如果不一致说明这条用例依赖了别的用例产生的状态并行只会放大这种依赖。2.2 pytest-xdist 配置与常用参数安装依赖pip install pytest-playwright pytest-xdist然后直接跑pytest tests/ -n 4-n 4表示开4个 worker。用例比较多时可以加--dist loadscope让 pytest 按测试模块粒度分配任务而不是在模块之间随机切分。这样同一个模块里的用例尽量由一个 worker 执行能减少模块内共享状态的冲突。pytest tests/ -n 4 --dist loadscope如果还需要更进一步可以按分片方式跑。分片的好处是适合 CI 里多个 job 并行比如你有两台 CI 机器想让它们各跑一半用例可以这样pytest tests/ --shardall --shard-index0 pytest tests/ --shardall --shard-index1第一个 job 只跑分片索引0的用例第二个 job 只跑分片索引1的用例。每个 job 再开自己的 worker最后汇总结果。这个能力在实际项目中很有用因为回归套件往往跑在多个 CI 节点上单机开太多 worker 反而容易内存不足。2.3 并行时最容易踩的坑并行最典型的几个坑我整理成速查数据库唯一性冲突。多条用例同时插入相同主键或相同业务编号就会有一条失败。解决方式是让每条用例生成带时间戳或随机数的数据而不是写死固定值。共享登录会话。并行之后如果所有用例都复用同一个登录态文件但某些用例会修改账号状态就可能互相影响。最好按用例分组准备不同的登录态或者在用例开始前检查登录态。全局变量串台。在模块里定义current_user None供多个用例使用串行时没问题并行时就会互相踩踏。正确的做法是把用户状态放在 fixture 中每个 worker 内部独立创建。浏览器进程资源吃紧。每个 worker 默认启动一个浏览器实例开8个 worker 就意味着至少8个 Chromium 进程。内存不足时会出现浏览器闪退、无响应。建议并发数不超过 CPU 核心数的一半并且给 CI 节点保留足够内存。如果并行后出现偶发失败第一步永远是把并发数调回1跑一遍看看是否稳定。如果串行全过、并行偶挂大概率就是数据或状态隔离没做好。3. 技巧二登录态复用别让每条用例都“从登录页开始”自动化测试效率里最容易被低估的优化点就是登录。很多人觉得登录不过是填两个输入框再点一下按钮能有多少开销但在实际业务系统里登录往往伴随跳转、初始化权限、拉取菜单、加载工作台数据一整套流程下来10到20秒很正常。一百条用例要是每条都重新登录光这一步就吃掉半小时。我有一个比喻这就像每次进图书馆都要在柜台重新办一张读者证。明明你的身份信息没变却反复做同一套核验流程。正确做法是办一次证拿着凭证反复入场。3.1 用 storage_state 保存登录状态Playwright 提供了非常简单的登录态持久化方式storage_state。它会把 cookie、localStorage 等会话信息序列化到文件里下次创建浏览器上下文时直接加载。下面这段代码就是一个基础的登录态生成脚本from playwright.sync_api import sync_playwright with sync_playwright() as p: browser p.chromium.launch(headlessFalse) context browser.new_context() page context.new_page() # 用测试账号完成登录 page.goto(https://your-app.example/login) page.locator(#username).fill(tester01) page.locator(#password).fill(password123) page.locator(button[typesubmit]).click() # 等待登录完成后首页的关键元素出现 page.locator(.home-header).wait_for() page.locator(.user-avatar).wait_for() # 保存登录态 context.storage_state(pathauth_state.json) browser.close()然后在 pytest 的 fixture 里每次创建上下文时把这个文件加载进来import pytest pytest.fixture def authed_page(browser): context browser.new_context(storage_stateauth_state.json) page context.new_page() yield page context.close()之后每条用例直接接收authed_page一上来就进入业务页面不需要再走登录。从全流程看每条用例平均省下10秒以上一百条用例就是一千秒效果非常直接。3.2 登录态失效的几个处理方案登录态不可能永远有效。常见情况是 token 有效期只有2小时用例跑到一半就过期所有用例开始往登录页跳。比较好的做法是加一个登录态检查在 fixture 启动后先访问一个需要登录态的页面如果发现 URL 里出现“login”就不要硬跑后续步骤。def ensure_login(page): if login in page.url: # 尝试重新登录重新生成 storage_state ... context.storage_state(pathauth_state.json)自动刷新登录态属于锦上添花如果你的测试环境 token 有效期够长可以不做。但至少要把报错写得清楚别让一百条用例因为同一次过期全部红掉。3.3 持久化上下文调试阶段的加速器除了storage_statePlaywright 还支持持久化上下文也就是launch_persistent_context。它接收一个本地用户数据目录会把整个浏览器状态保存下来。手动登录一次后后续直接从这个目录启动相当于浏览器记住了全部状态。context p.chromium.launch_persistent_context( user_data_dirmy_user_data, headlessFalse, )这个方案在本地调试时特别顺手。比如要反复调试某条失败用例可以先手动登录一次之后每次跑用例都复用同一个浏览器 profile省去重新登录。但在 CI 环境里我不建议用这个模式用户数据目录是本地文件并发时多个 worker 共用一个目录会互相冲突而且 CI 节点基本不可能保存持久状态。如果测试环境有多个域名、多个测试账号建议为每个环境单独生成一份auth_state.json。不同环境的 cookie 和 token 不能混用否则会出现“本地环境能登录测试环境却显示未授权”的奇怪现象。4. 技巧三网络层“作弊”——拦截请求和 API 造数Playwright 真正强的地方在于它不只是 UI 自动化工具它还能在浏览器层面拦截和重放网络请求。这意味着我们可以做到让页面只加载需要的东西、用 API 直接造数据、把后端故障模拟出来。这些操作如果放到非浏览器级工具里做会很复杂在 Playwright 里却是一两行代码的事。4.1 让页面只加载“真正需要”的资源业务系统尤其是管理后台页面往往加载大量非关键资源统计脚本、埋点脚本、第三方字体、大图占位、轮播图。这些资源不仅拖慢页面加载还经常成为网络波动导致超时的来源。在大多数用例里我们只关心功能元素和接口数据所以可以按resource_type做粗粒度拦截。def block_unused(route): if route.request.resource_type in (image, font, stylesheet): route.abort() else: route.continue_() page.route(**/*, block_unused)这段代码会把图片、字体、样式表直接阻断页面不会为了下载这些资源白白等待。但注意要验证页面视觉样式的用例不要这么干否则截图出来就是“裸奔”的页面。如果只想屏蔽某一类广告域名也可以用更精准的白名单方式page.route(https://tracking.example.com/**, lambda route: route.abort())4.2 用 API 请求代替 UI 造数很多用例的前置条件极长。比如测试订单取消功能如果用 UI 造一个订单得先登商品页、加购物车、提交订单、确认支付每一步都可能因为页面变化而失败。更高效的做法是直接用 API 把订单创建出来再通过 UI 去验证取消流程。Playwright 的request对象可以直接发接口请求with sync_playwright() as p: request p.request.new_context(base_urlhttps://api.example.com) resp request.post(/api/orders, data{ product_id: 10001, count: 2, customer: tester01 }) assert resp.ok, f创建订单失败: {resp.status} order_id resp.json()[order_id] # 接下来把 order_id 传入 UI 用例这个过程非常快几乎没有等待也不依赖页面元素定位。UI 只负责从创建好的订单状态开始验证整个用例的稳定性会明显提升。4.3 用路由拦截模拟异常场景测试第三方支付失败、后端返回500、接口超时这类场景时我们通常不想等真实故障发生。用route.fulfill可以把请求直接改写成一个模拟响应page.route(**/api/payment, lambda route: route.fulfill( status503, content_typeapplication/json, body{error:service unavailable} ))当页面发起支付请求时这个拦截会替代真实请求返回503。前端如果正确处理了异常就会展示报错提示。这样用例可以天天验证异常分支不用依赖外部环境。4.4 网络层技巧的边界和注意事项网络层“作弊”虽然好用但有几个坑必须注意。第一拦截规则别太粗暴。如果把所有请求都拦截掉页面拿不到任何数据自然就白屏了。我见过有人为了加速直接page.route(**/*, abort)结果整套业务页面全挂。更合理的做法是按资源类型或域名做白名单式拦截。第二对需要验证真实后端的用例不要用fulfill。比如要验证下单后的库存扣减应该让它真实请求后端否则测的是假数据不是真实业务链路。第三用 API 造数时要考虑幂等性。每次跑用例都创建订单数据库里会积累一堆测试数据。建议在用例结束后调用接口清理或者至少约定好测试数据的命名规则方便后续批量处理。5. 技巧四告别 time.sleep把等待交给 Playwright 的自动等待我见过太多 Playwright 测试代码里密密麻麻写着time.sleep(3)。这种代码最大的问题是它不知道页面现在到底快还是慢。页面3秒加载完它非要等5秒页面10秒才加载完它3秒就点按钮又超时。效率与稳定永远不能兼得。Playwright 的设计理念是“操作前自动等待”。click、fill这些动作在执行前都会检查元素的 actionability是否可见、是否稳定、是否可点击、是否可用。如果条件不满足就继续轮询直到超时。换句话说快的时候它不浪费一秒慢的时候它自己多等。5.1 用 expect 替代 sleepWeb-first 断言是 Playwright 官方强烈推荐的方式。以前你可能写time.sleep(2) assert page.locator(.toast).is_visible()现在可以直接写from playwright.sync_api import expect expect(page.locator(.toast)).to_be_visible(timeout10000)这行代码最多等10秒只要 toast 出现就立即通过没有多余的固定等待。再比如等待表格从0行变成5行可以写expect(page.locator(.table-row)).to_have_count(5)这比sleep(3)再数行数精确得多而且不会因为机器性能波动产生随机失败。5.2 用 expect.poll 做自定义轮询有些状态不在 DOM 里比如要等一个接口返回某个字段或者等一个异步任务把本地状态改掉。可以用expect.poll实现平滑轮询def get_order_status(): resp page.request.get(/api/order/10001) return resp.json()[status] expect.poll(get_order_status, timeout15000).to_equal(DONE)它会每隔一段时间调用一次get_order_status直到返回值等于DONE或超时。这种方式比“sleep 5秒然后检查一次”靠谱得多既不会在快机器上白白等待也不会在慢机器上漏掉变化。5.3 什么时候可以保留少量固定等待我并不是说time.sleep完全不能用。在一些特殊交互上比如 CSS 动画、地图渲染、图表绘制Playwright 的自动等待可能检查不到“动画是否播放完毕”。这种情况下我通常先尝试expect(locator).to_be_stable()如果它确实无法准确表示动画结束再考虑用page.wait_for_timeout(100)这种短等待兜底。但有一条红线固定等待只允许作为“补充等待”不能成为主等待策略。一旦用例里出现超过两三个sleep(3)基本说明没有找到正确的等待锚点。正确锚点通常是页面上的某个关键元素、某个接口返回或者某个业务状态变化。6. 技巧五数据驱动与参数化让同一套用例跑通多组场景前面四个技巧解决的是“怎么跑得快”数据驱动解决的则是“怎么少写、好维护”。业务测试里经常出现这种情况登录失败要覆盖5组账号注册流程要校验手机号、邮箱、用户名三种方式。如果每个场景都复制一遍用例代码文件会迅速膨胀改一个共性逻辑就要改几十处。6.1 用 parametrize 把多组数据灌进同一套用例pytest 的参数化功能可以直接生成多条测试项每条对应一组参数import pytest pytest.mark.parametrize(username,password,error, [ (tester01, wrong_password, 密码错误), (ghost_user, pass123, 用户不存在), (, pass123, 请输入用户名), ]) def test_login_failure(authed_page, username, password, error): page authed_page page.goto(/login) page.locator(#username).fill(username) page.locator(#password).fill(password) page.locator(button[typesubmit]).click() expect(page.locator(.error-msg)).to_contain_text(error)这三组参数会生成三条独立用例任何一组失败都只影响自己不会拖垮其他组。新增一个场景只需要在参数列表里加一组数据代码零改动。6.2 从外部文件读取测试数据如果参数很多直接把数据写在测试代码里不太方便维护。可以把数据放到 JSON 或 YAML 文件里import json import pytest with open(data/login_cases.json, encodingutf-8) as f: login_cases json.load(f) pytest.mark.parametrize(case, login_cases) def test_login_failure(authed_page, case): username case[username] password case[password] error case[error] ...这样业务同事可以单独维护测试数据不接触代码。数据文件和用例代码分开后管理成本会低很多。但要注意数据文件最好纳入版本管理并且每组数据要有可读的标识。6.3 数据驱动最常见的几个坑参数化也不是越多越好。第一参数组合一旦爆炸执行时间会成倍增加所以要按风险等级筛选关键组合而不是把笛卡尔积全跑一遍。第二每组用例需要有清晰的名字否则失败报告里全是test_login_failure[case0]这种看不出问题的 ID。可以用pytest.mark.parametrize里的ids参数为每组数据起名。第三数据组之间不要共享可变状态比如一个列表在用例 A 里被清空用例 B 再读时就变成了空列表。7. 常见问题与排查技巧实录上面五招组合使用后测试速度会明显提升但也会带来一些新的不稳定因素。我把实操中见过的最典型的几个问题列出来同时附上排查思路。7.1 并行之后用例之间互相“打架”并行前全部通过并行后随机挂几条单独重跑挂掉的用例又全过。这是典型的共享数据或共享账号问题。排查第一步是把并发数调回1确认用例本身没问题第二步看挂掉的用例有没有操作同一个账号、同一条记录第三步为每条用例生成唯一数据比如用户名加时间戳后缀。import random import time unique_user fuser_{int(time.time())}_{random.randint(1000, 9999)}这里的关键是让唯一值进入测试数据而不是写死在代码里。否则再跑一轮同样的冲突还是会复现。7.2 路由拦截后页面白屏加了route(**/*, block_func)后页面加载出来是空白。多半是拦截规则把接口请求也拦掉了。打开浏览器控制台看网络面板或者用page.on(request)打印被拦截的请求就能发现resource_type是什么。我习惯只屏蔽image、font、stylesheet、media这类非核心资源script和xhr尽量放行因为它们往往是页面数据的来源。7.3 auth_state.json 经常失效登录态文件刚生成时好用跑了几条用例后全跳回登录页。常见原因是 token 有效期太短或者测试环境会主动吊销登录态。我的对策是把登录态生成做成一个独立脚本在 CI 里每次跑测试前重新生成一遍同时让 fixture 检查登录是否成功如果第一条用例就发现跳登录页直接抛出错并附上重新生成登录态的命令而不是默默失败一百条。7.4 用例偶发失败又找不到原因这种情况下最好的工具是 Playwright 本身的 trace。每次失败都会生成一个 zip 包里面记录了页面截图、DOM 快照和所有网络请求。你打开 trace 就能看到失败前那一刻页面长什么样、请求到底有没有发出去、最后死在哪个操作上。开启 trace 的推荐方式context browser.new_context( storage_stateauth_state.json, traceon, )失败后保留 trace 文件没失败的用例可以不用。有了 trace排查偶发问题的效率会高很多而不是靠“多跑几次碰运气”。7.5 加并行后机器内存不够pytest -n 8跑着跑着浏览器崩溃。每个 Playwright worker 至少会拉起一个 Chromium 渲染进程8个 worker 的峰值内存很容易超过10G。如果 CI 节点只有8G内存建议-n 4或者更少。还可以通过--max-worker-restart允许 pytest 在 worker 无响应时自动重启但这只能兜底真正解决还是控制并发数。8. 一点个人体会这五个技巧单独拿出来都不复杂但真正在项目里组合起来需要一个循序渐进的过程。我自己落地时采用的顺序是先做登录态复用再全面替换掉time.sleep然后开并行之后加网络层拦截和 API 造数最后才是参数化。每做完一步都能看到明确的收益也容易回滚。8.1 一定要先保住“可观测性”效率优化的前提是你还能看清每一步发生了什么。我见过有些团队为了快把所有日志、截图、trace 都关掉结果出了问题只能靠猜。我的建议是不管并行还是拦截都要保证失败用例至少留下足够的信息。Playwright 的 trace 和完整截图是性价比最高的投资这套能力远比快十秒重要。8.2 留给团队一套可以复制的模板当某一套配置在一两个项目里验证成功我会把它抽成模板。新项目接入 Playwright 时直接复制这些 fixture、pytest 配置、登录态生成脚本半小时之内就能跑起第一条高效用例。这样一来效率优化就不是短期行为而是团队持续受益的资产。如果你也想在自己项目里做同样的事我的建议是先选一个中等规模的回归套件试点别一上来就追求8个 worker 全开。先把登录态复用、自动等待这两步做完让套件从“能跑”变成“稳跑”再逐步加入并行、拦截和参数化。回头再看回归时间的变化你可能会和我一样惊讶原来这几步组合起来真的可以让自动化测试效率翻倍。 
长河君 · 2026/10/18 8:27:42 · 阅读 1.2k Playwright自动化测试效率优化：五个实战策略让回归提速
Playwright Python 用了很久之后我最大的感触是自动化测试这行拼的其实不是“会写定位器”而是“会控制整条用例链”。几年前我刚接触自动化时也经历过一条用例要跑30秒、一百条用例要跑一上午、还时不时因为页面加载慢了半拍直接挂掉的阶段。后来把整套 Playwright 测试重新排了一遍没有增加多少新代码只是改变了执行方式和等待策略回归时长就从40多分钟降到了10分钟左右。这让我确信效率提升大部分来自执行策略而不是用例逻辑本身。这篇文章会完整复盘我在业务系统上实践过的5个技巧并行执行与分片、登录态复用、网络层拦截与API造数、智能等待、数据驱动参数化。每个都会给直接能抄的代码也说清楚哪些坑我不希望你再踩。如果你已经能独立写几条 Playwright 用例但整套回归跑起来总感觉“又慢又不稳”这篇基本就是照着操作就能提效。1. 先把“慢”和“不稳”拆开看很多团队一遇到自动化测试效率低第一反应是用例写得有问题于是开始研究更花哨的选择器或者换框架。但我在项目里复盘下来真正拖后腿的往往是执行模型而不是单个选择器。三个瓶颈最典型串行排队。pytest 默认用一个进程、一个浏览器上下文按顺序跑所有用例。前一条用例要等页面加载、等接口返回、等动画走完后一条用例才干等着。一条用例平均15秒一百条就是25分钟这里的等待时间几乎全是“排队”造成的。重复准备。登录、造数、清理数据这些动作如果每次都在 UI 里点就会反复吃掉时间。很多用例真正要断言的功能只有两步却被迫先把登录流程完整走一遍。等待策略低效。time.sleep是最典型的反面教材。等少了在慢机器上会超时等多了在快机器上纯属浪费。用例越多这种固定等待造成的浪费就越明显。如果把这三个问题比作超市收银串行排队等于只开一个收银台重复准备等于每位顾客进店都要重新办会员卡等待策略则是不管队伍多长都按固定节奏慢慢扫码。最终的体验就是一条龙慢吞吞整体更慢。1.1 为什么不能靠“多写断言”解决效率问题有些人会尝试加断言、加长超时来提升稳定性但这只是把问题往后推。断言增加会让单条用例更慢超时加长会让失败用例拖到最后一刻才报错。效率问题的根源在执行架构层面用例如何并行、登录态如何复用、网络请求如何绕过、等待如何自适应。只有这几个维度同时优化才可能接近“效率翻倍”的效果。1.2 五个技巧的总体设计思路我最终在项目里采用的一套组合方案是技巧解决的核心问题直接收益并行执行与分片串行排队回归时间压缩到原来的三分之一甚至更低登录态复用每条用例重新登录每条用例省下5到20秒登录时间网络层拦截与API造数UI前置链路太长减少无关资源加载跳过重复的点击路径智能等待time.sleep硬等快的时候不等慢的时候自动多等稳定性更好数据驱动参数化用例重复、维护成本高一套逻辑覆盖多组场景新增场景不用复制代码这个顺序是我反复调过的。建议先做登录态复用再上并行然后才是网络层和等待策略。原因很简单并行会让用例之间更容易互相干扰如果每条用例还要自己重新登录冲突概率会更高登录态复用之后并行执行的副作用小很多。网络层和智能等待属于“微调加速”在回归能稳定跑通的前提下做收益最明显。2. 技巧一并行执行与分片把排队时间直接砍掉并行是提升整体效率最直接的方法。如果你的用例彼此之间没有共享状态完全可以开多个 worker 同时跑。以前是100条用例排队跑现在4个进程同时跑理论耗时只有原来的四分之一。当然实际不会那么完美机器资源、浏览器进程开销、网络带宽都会带来竞争但即便只压缩掉一半也非常可观。我在一个业务系统的回归套件上做过对比60条用例平均每条大约15秒串行跑完大概15分钟。用4个 worker 并行后平均耗时降到5分半左右用8个 worker 时能到3分多钟但机器内存占用已经接近上限偶尔出现浏览器崩溃。所以“并发数越多越好”在这里并不成立要综合考虑 CPU 核心数和内存容量。2.1 并行执行的前提条件用例隔离并行不是把所有用例堆到一起就能自动变快。前提是每条用例的数据、账号、状态相互隔离。如果两条用例同时操作同一个测试账号一条用例退出登录另一条用例还在页面上执行就会出现大量偶发失败。我在工程里常用的隔离手段有三个。第一数据上尽量不共用单一固定账号而是通过参数化的方式生成每轮独立的数据记录第二引用数据库记录时带上唯一后缀避免重复主键第三如果实在要用共享账号就在写入操作前加锁或串行化不过这通常是下策。判断隔离是否到位的标准很简单把任意一条用例单独拿出来跑和一起跑结果必须一致。如果不一致说明这条用例依赖了别的用例产生的状态并行只会放大这种依赖。2.2 pytest-xdist 配置与常用参数安装依赖pip install pytest-playwright pytest-xdist然后直接跑pytest tests/ -n 4-n 4表示开4个 worker。用例比较多时可以加--dist loadscope让 pytest 按测试模块粒度分配任务而不是在模块之间随机切分。这样同一个模块里的用例尽量由一个 worker 执行能减少模块内共享状态的冲突。pytest tests/ -n 4 --dist loadscope如果还需要更进一步可以按分片方式跑。分片的好处是适合 CI 里多个 job 并行比如你有两台 CI 机器想让它们各跑一半用例可以这样pytest tests/ --shardall --shard-index0 pytest tests/ --shardall --shard-index1第一个 job 只跑分片索引0的用例第二个 job 只跑分片索引1的用例。每个 job 再开自己的 worker最后汇总结果。这个能力在实际项目中很有用因为回归套件往往跑在多个 CI 节点上单机开太多 worker 反而容易内存不足。2.3 并行时最容易踩的坑并行最典型的几个坑我整理成速查数据库唯一性冲突。多条用例同时插入相同主键或相同业务编号就会有一条失败。解决方式是让每条用例生成带时间戳或随机数的数据而不是写死固定值。共享登录会话。并行之后如果所有用例都复用同一个登录态文件但某些用例会修改账号状态就可能互相影响。最好按用例分组准备不同的登录态或者在用例开始前检查登录态。全局变量串台。在模块里定义current_user None供多个用例使用串行时没问题并行时就会互相踩踏。正确的做法是把用户状态放在 fixture 中每个 worker 内部独立创建。浏览器进程资源吃紧。每个 worker 默认启动一个浏览器实例开8个 worker 就意味着至少8个 Chromium 进程。内存不足时会出现浏览器闪退、无响应。建议并发数不超过 CPU 核心数的一半并且给 CI 节点保留足够内存。如果并行后出现偶发失败第一步永远是把并发数调回1跑一遍看看是否稳定。如果串行全过、并行偶挂大概率就是数据或状态隔离没做好。3. 技巧二登录态复用别让每条用例都“从登录页开始”自动化测试效率里最容易被低估的优化点就是登录。很多人觉得登录不过是填两个输入框再点一下按钮能有多少开销但在实际业务系统里登录往往伴随跳转、初始化权限、拉取菜单、加载工作台数据一整套流程下来10到20秒很正常。一百条用例要是每条都重新登录光这一步就吃掉半小时。我有一个比喻这就像每次进图书馆都要在柜台重新办一张读者证。明明你的身份信息没变却反复做同一套核验流程。正确做法是办一次证拿着凭证反复入场。3.1 用 storage_state 保存登录状态Playwright 提供了非常简单的登录态持久化方式storage_state。它会把 cookie、localStorage 等会话信息序列化到文件里下次创建浏览器上下文时直接加载。下面这段代码就是一个基础的登录态生成脚本from playwright.sync_api import sync_playwright with sync_playwright() as p: browser p.chromium.launch(headlessFalse) context browser.new_context() page context.new_page() # 用测试账号完成登录 page.goto(https://your-app.example/login) page.locator(#username).fill(tester01) page.locator(#password).fill(password123) page.locator(button[typesubmit]).click() # 等待登录完成后首页的关键元素出现 page.locator(.home-header).wait_for() page.locator(.user-avatar).wait_for() # 保存登录态 context.storage_state(pathauth_state.json) browser.close()然后在 pytest 的 fixture 里每次创建上下文时把这个文件加载进来import pytest pytest.fixture def authed_page(browser): context browser.new_context(storage_stateauth_state.json) page context.new_page() yield page context.close()之后每条用例直接接收authed_page一上来就进入业务页面不需要再走登录。从全流程看每条用例平均省下10秒以上一百条用例就是一千秒效果非常直接。3.2 登录态失效的几个处理方案登录态不可能永远有效。常见情况是 token 有效期只有2小时用例跑到一半就过期所有用例开始往登录页跳。比较好的做法是加一个登录态检查在 fixture 启动后先访问一个需要登录态的页面如果发现 URL 里出现“login”就不要硬跑后续步骤。def ensure_login(page): if login in page.url: # 尝试重新登录重新生成 storage_state ... context.storage_state(pathauth_state.json)自动刷新登录态属于锦上添花如果你的测试环境 token 有效期够长可以不做。但至少要把报错写得清楚别让一百条用例因为同一次过期全部红掉。3.3 持久化上下文调试阶段的加速器除了storage_statePlaywright 还支持持久化上下文也就是launch_persistent_context。它接收一个本地用户数据目录会把整个浏览器状态保存下来。手动登录一次后后续直接从这个目录启动相当于浏览器记住了全部状态。context p.chromium.launch_persistent_context( user_data_dirmy_user_data, headlessFalse, )这个方案在本地调试时特别顺手。比如要反复调试某条失败用例可以先手动登录一次之后每次跑用例都复用同一个浏览器 profile省去重新登录。但在 CI 环境里我不建议用这个模式用户数据目录是本地文件并发时多个 worker 共用一个目录会互相冲突而且 CI 节点基本不可能保存持久状态。如果测试环境有多个域名、多个测试账号建议为每个环境单独生成一份auth_state.json。不同环境的 cookie 和 token 不能混用否则会出现“本地环境能登录测试环境却显示未授权”的奇怪现象。4. 技巧三网络层“作弊”——拦截请求和 API 造数Playwright 真正强的地方在于它不只是 UI 自动化工具它还能在浏览器层面拦截和重放网络请求。这意味着我们可以做到让页面只加载需要的东西、用 API 直接造数据、把后端故障模拟出来。这些操作如果放到非浏览器级工具里做会很复杂在 Playwright 里却是一两行代码的事。4.1 让页面只加载“真正需要”的资源业务系统尤其是管理后台页面往往加载大量非关键资源统计脚本、埋点脚本、第三方字体、大图占位、轮播图。这些资源不仅拖慢页面加载还经常成为网络波动导致超时的来源。在大多数用例里我们只关心功能元素和接口数据所以可以按resource_type做粗粒度拦截。def block_unused(route): if route.request.resource_type in (image, font, stylesheet): route.abort() else: route.continue_() page.route(**/*, block_unused)这段代码会把图片、字体、样式表直接阻断页面不会为了下载这些资源白白等待。但注意要验证页面视觉样式的用例不要这么干否则截图出来就是“裸奔”的页面。如果只想屏蔽某一类广告域名也可以用更精准的白名单方式page.route(https://tracking.example.com/**, lambda route: route.abort())4.2 用 API 请求代替 UI 造数很多用例的前置条件极长。比如测试订单取消功能如果用 UI 造一个订单得先登商品页、加购物车、提交订单、确认支付每一步都可能因为页面变化而失败。更高效的做法是直接用 API 把订单创建出来再通过 UI 去验证取消流程。Playwright 的request对象可以直接发接口请求with sync_playwright() as p: request p.request.new_context(base_urlhttps://api.example.com) resp request.post(/api/orders, data{ product_id: 10001, count: 2, customer: tester01 }) assert resp.ok, f创建订单失败: {resp.status} order_id resp.json()[order_id] # 接下来把 order_id 传入 UI 用例这个过程非常快几乎没有等待也不依赖页面元素定位。UI 只负责从创建好的订单状态开始验证整个用例的稳定性会明显提升。4.3 用路由拦截模拟异常场景测试第三方支付失败、后端返回500、接口超时这类场景时我们通常不想等真实故障发生。用route.fulfill可以把请求直接改写成一个模拟响应page.route(**/api/payment, lambda route: route.fulfill( status503, content_typeapplication/json, body{error:service unavailable} ))当页面发起支付请求时这个拦截会替代真实请求返回503。前端如果正确处理了异常就会展示报错提示。这样用例可以天天验证异常分支不用依赖外部环境。4.4 网络层技巧的边界和注意事项网络层“作弊”虽然好用但有几个坑必须注意。第一拦截规则别太粗暴。如果把所有请求都拦截掉页面拿不到任何数据自然就白屏了。我见过有人为了加速直接page.route(**/*, abort)结果整套业务页面全挂。更合理的做法是按资源类型或域名做白名单式拦截。第二对需要验证真实后端的用例不要用fulfill。比如要验证下单后的库存扣减应该让它真实请求后端否则测的是假数据不是真实业务链路。第三用 API 造数时要考虑幂等性。每次跑用例都创建订单数据库里会积累一堆测试数据。建议在用例结束后调用接口清理或者至少约定好测试数据的命名规则方便后续批量处理。5. 技巧四告别 time.sleep把等待交给 Playwright 的自动等待我见过太多 Playwright 测试代码里密密麻麻写着time.sleep(3)。这种代码最大的问题是它不知道页面现在到底快还是慢。页面3秒加载完它非要等5秒页面10秒才加载完它3秒就点按钮又超时。效率与稳定永远不能兼得。Playwright 的设计理念是“操作前自动等待”。click、fill这些动作在执行前都会检查元素的 actionability是否可见、是否稳定、是否可点击、是否可用。如果条件不满足就继续轮询直到超时。换句话说快的时候它不浪费一秒慢的时候它自己多等。5.1 用 expect 替代 sleepWeb-first 断言是 Playwright 官方强烈推荐的方式。以前你可能写time.sleep(2) assert page.locator(.toast).is_visible()现在可以直接写from playwright.sync_api import expect expect(page.locator(.toast)).to_be_visible(timeout10000)这行代码最多等10秒只要 toast 出现就立即通过没有多余的固定等待。再比如等待表格从0行变成5行可以写expect(page.locator(.table-row)).to_have_count(5)这比sleep(3)再数行数精确得多而且不会因为机器性能波动产生随机失败。5.2 用 expect.poll 做自定义轮询有些状态不在 DOM 里比如要等一个接口返回某个字段或者等一个异步任务把本地状态改掉。可以用expect.poll实现平滑轮询def get_order_status(): resp page.request.get(/api/order/10001) return resp.json()[status] expect.poll(get_order_status, timeout15000).to_equal(DONE)它会每隔一段时间调用一次get_order_status直到返回值等于DONE或超时。这种方式比“sleep 5秒然后检查一次”靠谱得多既不会在快机器上白白等待也不会在慢机器上漏掉变化。5.3 什么时候可以保留少量固定等待我并不是说time.sleep完全不能用。在一些特殊交互上比如 CSS 动画、地图渲染、图表绘制Playwright 的自动等待可能检查不到“动画是否播放完毕”。这种情况下我通常先尝试expect(locator).to_be_stable()如果它确实无法准确表示动画结束再考虑用page.wait_for_timeout(100)这种短等待兜底。但有一条红线固定等待只允许作为“补充等待”不能成为主等待策略。一旦用例里出现超过两三个sleep(3)基本说明没有找到正确的等待锚点。正确锚点通常是页面上的某个关键元素、某个接口返回或者某个业务状态变化。6. 技巧五数据驱动与参数化让同一套用例跑通多组场景前面四个技巧解决的是“怎么跑得快”数据驱动解决的则是“怎么少写、好维护”。业务测试里经常出现这种情况登录失败要覆盖5组账号注册流程要校验手机号、邮箱、用户名三种方式。如果每个场景都复制一遍用例代码文件会迅速膨胀改一个共性逻辑就要改几十处。6.1 用 parametrize 把多组数据灌进同一套用例pytest 的参数化功能可以直接生成多条测试项每条对应一组参数import pytest pytest.mark.parametrize(username,password,error, [ (tester01, wrong_password, 密码错误), (ghost_user, pass123, 用户不存在), (, pass123, 请输入用户名), ]) def test_login_failure(authed_page, username, password, error): page authed_page page.goto(/login) page.locator(#username).fill(username) page.locator(#password).fill(password) page.locator(button[typesubmit]).click() expect(page.locator(.error-msg)).to_contain_text(error)这三组参数会生成三条独立用例任何一组失败都只影响自己不会拖垮其他组。新增一个场景只需要在参数列表里加一组数据代码零改动。6.2 从外部文件读取测试数据如果参数很多直接把数据写在测试代码里不太方便维护。可以把数据放到 JSON 或 YAML 文件里import json import pytest with open(data/login_cases.json, encodingutf-8) as f: login_cases json.load(f) pytest.mark.parametrize(case, login_cases) def test_login_failure(authed_page, case): username case[username] password case[password] error case[error] ...这样业务同事可以单独维护测试数据不接触代码。数据文件和用例代码分开后管理成本会低很多。但要注意数据文件最好纳入版本管理并且每组数据要有可读的标识。6.3 数据驱动最常见的几个坑参数化也不是越多越好。第一参数组合一旦爆炸执行时间会成倍增加所以要按风险等级筛选关键组合而不是把笛卡尔积全跑一遍。第二每组用例需要有清晰的名字否则失败报告里全是test_login_failure[case0]这种看不出问题的 ID。可以用pytest.mark.parametrize里的ids参数为每组数据起名。第三数据组之间不要共享可变状态比如一个列表在用例 A 里被清空用例 B 再读时就变成了空列表。7. 常见问题与排查技巧实录上面五招组合使用后测试速度会明显提升但也会带来一些新的不稳定因素。我把实操中见过的最典型的几个问题列出来同时附上排查思路。7.1 并行之后用例之间互相“打架”并行前全部通过并行后随机挂几条单独重跑挂掉的用例又全过。这是典型的共享数据或共享账号问题。排查第一步是把并发数调回1确认用例本身没问题第二步看挂掉的用例有没有操作同一个账号、同一条记录第三步为每条用例生成唯一数据比如用户名加时间戳后缀。import random import time unique_user fuser_{int(time.time())}_{random.randint(1000, 9999)}这里的关键是让唯一值进入测试数据而不是写死在代码里。否则再跑一轮同样的冲突还是会复现。7.2 路由拦截后页面白屏加了route(**/*, block_func)后页面加载出来是空白。多半是拦截规则把接口请求也拦掉了。打开浏览器控制台看网络面板或者用page.on(request)打印被拦截的请求就能发现resource_type是什么。我习惯只屏蔽image、font、stylesheet、media这类非核心资源script和xhr尽量放行因为它们往往是页面数据的来源。7.3 auth_state.json 经常失效登录态文件刚生成时好用跑了几条用例后全跳回登录页。常见原因是 token 有效期太短或者测试环境会主动吊销登录态。我的对策是把登录态生成做成一个独立脚本在 CI 里每次跑测试前重新生成一遍同时让 fixture 检查登录是否成功如果第一条用例就发现跳登录页直接抛出错并附上重新生成登录态的命令而不是默默失败一百条。7.4 用例偶发失败又找不到原因这种情况下最好的工具是 Playwright 本身的 trace。每次失败都会生成一个 zip 包里面记录了页面截图、DOM 快照和所有网络请求。你打开 trace 就能看到失败前那一刻页面长什么样、请求到底有没有发出去、最后死在哪个操作上。开启 trace 的推荐方式context browser.new_context( storage_stateauth_state.json, traceon, )失败后保留 trace 文件没失败的用例可以不用。有了 trace排查偶发问题的效率会高很多而不是靠“多跑几次碰运气”。7.5 加并行后机器内存不够pytest -n 8跑着跑着浏览器崩溃。每个 Playwright worker 至少会拉起一个 Chromium 渲染进程8个 worker 的峰值内存很容易超过10G。如果 CI 节点只有8G内存建议-n 4或者更少。还可以通过--max-worker-restart允许 pytest 在 worker 无响应时自动重启但这只能兜底真正解决还是控制并发数。8. 一点个人体会这五个技巧单独拿出来都不复杂但真正在项目里组合起来需要一个循序渐进的过程。我自己落地时采用的顺序是先做登录态复用再全面替换掉time.sleep然后开并行之后加网络层拦截和 API 造数最后才是参数化。每做完一步都能看到明确的收益也容易回滚。8.1 一定要先保住“可观测性”效率优化的前提是你还能看清每一步发生了什么。我见过有些团队为了快把所有日志、截图、trace 都关掉结果出了问题只能靠猜。我的建议是不管并行还是拦截都要保证失败用例至少留下足够的信息。Playwright 的 trace 和完整截图是性价比最高的投资这套能力远比快十秒重要。8.2 留给团队一套可以复制的模板当某一套配置在一两个项目里验证成功我会把它抽成模板。新项目接入 Playwright 时直接复制这些 fixture、pytest 配置、登录态生成脚本半小时之内就能跑起第一条高效用例。这样一来效率优化就不是短期行为而是团队持续受益的资产。如果你也想在自己项目里做同样的事我的建议是先选一个中等规模的回归套件试点别一上来就追求8个 worker 全开。先把登录态复用、自动等待这两步做完让套件从“能跑”变成“稳跑”再逐步加入并行、拦截和参数化。回头再看回归时间的变化你可能会和我一样惊讶原来这几步组合起来真的可以让自动化测试效率翻倍。