文:华为云dev云音乐减少
1、背景。
1.1前端自动化测试数量减少
前端浏览器数量多了,页面兼容性问题就多了,另外界面变化快,一个月内页面可以改版两三次,前端自动化测试就少了,care也没那么多。(威廉莎士比亚,美国作家)。
18年英国的一位开发者做过一些前端测试工具调查如图1-1所示。从图中可以发现有43%的用户未使用过任何前端测试工具。图1-1
1.2 基于Puppteer的自动化测试
Puppeteer(中文翻译为“木偶”)是Google Chrome团队官方的无界面(Headless)chrome工具。这是一个node库。提供高级API来控制DevTools协议无头版Chrome。Chrome的DevTools提供了非常之多和非常方便的页面工具,而Puppteteer则把这种能力通过Headless方式提供出来,可以在linux操作能力,必将成为web应用的自动化测试行业标杆,场景非常之多。
1.3 解决实际问题
笔者是在华为云DevCloud的前端团队,团队采用前端微服务架构,也就是说,有很多前端portal,同时每个portal有若干个前端开发进行开发维护,开发之间沟通交流较少,而且还是在异地进行开发。但每个服务同属于DevCloud产品,所以页面体验、场景、控件、术语都需要保持一致,如果通过人工的方式来对每个服务页面进行检测是十分困难的一件工作。
2、Puppeteer能做什么
可以这么说,在chrome浏览器手动能完成的大部分事情可以使用puppteteer完成!你可以操作页面的dom、抓取内容等等。另外puppeteer还可以:
- 生成页面的截图和PDF;
- 抓取SPA并生成预先呈现的内容(SSR)
- 从网站上抓取你所想要的内容。自动表单提交,UI测试,键盘输入等等
- 创建一个最新的自动化测试环境,使用最新的JavaScript和浏览器功能,直接在最新版的chrome中运行测试。
3、Puppeteer版本
我最早使用的版本是puppetter@1.5.0版本,通过npm i pupptetter下载。里面包含自带浏览器版本。如图所示3-1所示。
图3-1 puppeteer自带浏览器
在版本1.7.0之后,google把puppeteer拆成puppteteer-core和浏览器两部分。也就是说浏览器需要自己手动去下载。下载地址可以通过华为云镜像站(http://t.cn/EJiCszB)搜索chromium进行匹配下载,如图3-2所示。
图3-2 puppteteer浏览器chrome下载
当然不同的puppeteer-core版本匹配不同的浏览器版本,不然会有报错。版本匹配如图2-3所示。大家也可以在官网github上进行查看:
图3-3 puppeteer版本匹配
4、 轻松入门
这部分包括windows和linux上的配置和运行。因为最终是需要部署到linux服务上去。
4.1 简单实现
如果windows下使用puppeteer非常容易,在加上下面一行代码:
"puppeteer-core": "1.13.0",下面是一点简单截频实现:
const puppeteer = require('puppeteer'); (async () => { const browser = await (); const page = await brow(); await (';); await ({path: 'exam;}); await brow(); })();4.2 基本语法
这些是puppeteer一些基础的语法,可以满足一些常用功能。
async/await
看官方的例子就可以看出来,几乎所有的操作都是异步的,如果坚持使用回调或者Promi 写出来的代码会非常丑陋且难读,Puppeteer 官方推荐的也是使用高版本 Node 用 async/await 语法
async确保了函数返回一个promise,即使其中包含非promise。够简单了吧?但是不仅仅只是如此,还有另一个关键词await,只能在async函数里使用,同样,它也很cool。
关键词await可以让JavaScript进行等待,直到一个promise执行并返回它的结果,JavaScript才会继续往下执行。
let value = await promise查找元素
这是 UI 自动化测试最常用的功能了,Puppeteer 的处理也相当简单
page.$(selector)
page.$(selector)
这个在底层依然是执行document.querySelector和document.querySelectorAll。但返回的不是dom对象。而是封装的。
获取DOM属性
我们写爬虫爬取页面图片列表,感觉可以通过 page.$$(selector) 获取到页面的元素列表,然后再去转成 DOM 对象,获取 src,然后并不行,想做对获取元素对应 DOM 属性的获取,需要用专门的 API:page.$eval(selector, pageFunction[, ...args])
evaluate
如果我们有一些及其个性的需求,无法通过 page.$() 或者 page.$eval() 实现,可以用大招——evaluate。如下所示:
const result = await (() => { return Promi(8 * 7); }); con(result); // prints "56" const aWindowHandle = await Handle(() => Promi(window)); aWindowHandle; // Handle for the window object. 相当于把返回对象做了一层包裹性能
通过 () 可以得到一些页面性能数据。
- Timestamp The timestamp when the metrics sample was taken.
- Documents 页面文档数
- Frames 页面 frame 数
- JSEventListeners 页面内事件监听器数
- Nodes 页面 DOM 节点数
- LayoutCount 页面 layout 数
- RecalcStyleCount 样式重算数
- LayoutDuration 页面 layout 时间
- RecalcStyleDuration 样式重算时长
- ScriptDuration script 时间
- TaskDuration 所有浏览器任务时长
- JSHeapUsedSize JavaScript 占用堆大小
- JSHeapTotalSize JavaScript 堆总量
会返回如下数据:
{ Timestamp: 382305.912236, Documents: 5, Frames: 3, JSEventListeners: 129, Nodes: 8810, LayoutCount: 38, RecalcStyleCount: 56, LayoutDuration: 0.596341000346001, RecalcStyleDuration: 0.8817, ScriptDuration: 1.24401400075294, TaskDuration: 2.21657899935963, JSHeapUsedSize: 15430816, JSHeapTotalSize: 23449600 }更多功能请查看puppeteer的github官网。
4.3 Linux安装Puppeteer
windows下调试好的项目,在linux上运行,还是需要费一番功夫,需要配置更多的参数。如下:
一、下载相关依赖包,这些依赖包都是chrome运行所需要的。
yum install libXcom libXcur libXdamage.x86_64 libXext.x86_64 \ libXi.x86_64 libX cu libXScrnSaver.x86_64 libXrandr.x86_64 GCon \ al a g ipa-gothic-fonts xorg-x11-fonts-100dpi \ xorg-x11-fonts-75dpi xorg-x11-utils xorg-x11-fonts-cyrillic xorg-x11-fonts-Type1 xorg-x11-fonts-misc二、字体安装:
yum install ipa-gothic-fonts xorg-x11-fonts-100dpi xorg-x11-fonts-75dpi xorg-x11-utils xorg-x11-fonts-cyrillic xorg-x11-fonts-Type1 xorg-x11-fonts-misc三、增加—no-sandbox –disable-setuid-sandbox
const browser = await ({args:['--no-sandbox', '--disable-setuid-sandbox']})笔者的工作环境比较复杂,中间因为权限问题导致运行报错,这个时候需要增加一些代理设置。
5、puppeteer体验度量实践
前面主要是讲一些puppeteer基本功能和实践。那我们基于puppeteer怎么解决实际问题的呢。
5.1 规范的建立
在使用puppeteer之前,需要先梳理各微服务使用的场景,以及术语规范等,梳理清楚之后在来进行工具自动化。首先我们参照尼尔森可用性原则。
上面这位略显阴柔的帅哥就是尼尔森(Jakob Nielsen),人机交互学博士。他通过自己的邮件列表以及网站,向成千上万的web设计师传授web易用性方面的只是。是web设计师眼中的顶尖领袖。Jakob Nielsen在1995年发表了“尼尔森十大可用性原则”。
在尼尔森十大原则里有一项是UI一致性原则,我们基于这个梳理出DevCloud的一些细化的点,并给出每个测试因子的权重和分值,计算出各个服务的UI体验,最后换算成百分值,最后加权计算服务体验总分。图5-1就是我们梳理出来的部分规则。
图5-1 测试分类
5.2 具体使用puppteer
在上面建立规则之后,我们再针对每个检测项评估是否可以量化,怎么量化。比如我们想检测组件的覆盖度。图4-2是我们产品所使用的公共组件库。都是以ave-开头,checkbox的命名就是ave-button。那普通的checkbox则是以input[type=checkbox]来写的。我们针对每个服务去扫面线上各个页面,看使用ave-check和使用原生input checkbox的数量,这样就能统计出组件库的覆盖度。最终驱动各服务去整改。
通过组件的形式使得各个服务体验基本一致。
图5-2 DevCloud组件库
最终通过图表的形式来进行展示。如图5-3所示。
图5-3 ave-checkbox覆盖度
从图上我们可以看到ave-checkbox得到整改。
通过以上的方式,我们可以在组件、样式、以及体验旅程方面都能很好的把握整个产品设计是否与我们预期是一致的。
我们团队在自动化方面一直在探索,除了在前端测试、接口测试以及编译构建方面也一直遵从能够使用工具提升效率,绝不靠人工来进行检测的理念,不断的实践,极大的减少了人力成本。当然这些能力也一直是对外开放的:华为云软件开发服务DevCloud。也欢迎大家来建议和探讨。
6、 参考资料及扩展阅读材料
The Front-End Tooling Survey 2018 - Results
尼尔森可用性十大原则
华为云DevCloud作为一站式云端DevOps平台,集成华为近30年研发实践和前沿理念,面向开发者提供研发工具服务,让软件开发简单高效。现支持5人以下额度范围内,可以免费使用,并且可以预约免费的产品演示和技术交流,详情查看华为云官网:http://t.cn/EJia5sX