A-A+

海豚中用户交互行为录制功能的实现详解

2017年07月31日 自动化测试 暂无评论 阅读 115 次

海豚是什么?

没错,它是一个 Web UI自动化测试工具,专治Web UI的各种疑难杂症,目前只针对移动端Webapp量身定做。

说到 Web UI的自动化测试,大家信口拈来都能够说出来很多:Totoro/Dalekjs/Automaton/Selenium/CatJS/[Maoxu UITestPI]阿里内部的自动化测试工具/Baidu Pagediff ... 还有很多隐藏功与名的自动化测试工具罗列不出来了,就让我们先顶礼膜拜一下吧

上面罗列的其实有些不算是Web UI自动化测试工具,至少不算是 UI 级别的测试工具,只是一个提供测试环境的工具。

对于 Web UI的自动化测试,其实大家都尝试过很多方案,最终都挺难坚持下来的,主要有两个点: 测试用例维护成本高; Web UI经常变动,导致维护测试用例成了一个十分花费成本的事情。 这样自然就比较难的坚持下来。

那么,为啥还要再开发一个海豚呢?首先, 它不仅仅是一个 “轮子”,下面将会向大家展示它所包含的丰富的功能,以及如何解决用例编写和维护方面的成本问题,就能够很好的回答为啥还要再开发一个 “轮子”。

在开始天花乱坠之前,大家试想一下:每次功能上线,可能都需要进行全功能的回归,这样导致前端和测试的资源浪费严重,并且容易漏测。特别是对一些SPA的Webapp应用,对JS的逻辑有强依赖,稍微某处的JS报个错,有可能就导致页面渲染不出来,这似乎就直接是P2+的故障了(还想不想拿3.5了!)。

如果 让全功能的回归能够做到自动化,释放纯手工测试的人力资源,并且回归测试能够覆盖到所有的逻辑场景 ,这对测试的效率,以及整个开发流程的效率都是很大的提升,并且能够规避很多人的主观和客观因素导致的漏测或者疏忽。


海豚能够做什么事情?

  1. 多页面流的自动化测试
  2. 页面样式Page Diff监控
  3. 页面JS执行过程监控
  4. 页面JS执行错误捕获
  5. 网络加载情况异常捕获(statusCode)
  6. 性能分析
  7. 页面情况扫描
  8. 交互行为的录制以及自动化回放,监控交互行为的过程
  9. ...更多待你挖掘...

多页面流的自动化测试

支持在多个页面之间的自动化测试,测试完整业务流场景,比如常见的 “商品详情->交易->下单-> ...”的业务流,都可以很好的支持.

比如下图就是从天猫的首页点击“品牌特卖”,然后再点击其中一个商品到商品详情页的过程,全程截图,并且监控这个过程的样式、JS报错情况、网络请求加载情况等,当然也还可以自定义一些代码来检查这个过程是否符合预期:

细节方面的,可以点击查看该视频说明:点击观看


单页面的自动化测试

这种场景就更加简单一点,直接使用录制工具录制交互行为测试代码,然后直接复制到任务中即可,细节方面的,可以点击查看视频说明:点击查看


页面样式监控

采用 page-diff 的方案,监控页面样式发生的变化,可以在录制用户的行为过程中针对每一个动作进行pagediff操作。

使用 page-diff 的方案代替传统的截图做比对的方式,有了非常大的好处,并且可以避免非常多的误报(比如一些lazyload的图片,每次运行加载情况不一样导致误报),通过 page-diff,就可以只关注页面的样式的变化,对内容本身可以不做Diff,减少因为内容的变化导致的误报。

而对于使用者来说,只需要设定该行为动作使用pagediff即可,声明了之后,行为回放的过程执行到这一步会进行跟设定的pagediff基线进行diff比对,有diff会上报错误,并且可以可视化的看到Diff Highlight的结果。

var action = monitor.createAction();
action
.tap("#index-channel > .hot", { usePageDiff : true, waitTime: 2000 }, function(elem){})
.tap("#index-channel > span", { usePageDiff : true, waitTime: 2000 }, function(elem){})
.end(function(){ monitor.complete(); });


JS执行过程监控

它是这样的一个功能,页面注册一个 window.debug 函数,然后在业务代码中通过这个debug函数输出信息,Dolphin会收集这些信息,每次运行都跟基线进行diff,有差异就上报错误,并且可视化的做展现。

这有一个非常大的好处在于,可以监控到页面上JS的运行顺序以及逻辑执行是否有差异,从而发现JS执行层面的问题


交互行为录制功能

提供了对页面交互行为的录制功能,录制完成后自动生成测试用例代码,大大提高测试任务用例代码的创建和维护成本。这样可以最小成本的创建用例以及更新用例代码。

出示一组数据: 本人的业务内,一个对前端不太熟悉的测试女同学(没错,是女同学),整理了87个测试场景,然后创建了87个测试任务,全部通过录制工具完成,减去中间其他事情的干扰,完成这87个测试任务的录制以及设定工作,只需要3天

录制工具产出的示例代码:

//http://tv.uc.cn/mobile/4.7.6/index.html?uc_param_str=frdnsnpfvecplabtbmntnwpvsslibieisinipr#!/channel/%E5%8A%A8%E6%BC%AB

var action_1441870302268 = monitor.createAction();
action_1441870302268
.wait(2000)
.tap("#index-channel > ul:nth-child(1) > li:nth-child(2) > span", {  usePageDiff : true, waitTime : 2000  }, function(elem){})
.tap("#channel > div:nth-child(1) > div > div:nth-child(3) > div > ul:nth-child(1) > li:nth-child(3) > span", {  usePageDiff : true, waitTime : 2000  }, function(elem){})
.tap("#main > div:nth-child(3) > div:nth-child(1) > div > div:nth-child(3) > div > ul:nth-child(1) > li:nth-child(4) > span", {  usePageDiff : true, waitTime : 2000  }, function(elem){})
.end(function(){ monitor.complete(); });

//如果是多页面测试场景,下面这个注释千万不要删掉哦,那是间隔标志符
/*{{PAGEMARK}}*/

工具截图(不要只看妹子啦,下面高能):


众多页面分析相关工具

在任务运行完成后,在运行详情页面,有丰富的工具来分析页面的性能和规范的问题。

比如有测试页面T0~T2(包括首屏)的时间以及截图、页面加载过程的截图动画、PageSpeed Insights、YSlow等等。

更多的工具就不一一展示了,这是针对页面进行分析的工具集,可以通过这样的分析和测试,发现页面性能方面的问题


天马行空的随想

现在再回想起开头针对 Web UI 自动化测试的两个痛点问题:

  1. 用例维护成本高:海豚使用录制工具(其实都有的啦,说话不能超过三遍),自动生成直接可执行的用例代码,创建用例简单,维护上针对有修改的用例重新录制即可。回放交互行为的过程,会自动进行Page Diff,JS Debug,JS错误捕获等等的监控,所以只需要用户做的,就是录制~录制~录制,即可
  2. Web UI总是频繁的变动,导致用例总是需要更新。针对这点,我说说个人的看法:
    1. 之前一直以为Web UI自动化测试比较适合“比较稳定的业务场景”,其实不然,稳定的业务场景以及非稳定的业务场景,都非常有必要建立起来一套UI自动化测试,而这里的UI不只是单单指的是样式,更多的是JavaScript的业务逻辑,UI可以多变,但是JS的业务逻辑不会保持长时间频繁的变动,特别是一些核心的JS业务逻辑场景
    2. 海豚支持了样式以及JS业务逻辑的监控,这个就跟接口维护平台一样,保持“鲜活”的接口以及测试用例,才能让业务的研发效率得到持续的保障和提升
    3. 试想:业务逻辑相对稳定之后,UI虽然时有变动,但是如果变动都要导致功能回归范围广,那么这样的耗时,跟修改部分需要更新的测试用例代码,然后进行详细的功能自动化回归,这样的收益是不是会更大呢。
    4. 最后一点, 目前针对 Web UI 的测试大部分都还是手工、肉眼的模式来进行,这样原始的工作方式,是不是应该改变一下,使用自动化工具代替手工模式,日常维护测试用例的更新,那么运行和检测、监控方面就交给测试工具,全覆盖的进行功能回归检测,然后把剩下的时间,用我们产品的话说就是:“测试的最高境界是为测试产品,而不是测试某个功能”。测试功能就留给自动化测试工具,那么测试产品,就交给你了

接下来要做什么

当前,海豚的运行服务是通过 PhantomJS 2.0 运行的,大家第一个想法就是:它还是不能真实的模拟设备啦,然并卵~然并卵~

我们正在调研并开发让运行Runner服务运行在iOS上面,或者后面还会有Android的Runner,还会有手淘、天猫、UC浏览器内核的Runner的出现。期待吧~~

 

问答:

1).这个“轮子”造的确实不错,但发现一个问题若是纯JS的动作和后台没有交互的话,录制也就无法抓取必须手动代码补上。不过页面样式Page Diff监控做的确实一亮

答:"纯JS的动作和后台没有交互的话,录制也就无法抓取" 这个不太明白意思。 纯JS的动作,结果要体现在UI的更新上才能验证。如果不涉及到UI的变更,那么可以使用console.debug输出js执行的信息,这个可以在每次运行的时候去diff这个输出的结果,来保证JS执行层的差异。

2)

1.回放功能的稳定性如何?经过大用例实践后是否能足够稳定的回放? 2.类似于 .tap("#index-channel > ul:nth-child(1) > li:nth-child(2) > span", { usePageDiff : true, waitTime : 2000 }, function(elem){}) 这样的录制脚本,可维护性还可以提高吗?总感觉(1)(2)这样的玩意儿是可维护性的敌人。

答:1. 目前运行下来,稳定性没问题; 2. 这是录制出来的脚本,在录制的selector这块我已经做了优化,尽量使用class和id,如果匹配到某一级的class已经可以唯一定位到这个元素,就截至,所以selector已经可以很短的了。

3):对于快速迭代的产品来说成本还是太高

答:

我们用这个平台来测试快速迭代的产品,基本上没有多少成本,主要的成本都是前期的录制。这个项目主要的意义在于缩小回归测试的范围

 

关于这个快速迭代的产品的个人想法我在上面最后的随想里面也说明了,ui的变化包括样式和js逻辑,两者都频繁迭代的产品很少见,想想用户得要多么辛苦的不停的适应产品的变化啊。对于测试同学本身,需要从人工的测试方式,寻求一种自动化的方案去解决人工测试的方式。一来全面,二来释放测试资源,可以做其他更多有意义的事情。产品迭代频繁不是一个终极理由。

4):

browserstack挺好的,真实多环境测试.自己的话,各种平台弄一个,装selenium

答:

browserstack这样的很多,但是考虑到用例的维护成本,以及测试页面的深度,需要获取到页面加载、执行的情况。不一定都适合自己的业务情况。

 

ps:https://testerhome.com/topics/3394

标签:

给我留言

Copyright © web前端技术开发个人博客 保留所有权利  京ICP备14060653号 Theme  Ality

用户登录