三方面带你全面认识UI测试（上）

草帽路飞UU

前言
　　最近在研究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
　　接下来，我们将从不同方案的实现原理一一进行分析和对比。

　　WebDriver
　　WebDriver是W3C标准中的浏览器远程控制协议（Protocol）

Client就是我们的测试代码，Browser就是我们要控制的浏览器，中间会有个WebDriver协议的实现，就是Browser Driver。
　　在Client端通过Language Binding，可以实现多语言的测试脚本（Java、Ruby、Python、C#、Javascript etc...）
　　在Browser Driver端，是各个浏览器基于WebDriver的实现，用来远程控制浏览器
　　当执行测试脚本时：发起http请求，基于JSON Wire Protocol，生成返回JSON格式的请求，发送给Browser Driver
　　Browser Driver通过http服务器接受请求，再通过http server决定执行在浏览器的指令
　　执行状态将发送返回给http server，再将其发送回自动化脚本

　　CDP
　　全称：Chrome Devtools Protocol
　　也就是：Chrome浏览器开发工具协议

在 Selenium 中 chrome driver的实现中也是基于CDP二次开发去控制浏览器。
　　相比于Webdriver的协议，CDP可以做更多底层的操作，比如可以检查/调试/监听网络流量。
　　Puppeteer就是基于CDP的Nodejs 实现。

　　Inject Script
　　代表作：Cypress

　大多数测试工具（例如selenium）通过在浏览器外部运行并在网络上执行远程命令来运行。cypress则相反，cypress与应用程序在相同的生命周期里执行。
　　技术上讲，cypress通过webpack将测试代码打包成一个bundle，放到一个iframe中运行，当首次加载cypress时，cypress web应用程序先把自己托管在本地的一个随机端口上，在识别出第一个cy.visit()命令后，cypress会更改本地URL以匹配你远程应用程序的origin（满足同源策略--即相同域名、协议、端口），使得测试代码和应用程序在同一个run loop中运行。

　　方案对比