保质提效!E2E测试在通天塔的实践之路

发表于:2020-6-30 11:33

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:黄善波 钱程    来源:京东零售技术

  通天塔搭建系统通过各种组合,面向运营、商家提供了无穷的可能性,用户可以随心搭建出想要的营销页面。但是强大且复杂的系统也对研发自测带来了巨大的挑战,自测是研发质量的保障,但无论是回归测试那一长串的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开发者工具的开发者工具,进行页面重定向和截图等功能。
  图2-1:devtool向操作页面
  具体操作请参考 [Chrome DevTools Protocol](https://chromedevtools.github.io/devtools-protocol/)
  2. Chrome Headless:chrome 无头模式,即允许chrome无界面后台运行,chrome59开始跨平台支持无头模式。
  无头模式下,由于没有UI界面,减少了外界的干扰,能让程序运行的更稳定。
  解耦对UI的依赖,可跨平台运行,例如将其部署在linux平台上。
  快速认识PUPPETEER
  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-2:pptr对node环境要求
  3. 能干什么:截图、模拟用户操作、接口拦截等等在浏览器中可以手动执行的大多数操作都可以使用pptr完成。
  图3-3:pptr运用场景
  4. API结构:pptr 的API结构图(图3-4)层次分明,和Chrome结构一一对应(图中褪色的部分不在当前pptr支持范围)。理解pptr的API结构,不仅能提效自动化开发,还是前端理解浏览器机制有一定的帮助。
  图3-4:pptr结构图
  Puppeteer:Node库。
  Browser:可拥有多个BrowserContext。
  BrowserContext:浏览器上下文会话,具有数据独立性;可包含多个页面。
  Page:至少包含一个frame(主frame);同时可拥有多个frame,由iframe或者frame标签创建而生;其实一般操作,都能通过Page的API模拟完成。
  Frame:至少有一个执行上下文,默认为执Javascript的那个上下文;同时frame可能由于于扩展关联的执行上下文。
  Worker:只有一个执行上下文,帮助和WebWorkder交互。
  PUPPETEER结合通天塔
  1. 项目目标:把关代码的质量,提升研发人效。如图4-1,在灰度环境对核心流程进行自动化回归测试,只有通过测试,才能进行上线操作。
  图4-1:自动化测试项目目标
  2. 测试范围:通天塔是个庞大的系统,如果对每个细节进行用例编写,很有可能会背离初衷,反而为研发带来更繁重的维护压力。因此基于二八原则,对满足核心、常用、少变、高收益的流程进行用例编写,挑选常用且无需频繁申请测试物料的模板,通过核心主流程自动化测试,细节、业务需求人工自测的互补,以最佳的性价比去提升人效、质量。
  3. 项目架构:在实际落地时,pptr扮演的是一个核心角色,一般在测试用例编写时,开发人员接触最多的是pptr的API,但pptr并非项目全部。项目整体大致分为4层,如图4-2。
  图4-2:自动测试项目架构图
  * Node:融合jest和pptr、处理项目环境和资源配置以及对测试结果分析和处理。
  基类及工具:解决业务case的前置依赖,集中处理业务和技术难点,抽取业务页面、UI及模板中的公共部分,形成基类,作为底层向上层多变的实例及具体测试用例提供支撑。
  实例:各基类的实例化,并暴露例如编辑、保存、发布等测试方法,让case开发的起点更贴近其业务,不再是从打开页面、登录等开始。
  业务测试用例:业务用例的编写。依照测试的力度对测试场景进行拆分,主要分为复合流程用例和单功能用例。其中复合流程用例由多个单功能用例串联,例如无线平台搭建主流程测试等都是复合流程用例。单功能用例则细致到每个细微功能或元素的测试。
  4. pptr和jest融合:有社区提供封装好的jest-puppeteer库解决方案和完全自行配置方案,在jest 官网都有详细的介绍,可根据受测系统的情况进行选择。由于通天塔搭建系统较为复杂,团队选择了完全自行配置方案。
  5. pptr提供的核心能力:通过对通天塔搭建系统现阶段的业务分析,主要用到pptr的模拟用户操作、接口拦截、网络模拟、代码注入等能力。同时为了便于维护,对pptr的一些功能进行了集中封装、优化或统一了使用姿势,主要有以下几点:
  Javascript注入:方法有很多,可采用向页面添加script标签,或者通过evaluate等可在浏览器中执行的方法进行注入。目前使用了前者,便于后续抽离统一维护注入代码。
  图4-3:Javascript注入代码
  网速设置:在每个浏览器页签创建时,加入网络参数的设置,pptr暂未提供API,目前基于CDP,直接向目标页面发送了设置网速的命令及参数(当然了,5G需要硬件的支持)。
  图4-4:网速模拟图
  接口拦截:其实接口数据获取非常简单,监听page上的request和response事件即可。但是由谁监听,又何时监听?如果由case开发人员自行监听,会显得较为繁琐、低效并不可控。于是,我们将接口监听提取到了页面创建时,进行统一添加;并通过缓存跟业务进行数据交换。减少了反复添加事件的同时,简化了case开发人员的获取数据的方式。如图4-5,只需要提供监听的接口,和触发接口调用的动作即可。
  图4-5:调用封装后的数据拦截API
  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解决方案。当前通天塔团队采用的方案如下:
  图4-6:元素拖拽解决方案
  7. 测试报告:由于引入了jest,可较为简单的生成控制台报告,同时也能生成持久化的报告。
  图4-7:通天塔主流程自动化测试报告
  校验成果
  目前手动进行通天塔搭建系统回归测试,大概需要20至30分钟左右;而使用自动化脚本,大概在240秒左右(含弱网)。在时间上展现了绝对的优势,并且人工测试容易出现误差,对于已成熟稳定的搭建主流程,也有非常明显的优势。同时其便利的特点也提升了研发主动自测的频率,让研发可以专注在需求、细节等方面的自测,通过人机互补的形式,对整体代码质量提升具有显著的推动效果。
  图5-1:通天塔可视化人工、自动化测试对比
  总结与展望
  通过现阶段的建设,团队已经解决了开发周期中,自测、回归耗时长、易出错的难题。同时端对端测试的特点,也令研发在潜移默化中更加关注用户侧视角,不论是必须保障的代码质量还是面向用户的体验交互都带来了提升。
  目前团队已在2020年Q2完成全平台核心模板的自测范围覆盖,同时挖掘E2E测试与CI / CD的深度结合。后续将建设一套完善的自动化、标准化、流程化、持续化的前端工程系统,以工程的角度解决研发问题,在研发人效、代码质量等角度稳步前行!

      本文内容不用于商业目的,如涉及知识产权问题,请权利人联系博为峰小编(021-64471599-8017),我们将立即处理。
《2023软件测试行业现状调查报告》独家发布~

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号