什么是测试自动化？测试自动化是自动审查和验证软件产品（例如：Web 应用）的实践，以确保其符合代码样式、功能（业务逻辑）和用户体验的预定义质量标准。本文将详细阐述测试自动化的演进及未来趋势。

1.测试自动化的诞生

上世纪 90 年代，网络浏览器诞生。到 21 世纪，为了应对跨浏览器和多设备测试的挑战，Selenium 和 WebDriver 项目随之出现，测试自动化才成为现实。这两个项目于 2011 年合并为 Selenium WebDriver，并于 2018年 成为 W3C 标准。通常称之为 WebDriver 或者 WebDriver “传统版”。

在 WebDriver “传统版”之前，测试自动化非常困难。浏览器测试自动化的引入，其功能显著提升了开发者和测试人员的工作效率。

2.测试自动化工具的涌现

随着网页开发越来越依赖 JavaScript，涌现了不少新的自动化解决方案，如 WebdriverIO、Appium、Nightwatch、Testcafe、Cypress、Puppeteer 和 Playwright。从下图的近年来 NPM Trends 可以看到不同包的 NPM 下载量趋势，其中 Playwright 拥有这众多跨平台、跨浏览器、跨语言等特性，增长迅速，受到众多开发者喜爱。

3.测试自动化的方法

测试自动化工具可根据其在浏览器的执行方式分为两大类：

• 高级：在浏览器中执行 JavaScript 的工具。例如，Cypress 和 TestCafe 利用 Web API 和 Node.js 直接在浏览器中运行测试。有趣的是，Selenium 的第一个版本也采用了同样的方法。
• 低级：在浏览器外执行远程命令的工具。当工具需要更强的控制能力时，如打开多个标签页或模拟设备模式，就需要通过协议执行远程命令来控制浏览器。

4.测试自动化相关协议

两种主要的自动化协议是 WebDriver "传统版" 和 Chrome DevTools 协议（CDP）。

下面我们来看看这两种协议的优势和局限性：

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

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

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

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

5.WebDriver BiDi - 跨浏览器自动化的未来

5.1.WebDriver BiDi 介绍

WebDriver BiDi 是一种新的标准浏览器自动化协议，它旨在结合 WebDriver“传统版”和 CDP 的优势，以满足浏览器自动化的未来需求。WebDriver BiDi 承诺实现双向通信，默认实现快速，并且包含低级控制。

WebDriver BiDi 的愿景是让您能够使用自己喜欢的任何工具编写测试，并在任何浏览器或驱动程序中自动执行这些测试，从而获得充分的灵活性。

WebDriver BiDi 工作组由各种各样的浏览器供应商、开源浏览器自动化项目以及提供浏览器自动化解决方案的公司组成。这种合作确保了浏览器自动化的未来前景光明。

5.2.WebDriver BiDi 发展

2020 年，W3C 浏览器测试和工具工作组开始着手开发，该工作组由各种各样的浏览器供应商、开源浏览器自动化项目以及提供浏览器自动化解决方案的公司组成。这种合作确保了浏览器自动化的未来前景光明。工作组的相关工作主要在 GitHub 代码库中完成。所有主流浏览器供应商每个月都会召开会议，报告实际进度，并讨论可质疑和未知的细节。公司跨公司工作小组会确保所有利益相关方的决策都保持一致。

2022 年，Chrome/ChromeDriver 106 和 Firefox 102 均支持了 WebDriver BiDi 标准。自那之后，WebDriver BiDi 开始在热门框架中得到采用，通过解锁日志记录支持等开发者迫切需要的功能，解决了开发者面临的主要痛点。

2023 年，12月12日，Puppeteer 宣布支持下一代跨浏览器 WebDriver BiDi 标准，这也意味着 Puppeteer 成为跨浏览器的自动化工具。这个新协议使得网页开发者能够轻松编写适用于多种浏览器引擎的自动化测试。

5.3.WebDriver BiDi 挑战

因为 WebDriver BiDi 力求在兼容性、易用性和可执行性之间取得平衡，所以在实现上充满挑战。

1）超越 CDP 的束缚：实现跨浏览器兼容性：

CDP 及其特定于 Chrome 和开发者工具的元素无法直接复制到 WebDriver BiDi 规范中。对于其他浏览器而言，按原样实现 CDP 是不可行的，而呈现的规范只是记录如何实现这一点毫无意义。

2）确保较短的延迟时间：

WebDriver BiDi 的设计必须能够处理高延迟而不影响性能。在 CDP 中，延迟时间很短，因为客户端和服务器几乎总是在同一台物理机器上运行，但在 WebDriver BiDi 中则不会。因此，WebDriver BiDi 必须最大限度地减少客户端与服务器之间的往返次数。

3）在 BiDi 中优先考虑人体工程学：

虽然不希望开发者从头开始构建 WebDriver BiDi 客户端，但应避免协议过于复杂，这一点至关重要。过于复杂的 BiDi 不仅难以实现，而且难以使用，阻碍了采用和使用。

4）确保 BiDi 的可实施性：

WebDriver BiDi 必须切实可行，要考虑到各种浏览器的局限性。例如，保留 BiDi 向客户端公开的所有 JavaScript 对象可能会导致内存泄漏，而不保留任何对象则阻碍调试以及与网页的 JavaScript 交互。请务必在不影响性能的前提下，实现有效的浏览器自动化，从而达到平衡。

为解决实现 WebDriver BiDi 所面临的挑战而采取的策略有：

1）快速原型设计：

解决实施性的挑战对 BiDi 的成功至关重要。为了加快规范和测试的进展，我们使用 NodeJS 采用了一种快速的原型设计方法。这不仅能够尝试不同的解决方案，还有助于开发 Web 平台测试。

2）以性能为导向设计：

这种设计决策是由性能驱动的，因为在某些情况下，WebDriver BiDi 的延迟时间较长。例如，从浏览器检索对象 ID 和值时，WebDriver BiDi 只需要一次往返，而 CDP 需要两次。这是因为 WebDriver BiDi 可以在单个响应中返回 ID 和值（结果不应可进行 JSON 序列化），而 CDP 必须单独返回这两项。

3）侧重于 Web Platform Tests (WPT)：

Web Platform Tests 在 BiDi 的作品中发挥着重要作用。WPT 目前涵盖 WebDriver“Classic”和 WebDriver BiDi，可作为所有实现的可靠参考。这些测试旨在通过各种实现运行和传递，从而确保跨浏览器协议的执行保持一致，这对 WebDriver BiDi 的成功至关重要。

总结

随着 WebDriver BiDi 协议不断完善以及被更多浏览器所支持，它将给测试自动化质量和效率带来质的提升。