前言
概念介绍
自动化测试的组成
最初由麦克科恩 (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。
在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中运行。
方案对比
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系51Testing小编(021-64471599-8017)，我们将立即处理
