阿里老大哥终于舍得浅谈一下UI自动化测试

前言

最近在研究E2E自动化测试，发现市面上关于自动化测试的介绍乏善可陈，因此本文将从概念介绍，技术选型，方案落地三个方面来聊聊UI自动化测试。

概念介绍

自动化测试的组成

最初由麦克科恩 (Mike Cohn) （敏捷开发的创始人之一）

在他的著作《Succeeding with Agile》一书中提出了测试金字塔这个概念。

从上图可以看出，整个金字塔模型由三层组成：

• 单元测试（Unit Tests）
• 服务测试（Service Tests）
• UI测试（UI Tests）

整个金字塔模型代表着越上层的测试集成度越高，执行速度越慢，越下层的测试隔离性越好，执行越快越轻量。

从测试金字塔中可以得到适合自己的经验法则：

• 构建不同粒度的测试

• 越高层次的测试应该越少，制定合理的测试策略

为了保持测试金字塔测形状，一个快速、可维护、覆盖范围合理的测试组合应该是这样的：

• 大量小而快的单元测试
• 全面的接口测试
• 少量的UI测试

都说业内最佳实践看Google，Google的自动化测试分层比例是：

• 单元测试（70%）
• 接口测试（20%）
• UI测试（10%）

UI测试 VS E2E测试

• UI测试（User Interface Test）

  用户界面测试

• E2E测试（End-to-end Test）

  端到端测试，模拟用户真实使用场景的测试

测试金字塔的顶层（UI测试）并非这里字面意义上的“UI测试”，这一点比较有误导性，对于现代前端应用，UI测试侧重产品的UI交互是否正确，模拟后端进行测试也可以，放在单元测试里去做也可以。

而E2E测试，是需要模拟用户真实场景的测试，检查整个系统是否以正确的方式运作。

所以广义上的“UI测试”（测试金字塔的UI Tests）可以认为是E2E测试。

什么场景适合

• 需求稳定，不会频繁变更
• UI界面稳定，变动少
• 项目周期长
• 大量的回归测试

技术选型

目前市面上常见的几种E2E测试方案有

• 基于WebDriver：Selenium，Appium
• 基于CDP：Puppeteer，Playwright
• Inject Script：Cypress

接下来，我们将从不同方案的实现原