前端测试 海豚-Web UI 自动化测试平台

shafeng · 2015年09月23日 · 最后由 pan 回复于 2017年12月04日 · 413 次阅读
本帖已被设为精华帖!

海豚是什么?

没错,它是一个 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 的出现。期待吧~~

在这个论坛注册了很久了,一直都是在看文章,现在写篇文章,介绍下自己重新开发的一个 UI 自动化测试平台,欢迎拍砖!

共收到 29 条回复 时间 点赞

贴一个站外可访问 URL:http://dolphin.duapp.com 只有历史运行的记录,没有运行 worker 对接。仅供查看。

这个开源吗?

#2 楼 @franky 现在阿里内部对开源抓的比较严,不过我会推动开源出去。目前在内部业务应用实践中。

看上去还是挺不错的,能开源就好了,因为需要测试环境,对外都是不开放的。

#3 楼 @supersha 赞,阿里的事情就是需要推动。

这不就是我想做的么,赶紧开源,哈哈。

当看到性能数据统计那一块的时候,必需上来支持一下,看起来是 css 定位的,支持 XPath 吗?

#7 楼 @watman 性能统计数据 css 定位? 不太明白你的意思。涉及到 Selector 的都是 CSS 标准的选择器。

#8 楼 @supersha 他的意思是

当看到性能数据统计那一块的时候,必需上来支持一下。
看起来是 css 定位的,支持 XPath 吗?

做的好牛. 真想开放的话, 可以分三步走. 公布公开在线服务, 公布 docker 部署方案允许私有部署. 最后开源代码.

感谢 lihuazhang 的翻译。一个标点符号引发的 BUG。希望将来能开放出来造福大家

惊叹作者的开发能力和思想落地能力,赞一个,坐等开源。

做这个需要花多久时间呀?

被评论给带偏了, 作者都没提开源. 我觉得能够开放这个思路就很好了. 大家别奢求太多, 关键的还要靠自己去做

#13 楼 @simonpatrick 3 个月差不多

非常棒的产品!测试行业太需要这样有想法、有创意、又实干的人啦!作为同样从事自动化测试的创业者,必须要赞一个!

16楼 已删除

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

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

#1 楼 @supersha 问下楼主,文中的录制工具是自己写的吗?

真是 666666,大赞. 想问两个问题

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

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

#22 楼 @jet 后面我抽空单独对录制这块的功能发个帖子说明一下,并贴出来源码

#24 楼 @supersha 棒。 持续关注中

这就是我苦苦寻求的东西啊 特意注册上来回复的 楼主,对于 pc 端的测试,你这套系统是否也同样支持呢?

#26 楼 @jayfan 支持的哦,已经有 PC 的业务在投入使用中

shafeng [该话题已被删除] 中提及了此贴 07月06日 22:53

很棒,先赞一个!

好厉害,刚入职的小菜鸟开拓思路了,刚开始做 ui 自动化,尤其遇到 ui 频繁变动的问题,js 业务逻辑的监控这个想法很棒,求后续继续分享~!

请问下如何获取海豚测试平台,觉得很有趣,想研究下

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册