当前位置：首页 > web >正文

【PlayWright】自动化测试框架机制详解

web 2025/9/4 16:22:06

注意: 本文在 AI 问答的基础上所书写, 主要目的为了简单了解框架背后的机制,
如有不妥之处欢迎批评指正~

一、Playwright 自动化测试框架详解

Playwright 是一个现代化的端到端网页测试框架，由微软开发并开源。它支持跨浏览器自动化测试，具有强大的功能和出色的性能。

1.1 Playwright 核心特点

多浏览器支持：
1. Chromium (Chrome/Edge)
2. WebKit (Safari)
3. Firefox
多语言支持：
1. JavaScript/TypeScript
2. Python
3. Java
4. .NET
自动等待机制：
1. 内置智能等待，减少手动添加等待时间的需要
2. 自动等待元素可见、可操作
网络拦截：
1. 模拟网络条件
2. 拦截和修改网络请求
设备模拟：
1. 模拟移动设备、地理位置、权限等

1.2 Playwright 与 Selenium 对比

特性	Playwright	Selenium
架构	直接与浏览器通信	通过驱动通信
执行速度	更快	相对较慢
自动等待	内置	需要手动实现
录制工具	自带Codegen	依赖第三方工具
移动端测试	支持良好	需要Appium
跨域处理	原生支持	有限支持

1.3 Playwright 为何能与浏览器直接通信：架构解析

1.3.1 传统工具的通信瓶颈（以Selenium为例）

在 Selenium 的架构中：

测试脚本 → WebDriver协议 → 浏览器驱动 → 浏览器

多层级通信：需要经过WebDriver协议转换和浏览器驱动中转
协议限制：依赖W3C WebDriver标准协议，功能受限于协议规范
性能损耗：每个操作都需要多次协议转换和进程间通信

1.3.2 Playwright的直连架构

Playwright采用完全不同的方式：

测试脚本 ↔ Playwright库 ↔ Playwright Server ↔ 浏览器

1.3.3 核心实现机制

内置协议控制：
1. Playwright实现了对 Chrome DevTools Protocol (CDP) 的直接利用
2. 对于Firefox和WebKit，Playwright团队维护了类似的私有协议
同进程模型：
1. Playwright启动浏览器时，会注入一个 Playwright控制器到浏览器进程
2. 这个控制器通过WebSocket或管道(pipes)与测试脚本通信
协议扩展：
1. Playwright不仅使用标准CDP，还扩展了自定义协议
2. 可以访问更多浏览器内部能力，如：
  - 精确的输入模拟（包括触摸、手势）
  - 网络拦截和修改
  - 设备模拟（CPU节流、地理位置等）

1.4 Selenium 和 Playwright 在处理 Chrome DevTools Protocol (CDP) 的方式上有显著差异

1.4.1 Playwright 对 CDP 的直接利用

深度集成：
- Playwright 直接通过 CDP 与浏览器通信，绕过 WebDriver 协议，实现了更底层的控制。
- 支持 CDP 的原始命令（如 Network、Performance、DOM 等域），可直接调用 client.send('Network.enable') 这样的方法。
优势：
- 高性能：减少协议转换开销，操作更高效（如网络拦截、文件下载）。
- 丰富功能：直接访问 CDP 的调试能力（如内存快照、CPU 分析、移动设备模拟）。
- 原子操作：支持等待特定 CDP 事件（如 request/response 拦截）。
示例代码（直接调用 CDP）：

const client = await page.context().newCDPSession(page);
await client.send('Network.enable');
client.on('Network.requestWillBeSent', (event) => {console.log('Request:', event.request.url);
});

1.4.2 Selenium 对 CDP 的处理

间接访问：
- Selenium 4 后通过 ChromiumDriver 提供有限的 CDP 集成（需依赖 DevTools 接口）。
- 需要手动启用 CDP 功能（如 execute_cdp_cmd），但覆盖范围有限。
局限性：
- 协议转换：Selenium 的指令需通过 WebDriver 协议转发到 CDP，存在性能损耗。
- 功能缺失：仅支持部分 CDP 命令（如网络控制、地理定位），高级功能（如性能分析）需自行扩展。

1.4.3核心差异对比

特性	Playwright	Selenium
CDP 访问方式	直接原生支持	通过 WebDriver 间接调用（execute_cdp_cmd）
协议层	绕过 WebDriver，直接 CDP	WebDriver + CDP 混合
功能覆盖	完整 CDP 功能（包括实验性 API）	仅限稳定 CDP 命令
性能	更高（无协议转换）	较低（协议转换开销）
调试能力	支持内存分析、性能追踪等高级调试	基础网络拦截、Cookie 操作等
跨浏览器一致性	统一 API 层（Chromium/WebKit/Firefox）	依赖浏览器驱动实现

补充说明

Selenium 的进阶方案：可通过第三方库（如 puppeteer-selenium）混合使用，但维护成本高。
Playwright 的封装：虽然直接暴露 CDP，但上层 API 对常见操作（如截图、录屏）做了简化。

1.5 Chrome DevTools Protocol (CDP) 是什么?

Chrome DevTools Protocol (CDP) 是 Chrome 或其他基于 Chromium 的浏览器（如 Edge、Opera）提供的一个底层调试协议，它允许开发者通过程序化的方式与浏览器内核交互，实现调试、监控或自动化控制浏览器的能力。以下是它的核心解析：

1.5.1 CDP 是什么？

本质： CDP 是一个基于 WebSocket 的通信协议，开发者可以通过发送 JSON 格式的命令与浏览器内核直接对话。（DevTools 的图形界面其实就是通过 CDP 与浏览器通信的。）
功能范围：覆盖浏览器的几乎所有底层操作，例如：
- DOM 操作（获取节点、修改属性）
- 网络控制（拦截请求、修改请求头）
- 性能分析（CPU、内存监控）
- JavaScript 调试（断点、执行上下文）
- 设备模拟（屏幕尺寸、GPS、触摸事件）
- 应用缓存（Service Worker、Cache Storage）

1.5.2 CDP 的工作原理

CDP 的工作原理

通信流程：

graph LRA[客户端（如 Playwright/Puppeteer）] -- WebSocket --> B[浏览器（通过 CDP 端口）]B -- 响应/事件推送 --> A

浏览器启动时会开放一个 WebSocket 端口（默认 9222），客户端通过该端口发送 CDP 命令。
浏览器执行命令后返回结果，或主动推送事件（如网络请求触发 Network.requestWillBeSent）。
协议结构： CDP 按功能分为多个域（Domains），例如：
- Page：控制页面导航、截图。
- Network：管理网络请求。
- Runtime：执行 JavaScript。
- DOM：操作 DOM 树。

1.5.3 如何访问 CDP？

直接使用：通过 WebSocket 客户端手动发送命令（需自行处理协议细节）：

# 启动 Chrome 并开放 CDP 端口
chrome --remote-debugging-port=9222

然后使用工具（如 curl 或 WebSocket 库）连接 ws://localhost:9222。
通过工具库：常用库对 CDP 做了高层封装：
- Playwright/Puppeteer：直接调用 CDP 的底层方法（如 page.evaluateOnNewDocument 背后是 Page.addScriptToEvaluateOnNewDocument 命令）。
- Selenium 4+：通过 execute_cdp_cmd 间接调用有限功能。
核心优势
底层控制能力：比 WebDriver 协议更接近浏览器内核，可实现更精细的操作（如修改 SSL 证书、模拟传感器数据）。
实时事件监听：可订阅浏览器事件（如 Console.messageAdded、CSS.styleSheetAdded）。
跨语言支持： CDP 是语言无关的协议，任何支持 WebSocket 的编程语言均可调用。

1.5.4 与 WebDriver 的对比

特性	CDP	WebDriver
协议层	浏览器内核原生协议	W3C 标准化的自动化协议
功能粒度	精细（可操作单个 DOM 节点）	粗粒度（基于元素定位）
性能	更高（直接通信）	较低（多一层协议转换）
兼容性	仅限 Chromium 系浏览器	跨浏览器（Chrome/Firefox/Safari）