你尚未登录,仅允许查看本站部分内容。请登录使用邀请码注册
supersha

海豚-Web UI自动化测试工具 35个回复 专栏 @ 工具

supersha 发布于 1 年前

海豚是什么?

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

说到 Web UI的自动化测试,大家信口拈来都能够说出来很多:Totoro/Dalekjs/Automaton/Selenium/CatJS/[Maoxu UITest PI]阿里内部的自动化测试工具/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的出现。期待吧~~

  • kangxiaojun

    mark

    #1
  • zack

    赞!

    #2
  • mikuazusa

    大赞啊,看来也是松鼠厂的小伙伴~

    #3
  • 前端农民工

    必须赞一下

    #4
  • ocean

    太赞了..!

    #5
  • ThinkerChan

    mark

    #6
  • ro87630872

    mark 太赞了

    #7
  • chenwery

    动作录制给测试用例的维护带来太大的方便,其实现方式也是大赞!

    #8
  • zzbo

    这个很牛B

    #9
  • hacke2

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

    #10
  • 前端农民工

    @hacke2

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

    #11
  • supersha

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

    #12
  • imweb.daniel

    开源了么?比较想用。

    #13
  • 九月枫林

    同问,开源吗

    #14
  • supersha

    @imweb.daniel @九月枫林 现在还在内部应用阶段,后面会考虑开源出来

    #15
  • 九月枫林

    @supersha 赞~

    #16
  • chennanbei

    狂赞

    #17
  • itbeihe

    mark一下

    #18
  • ShinePaul

    mark 赞

    #19
  • Alex020

    赞赞赞

    #20
  • supersha

    在bae上搭了一个海豚的Web平台,只供查看示例运行的数据:http://dolphin.duapp.com/

    #21
  • baeiou

    千呼万唤始出来啊!

    #22
  • kunkun

    好牛逼的样子,多谢分享

    #23
  • 树上有云

    必须赞一下

    #24
  • wanghx

    简直酷炫

    #25
  • raphealguo

    顶一个,回头过来研究一下

    #26
  • simon_htq

    录制屏幕的功能是如何实现的?

    #27
  • joesonw

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

    #28
  • supersha

    @simon_htq js监控页面的事件,然后生成测试用例代码

    #29
  • supersha

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

    #30
登录后回复,如无账号,请使用邀请码注册