A-A+

前端测试 海豚 (Web UI 自动化测试平台) 近期的功能更新

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

距离之前写的一片介绍海豚的文章:海豚-Web UI 自动化测试平台 已经有一段时间了,简单介绍下到目前为止海豚所更新的一些功能以及一些思考。

到目前为止公司内部已经有八九个业务在使用(没有在本团队之外的团队分享过海豚,都是慕名而来并使用上的)。这是自己能够继续坚持开发海豚更多功能的动力啊。

自己所负责的业务也在深度使用,不再担心上线的功能会影响到其他的功能,并且没有及时发现。

功能更新点:

  1. 添加了request response ajax jsonp 等自定义事件,用于处理页面的请求
    • monitor.on("request", function(request){}) 所有页面发起的请求都会触发该事件
    • monitor.on("response", function(response){}) 所有页面请求的响应都会触发该事件
    • monitor.on("ajax", function(event){}) 页面所有的Ajax请求会触发该事件,JSONP的请求类似
  2. 添加了monitor.consoleInfos()方法,用于收集页面上所有console.info输出的内容,供使用者收集信息
  3. 添加了monitor.ignoreJSError monitor.ignoreResourceError monitor.setExcludeDomainError 这三个接口,用户忽略掉页面上的一些不可避免的错误和误报数据
  4. 添加了定时运行任务的支持(加入crontab功能)
  5. 添加了 monitor.define monitor.require接口,用于测试用例的模块化管理机制
  6. 录制工具升级,缩短录制的selector,并添加行为路径说明,比如://点击“电影”(navi-item tap-on tap-bgc tap-round on-route > span) --> 点击“全部”(class:tab-all) --> 点击“精选”(class:tab-recommend on)
  7. 添加了monitor.mock(string, mockData)接口,用户捕获页面发起的异步请求(Ajax/JSONP),并模拟请求响应的数据,这样不用服务端造各种逻辑数据了,更加方便各种应用场景
  8. 优化了任务运行Inspector工具的信息展现,方便调试。并且对于使用者不再那么黑盒:

更多内部功能上的细节就不多罗列了。上面的功能点都是业务使用之后所提出来的需求点,每一个点都非常实用。

规划中的两个比较重要的点

  1. pagediff支持HTML结构模型的diff方案。
    • 原因:因为基于原有的pagediff按照页面样式和HTML结构的方式,很容易由于数据上的变动,导致很多误报的diff出来,造成了困扰。
    • 初步方案:基于HTML结构模型的方式,设置一个HTML结构模型的语法(可以多个),按照这个模型来匹配
    • 模型设计方案:

    • 可以配置是否对样式也同时监控
  2. 性能加载监控
    • 监控页面的首字节、HTML文档加载、首屏、加载完毕等时间信息
    • 按照每小时获取性能数据,并图表展示性能趋势图
    • 性能数据变化过大报警功能
  3. JavaScript截图
    • html2canvas的方案在移动设备上性能太成问题了
    • 需要研究一种性能更好的方案来实现在UIWebView上的纯JS截图方案

问答:

1).diffy降噪的思路可以借鉴下. 访问多次, 通过对比排除变化的字段. 然后再结合黑名单.

2).看了这贴之后又回头去补了你们前面的那个帖子。发现pagediff很有意思啊,我很有兴趣研究下这个是怎么玩的。多谢楼主

答:看看 https://github.com/fouber/page-diff 这个开源的工具哈

 

3):

page diff 这也是个做自动化的新思路。

1、这个是不是要保证测试数据一致,否则怎么生成特定的html?

2、然后怎么保存历史页面呀,把对应的源码下载做记录?

3、直接抓屏,然后灰度化,直接图片对比不就成了,为什么费劲分析html呢?

答:

先说你第二个直接抓屏的问题,这个误报率太高了,特别是像现在lazyload的应用那么广泛,图片的加载稍微还没有出来就去截屏diff了,这样的情况发生的概率很大。所以不去做图片的像素diff。

使用page diff,海豚有一个“基线”的概念,就是用同样的数据跑一次,如果觉得这一次跑出来的结果是符合当前预期的,那么就设置为基线,下次的运行都基于这份基线做diff。如果最新跑出来的跟基线有diff,但是又符合新功能的预期的,那么就又可以设置为新的基线,一直循环这样。

page diff保存的不是html源码,保存的是当前这个页面状态下指定DOM下的所有子元素DOM以及它的样式,这就是要遍历整个DOM,并获取到DOM元素的样式,然后生成一份JSON数据,最后保存的是这份JSON数据文件。

4)对于流程比较长的业务场景,比如 查看-购买-修改数量-支付-查看订单,依赖的接口多,接口的超时情况又比较多,你们是怎么处理呢?就等待接口返回吗?有什么优化办法吗?我们现在就遇到这种情况,测试环境中依赖的接口不稳定,导致脚本大量失败。

答:

测试接口不稳定,啥自动化测试工具都没用。接口超时、或者挂了,影响了后面所有的流程。接口稳定性方面是作为一个基础的保障才能更好的做好前端的UI自动化测试。 目前我们跨页面流的测试模式也是有的,对于执行的每一步,都可以自定义等待多少时间才执行下一步。我觉得自动化测试,如果对运行时间不是要求太苛刻的话,稍微每一步10s所有的设置都还是可以接受的。

 

标签:

给我留言

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

用户登录