保质提效！E2E测试在通天塔的实践之路
通天塔搭建系统通过各种组合，面向运营、商家提供了无穷的可能性，用户可以随心搭建出想要的营销页面。但是强大且复杂的系统也对研发自测带来了巨大的挑战，自测是研发质量的保障，但无论是回归测试那一长串的list还是各个逻辑分支的变化，都对自测阶段的时间和细节要求带来了相当的挑战。研发自测一次通天塔搭建流程往往需要二十甚至三十分钟的投入，并且依赖人工容易出现疏漏、差错。
因此，通天塔团队在2020年Q1实践并落地了一套E2E（端对端）测试流程，覆盖通天塔搭建系统无线端在核心搭建流程的测试。通过这套流程，常规需求自测、重构优化后的回归、日常监控走查等工作可以大幅减少人力投入，让宝贵的研发资源得以投入到更重要的节点。
业界有非常多优秀的WebUI自动化测试框架，诸如：Puppeteer、Playwright、Selenium、Cypress、Testcafe、Phantomjs、Protractor。通天塔团队经过一系列的甄选最终选择了Puppeteer（以下简称pptr），主要原因如下：
Puppeteer是基于JavaScript开发的Node库，与搭建系统团队技术栈一致，开发上手成本低。
Puppeteer由Chrome官方团队开发和维护，同时运营用户也主要使用Chrome搭建页面。
Puppeteer更贴近浏览器，功能强大、扩展性高，开发者甚至可以避开其提供的API，自行基于Chrome Devtools Protocol 操控Chrome。
Puppeteer 免费开源，目前版本稳定，社区活跃并且持续增长，易于长期维护。
在使用pptr之前，需要先了解一下其依赖的两个核心概念Chrome Devtools Protocol和Chrome Headless。
1. Chrome Devtools Protocol: chrome开发协议（以下简称CDP），基于WebSocket。chrome允许第三方通过CDP与其建立数据交换通道。
CDP与语言无关，第三方可利用任意语言基于CDP操控Chrome。
Chrome的开发者工具、VS-code调试器以及Puppeteer、Selenium的webDriver等都是基于CDP。
如图2-1：利用chrome开发者工具的开发者工具，进行页面重定向和截图等功能。
具体操作请参考 [Chrome DevTools Protocol](https://chromedevtools.github.io/devtools-protocol/)
2. Chrome Headless：chrome 无头模式，即允许chrome无界面后台运行，chrome59开始跨平台支持无头模式。
无头模式下，由于没有UI界面，减少了外界的干扰，能让程序运行的更稳定。
解耦对UI的依赖，可跨平台运行，例如将其部署在linux平台上。
1. 定义：Puppeteer，基于CDP封装的一个Node库，提供了一系列操控chrome的高级API；同时可控制Chrome运行在无头模式下。经过前面对CDP的了解，不难发现pptr实际是基于node对CDP进行封装的工具库；相比于CDP和浏览器交互的晦涩命令集，pptr提供的API更便于开发。
2. 安装: 可通过npm/yarn安装，如图3-1。pptr 默认自带一个chromium浏览器；自V1.7.0后，同时发布了不含Chromium的包 puppeteer-core。
图3-1：pptr安装
需要注意的pptr不同版本对node版本有一定的要求，详见图3-2：
3. 能干什么：截图、模拟用户操作、接口拦截等等在浏览器中可以手动执行的大多数操作都可以使用pptr完成。
4. API结构：pptr 的API结构图（图3-4）层次分明，和Chrome结构一一对应（图中褪色的部分不在当前pptr支持范围）。理解pptr的API结构，不仅能提效自动化开发，还是前端理解浏览器机制有一定的帮助。
Puppeteer：Node库。
Browser：可拥有多个BrowserContext。
BrowserContext：浏览器上下文会话，具有数据独立性；可包含多个页面。
Page：至少包含一个frame（主frame）；同时可拥有多个frame，由iframe或者frame标签创建而生；其实一般操作，都能通过Page的API模拟完成。
Frame：至少有一个执行上下文，默认为执Javascript的那个上下文；同时frame可能由于于扩展关联的执行上下文。
Worker：只有一个执行上下文，帮助和WebWorkder交互。
1. 项目目标：把关代码的质量，提升研发人效。如图4-1，在灰度环境对核心流程进行自动化回归测试，只有通过测试，才能进行上线操作。
图4-1：自动化测试项目目标
2. 测试范围：通天塔是个庞大的系统，如果对每个细节进行用例编写，很有可能会背离初衷，反而为研发带来更繁重的维护压力。因此基于二八原则，对满足核心、常用、少变、高收益的流程进行用例编写，挑选常用且无需频繁申请测试物料的模板，通过核心主流程自动化测试，细节、业务需求人工自测的互补，以最佳的性价比去提升人效、质量。
3. 项目架构：在实际落地时，pptr扮演的是一个核心角色，一般在测试用例编写时，开发人员接触最多的是pptr的API，但pptr并非项目全部。项目整体大致分为4层，如图4-2。
* Node：融合jest和pptr、处理项目环境和资源配置以及对测试结果分析和处理。
基类及工具：解决业务case的前置依赖，集中处理业务和技术难点，抽取业务页面、UI及模板中的公共部分，形成基类，作为底层向上层多变的实例及具体测试用例提供支撑。
实例：各基类的实例化，并暴露例如编辑、保存、发布等测试方法，让case开发的起点更贴近其业务，不再是从打开页面、登录等开始。
业务测试用例：业务用例的编写。依照测试的力度对测试场景进行拆分，主要分为复合流程用例和单功能用例。其中复合流程用例由多个单功能用例串联，例如无线平台搭建主流程测试等都是复合流程用例。单功能用例则细致到每个细微功能或元素的测试。
4. pptr和jest融合：有社区提供封装好的jest-puppeteer库解决方案和完全自行配置方案，在jest 官网都有详细的介绍，可根据受测系统的情况进行选择。由于通天塔搭建系统较为复杂，团队选择了完全自行配置方案。
5. pptr提供的核心能力：通过对通天塔搭建系统现阶段的业务分析，主要用到pptr的模拟用户操作、接口拦截、网络模拟、代码注入等能力。同时为了便于维护，对pptr的一些功能进行了集中封装、优化或统一了使用姿势，主要有以下几点：
Javascript注入：方法有很多，可采用向页面添加script标签，或者通过evaluate等可在浏览器中执行的方法进行注入。目前使用了前者，便于后续抽离统一维护注入代码。
网速设置：在每个浏览器页签创建时，加入网络参数的设置，pptr暂未提供API，目前基于CDP，直接向目标页面发送了设置网速的命令及参数（当然了，5G需要硬件的支持）。
接口拦截：其实接口数据获取非常简单，监听page上的request和response事件即可。但是由谁监听，又何时监听？如果由case开发人员自行监听，会显得较为繁琐、低效并不可控。于是，我们将接口监听提取到了页面创建时，进行统一添加；并通过缓存跟业务进行数据交换。减少了反复添加事件的同时，简化了case开发人员的获取数据的方式。如图4-5，只需要提供监听的接口，和触发接口调用的动作即可。
6. 实践中遇到有关pptr的问题：
page.click无效：可尝试 page.$eval(‘xxx’, el => el.click)
文件上传失败：v2.1.1 elementHandle.uploadFile(...filePaths) 文件上传未触发change 事件，导致无法上传至服务器；在v3.0.0修复，目前利用外部兼容Polyfill模块，完成自行修复。
弹窗阻止页面关闭或刷新：监听page的dialog事件，处理弹窗，详细请参考官网文档。
元素拖拽（DragAndDrop）:对于元素拖拽，pptr并没有提供现成的api。这是pptr一个众所周知的issue，理想方案是利用鼠标，移动到待拖拽元素上再按下，然后再将鼠标移动到目标元素上，放开鼠标即可。但最终总是受真实鼠标位置影响，可能无法放下元素。由于官方没有给出最佳方案，因此可以自行search解决方案。当前通天塔团队采用的方案如下：
7. 测试报告：由于引入了jest，可较为简单的生成控制台报告，同时也能生成持久化的报告。
目前手动进行通天塔搭建系统回归测试，大概需要20至30分钟左右；而使用自动化脚本，大概在240秒左右（含弱网）。在时间上展现了绝对的优势，并且人工测试容易出现误差，对于已成熟稳定的搭建主流程，也有非常明显的优势。同时其便利的特点也提升了研发主动自测的频率，让研发可以专注在需求、细节等方面的自测，通过人机互补的形式，对整体代码质量提升具有显著的推动效果。
通过现阶段的建设，团队已经解决了开发周期中，自测、回归耗时长、易出错的难题。同时端对端测试的特点，也令研发在潜移默化中更加关注用户侧视角，不论是必须保障的代码质量还是面向用户的体验交互都带来了提升。
目前团队已在2020年Q2完成全平台核心模板的自测范围覆盖，同时挖掘E2E测试与CI / CD的深度结合。后续将建设一套完善的自动化、标准化、流程化、持续化的前端工程系统，以工程的角度解决研发问题，在研发人效、代码质量等角度稳步前行！