回顾过往：测试自动化的演变

Jecelyn Yeen
Maksim Sadym
Maksim Sadym
X GitHub

测试自动化的诞生

让我们回到 20 世纪 90 年代，那时候网络浏览器诞生了。测试自动化直到 21 世纪 00 年代才成为现实，随着 Selenium 和 WebDriver 项目的出现，它们可以应对跨浏览器和多设备测试挑战。

这两个项目于 2011 年合并为 Selenium WebDriver，并在 2018 年成为 W3C 标准。我们通常将其称为 WebDriver 或 WebDriver“传统版”。

Selenium WebDriver 项目的发展。
Selenium WebDriver 项目的演变

在 WebDriver“Classic”（经典）之前，测试自动化非常困难。将浏览器测试自动化的能力显著提升了开发者和测试人员的生活质量。

JavaScript 的崛起

随着 Web 开发演变为更多依赖 JavaScript，出现了新的自动化解决方案，例如 WebdriverIO、Appium、Nightwatch、Protractor（已弃用）、Testcafe、Cypress、Puppeteer 和 Playwright。

JavaScript 自动化工具。
JavaScript 自动化工具

自动化方法

从广义上讲，这些工具根据实现浏览器自动化的方式可以大体分为两大类：

  • 概要：在浏览器内执行 JavaScript 的工具。例如，Cypress 和 TestCafe 利用网络 API 和 Node.js 直接在浏览器中运行测试。一个有趣的事实 - Selenium 的第一个版本也使用了相同的方法。
  • 低级别：用于在浏览器外部执行远程命令的工具。当工具需要更强的控制力（例如打开多个标签页或模拟设备模式）时，就需要执行远程命令才能通过协议控制浏览器。 两种主要的自动化协议是经典 WebDriver 协议和 Chrome 开发者工具协议 (CDP)。

在下一部分中，我们将探讨这两种协议，以了解它们的优势和局限性。

WebDriver Classic 和 CDP。

WebDriver“Classic”（经典）与 Chrome DevTools Protocol (CDP)

WebDriver“ Classic” 是所有主流浏览器都支持的 Web 标准。自动化脚本通过 HTTP 请求向驱动程序服务器发出命令，然后驱动程序服务器通过浏览器特定的内部协议与浏览器进行通信。

虽然它具有出色的跨浏览器支持并且其 API 是专为测试而设计的，但它可能很慢，并且不支持某些低级控件。

WebDriver“Classic”。
WebDriver“传统版”

例如，假设您有一个点击元素 await coffee.click(); 的测试脚本。系统会将其转换为一系列 HTTP 请求。

# WebDriver: Click on a coffee element

curl -X POST http://127.0.0.1:4444/session/:element_id/element/click
   -H 'Content-Type: application/json'
   -d '{}'

另一方面，Chrome 开发者工具协议 (CDP) 最初是专为 Chrome 开发者工具和调试而设计的，后来被 Puppeteer 采用来实现自动化。CDP 通过 WebSocket 连接直接与基于 Chromium 的浏览器进行通信，从而提高性能和进行低级控制。

但是，它只适用于基于 Chromium 的浏览器，并且不是开放标准。除此之外，CDP API 相对复杂。在某些情况下，使用 CDP 不符合人体工程学。例如，使用进程外 iframe 需要花费很多精力。

CDP。
Chrome 开发者工具协议

例如，点击 await coffee.click(); 元素会转换为一系列 CDP 命令。

// CDP: Click on a coffee element

// Mouse pressed
{ 
  command: 'Input.dispatchMouseEvent', 
  parameters: {
    type: 'mousePressed', x: 10.34, y: 27.1, clickCount: 1 }
}

// Mouse released
{ 
  command: 'Input.dispatchMouseEvent', 
  parameters: {
    type: 'mouseReleased', x: 10.34, y: 27.1, clickCount: 1 }
}

底层控制机制是什么？

在开发 WebDriver“Classic”（经典）的年代，根本不需要进行低级别的控制。但时代变了，网络现在的功能更强大，如今的测试要求更精细的操作。

由于 CDP 旨在满足所有调试需求，因此与“经典”WebDriver 相比，CDP 支持更多的低级别控件。它可以处理如下功能：

  • 捕获控制台消息
  • 拦截网络请求
  • 模拟设备模式
  • 模拟地理定位
  • 还有更多其他奖励！

这些在 WebDriver“Classic”（经典）中无法实现，因为其架构不同 - WebDriver“Classic”（经典 WebDriver）是基于 HTTP 的，因此很难订阅和监听浏览器事件。另一方面，CDP 基于 WebSocket，默认支持双向消息传递。

后续内容：WebDriver BiDi

下面总结了 WebDriver“传统版”和 CDP 的优势：

WebDriver“传统版” Chrome 开发者工具协议 (CDP)
最佳跨浏览器支持 快速的双向消息传递
W3C 标准 提供低级控制
专为测试而构建

WebDriver BiDi 旨在将 WebDriver“传统版”与 CDP 的优点相结合。这是一种新的标准浏览器自动化协议，目前正处于开发阶段。

详细了解 WebDriver BiDi 项目 - 其工作原理、愿景和标准化过程。