案例研究 - WebdriverIO 如何帮助在线视频公司加快发布速度并提升代码质量

JW Player 是一款可嵌入的在线视频播放器，每天产生超过 10 亿次独立观看量。为了维持和扩大这一规模，播放器需要能够在各种不同的网络和移动平台上运行。这增加了自动化测试的重要性，以便在部署到如此多的不同目标时提高我们对发布版本的信心。在将我们的遗留测试框架（包含超过 6,000 个测试）转换完成一个漫长的项目后，JW Player 的测试工程团队能够以更及时的方式发布版本，并且出现回归的次数更少。由于 WebdriverIO，我们没有遇到任何重大回滚，并且增强了我们对产品质量的信心。

选择 WebdriverIO

在我们迁移到 WebdriverIO 之前，我们一直在使用基于 Cucumber 的开源 Ruby 框架。JW Player 官方支持七种桌面和移动网络浏览器，以及 iOS 和 Android 版本（分别追溯到 10 和 4.4）。为了覆盖这些平台，我们每天晚上运行大约 25,000 个 UI 验收测试。遗留的实现导致了两个问题。首先，我们在 Ruby 中遇到了性能限制，因为跨所有平台的单个测试运行可能需要长达 9 个小时。其次，由于播放器是用 JavaScript 实现的，产品工程师不太可能采用和参与基于 Ruby 的框架。迁移到 JavaScript 原生框架解决了这两个问题。

Selenium Webdriver 长期以来一直是 Web 自动化的首选标准。大约在 2018 年，我们的团队开始探索一些新兴的测试技术。Cypress 的浏览器支持有限，Microsoft Playwright 当时甚至还没有发布，而 Puppeteer 只能在 Chrome 上执行。基于 Webdriver 的解决方案，凭借其在浏览器供应商中广泛而专注的支持，成为明显的赢家。

最初吸引我们使用 WebdriverIO 的是其简单的 API 以及对我们所有需要测试的浏览器和设备的完整支持，相比之下，Cypress 和 Puppeteer 缺乏对一个或多个必要平台的支持。但更重要的是，它拥有丰富的插件系统和活跃、积极的开发者社区。来自 Sauce Labs 的赞助（已经在测试领域崭露头角）让我们相信 WebdriverIO 将继续发展，不会成为废弃软件。

WebdriverIO 原生支持我们的一些现有和期望的工具集。例如，我们用于快速梳理产品缺陷的Allure 报告，以及我们用于监控测试健康状况和跟踪随时间推移的趋势的Report Portal，都很容易集成。细粒度的执行前和执行后钩子赋予了测试工程师前所未有的能力来塑造测试的执行方式和位置。

Webdriver.IO 实践方法

随着 WebdriverIO 不断添加更多功能，我们能够通过删除开源依赖项和混乱的 mixin 代码来持续简化我们的代码库。我们甚至能够停用旧框架依赖的一些服务。

• 去年发布的网络基元功能使我们能够移除对 Browsermob Proxy 的依赖，Browsermob Proxy 是一种通常用于 Selenium Webdriver 应用程序的代理工具，用于拦截和操作 HTTP 请求。我们现在调用 browser.mock()，指定我们要捕获的请求的子字符串或正则表达式，并提供一个简单的模拟对象来替换该资源。延迟响应的能力使我们能够自动化一些需要手动执行的复杂测试。然后，我们能够在由于网络或其他外部条件导致特定请求（例如广告）延迟时验证播放器的行为。

  // mock.js
  export function delayResponse3seconds() {
      return new Promise((resolve) => setTimeout(() => {
          return resolve('{ "foo": bar }');
      }, 3000));
  }
  
  // test.js
  import { delayResponse3seconds } from './mock';
  
  function rewritePattern(pattern, replacement) {
     console.log(`Attempting to rewrite: ${pattern} with: ${replacement}`);
     const toRewrite = browser.mock(`**/${pattern}`);
     toRewrite.respond(delayResponse3seconds);
     console.log(`Successfully rewrote ${pattern} to ${replacement}`);
  }

• 随附的Chrome Devtools 协议支持也使我们能够自动化一些原本需要手动完成的测试。能够在初始页面加载后调用 browser.throttle(“Good3G”) 使我们能够更准确地验证视频播放器在移动用户更真实的条件下的行为。

• 由于WebdriverIO 的 CDP 映射，我们能够创建和维护一套性能测试。在页面加载和与播放器交互后调用 browser.getMetrics() 使我们能够验证，一旦播放器设置好并嵌入到客户的网站上，它就不会对最终用户造成任何不必要的累积布局偏移，从而避免造成破坏性的页面加载体验。

总结

总的来说，JW Player 迁移到 WebdriverIO 无疑是一项巨大的成功。在性能和“生活质量”方面相较于我们的旧框架有所提升，WebdriverIO 的功能集使我们能够自动化数百个手动测试用例。我们已经能够将回归周期从大约 1 周大幅缩短到几天。但最重要的是，这些改进使我们能够发现创纪录数量的缺陷，从而带来更高质量的产品并为客户提供更多价值。