360Qtest专栏 移动 H5 广告的性能自动化测试方案

simple · 2018年08月30日 · 最后由 simple 回复于 2018年08月30日 · 1145 次阅读

应用背景

近日公司发布的一款广告应用里,用到了Native和Webview的混合模式,在移动场景下加载H5活动页面,目的是为了根据活动实时更新页面内容而不用升级APP版本,比如世界杯专题。然而在测试过程中发现页面加载的速度非常的慢,白屏的情况频发,鉴于此种情况,需要进行H5的前端性能测试。

前端性能对用户的影响有多大,一组数据可以证明:

前端性能测试中有一种2-5-8原则的说法,即:

页面在2秒内响应的,感觉系统很快;2-5秒响应的,响应速度还可以接受;5-8秒响应的,感觉响应速度慢

项目需求

Wb页面的性能测试行业内探索已久,已经有大量的优秀实践。比如我们所熟知的几种工具:Firebug、YSlow、HttpWatch、Page Speed、WebPagetest等等,移动端通常是通过抓包分析的方式,譬如:Fiddler、Charles、Wireshark,或者远程调试Chrome DevTools的方式。每一种工具都可以拿出单独的篇幅来介绍,本文主要探索移动H5的自动化方案。
先明确我们项目的需求,罗列一下有以下几点:

  • 整个测试方案需要自动化实现
  • 测试方案在移动设备上完成
  • 测试流程在多个手机分布式执行
  • 测试报告可视化,最好是像Chrome dev tool一样直观

明确指标

除了文章开头提到的白屏问题,前端性能最常见的问题无外乎就是,加载慢、响应慢、卡顿不流畅几种,这种用户主观感受如何对应到技术层面指标呢?If you cannot measure it, you cannot improve it. 前端渲染过程中有三个非常关键的指标:

  • Start Render:浏览器开始渲染的时间,即用户在页面上看到的第一个内容的时间
  • DOM Ready:DOM加载并解析解析完成,会触发DOMContentLoaded事件,但是不包括图片、iframe等其它资源的加载
  • Page Load:Page Load时间指的就是window.onload事件触发的时间。与DOM Ready时间相比,Page Load的时间往往要更靠后一些,因为Page Load不仅仅是HTML文档解析完毕还包括了所有资源加载所需要的时间,例如图片资源的加载、iframe的加载等

我们需要做的就是在真实的用户操作过程中拿到这几个指标。

测试方案探索
为了尽可能接近移动设备的操作场景,我们第一种方案确定采用tcpdump通过抓包生成.pcap文件来获取性能数据。

设计流程大概:

  • 具体实现步骤是:

    1. 在我们的Mango平台(手机管理平台)提交H5测试参数
    2. 服务端接收H5参数后,提交任务队列到redis中
    3. Redis检查当前H5测试手机的状态,启动tcpdump监听
    4. Redis启动H5手机的MangoService,根据参数进行H5地址访问
    5. MangoService在访问的URL中注入一段JS代码,利用W3C Performance API获取性能数据,存储到DB中
    6. MangoService测试结束后,告诉Server端测试结束,Redis结束监听
    7. Redis任务将.pcap文件转成har文件
    8. Mango进行web页面展示
  • tcpdump操作流程

    1. 准备几个root权限的手机
    2. 准备tcpdump文件(下载地址:http://www.tcpdump.org/ ,注意,最新的tcpdump不一定能用)
    3. adb push /Users/simple/tcpdump /data/local/tcpdump
    4. adb shell chmod 777 /data/local/tcpdump
    5. adb shell su
    6. /data/local/tcpdump -i any -p -s 0 -w /sdcard/capture.pcap
    7. adb pull /sdcard/capture.pcap /Users/simple/report
  • 注入JS获取性能数据
    我们的做法是在webview注入监控性能的js,然后在加载过程中通过监听页面事件来获取加载过程中的各项性能数据。可能读者会有疑问,为什么使用tcpdump抓取数据包了,还需要用到js注入的手段?因为我们有一个关键指标用tcpdump无法拿到,就是白屏时间,要获取白屏时间这个指标,可能各位还需要了解一下这个名词的概念,目前资料提到的白屏时间获取的办法是* ( responseStart – navigationStart )*,我们需要借助W3C的performance API来拿到这两个指标进行计算。

  • pcap转har
    先说说为什么要把pcap文件转为har文件,因为我们上面提到了,想要得到一个和Chrome dev tools一样的timline图,而恰好有一个工具可以实现har文件转换成前端timline效果图的工具,叫HarViewer。

通过将pcap文件转换为har后,再通过前端js展示,会得到这样的效果页面:

同时,我们通过注入的js回传服务端的性能数据,拿到了相关性能数据进行换算,得到白屏时间和其他时间指标数据,通过取正态分布区间的结果进行计算,就可以得到一次H5性能自动化测试的结果,稍加整理后写个简单的页面进行展示。

后记

听上去似乎是一个完美的解决方案,但是在开展过程中,我们遇到了几个问题:

  • Tcpdump需要root权限,而我们的任务需要分布式执行,且目前高版本的手机root失败率非常高,而且还存在root被还原的情况
  • JS注入以什么方式进行
  • pcap文件的解析对https的请求束手无策,而我们的广告请求都是https的
  • 白屏时间是否是标准答案?

分割线

欢迎访问我们测试团队的官网:http://test.360.cn/

共收到 7 条回复 时间 点赞

很强大移动端前端性能自动化测试方案,能否对注入JS详细展开说说?

paul 回复

还有一篇文章。。是我们最终用的解决方案,这个是初版

这个平台是刚上线不久的吗,我记得你们先前的是360开测

heygrl 回复

跟开测不是一个东西呢,开测也有H5的测试,跟这个不是一个方案,可以参考他们之前发的帖子,用chrome dev tools做的

是刚上线的么,我看好多入口点击没反应

开测那个云真机、一些测试服务可以跟这个平台放一块啊,都是针对测试相关的一些专项,开测那个平台UI不好看,我估计也没什么流量把

heygrl 回复

汗,我帮你反馈给他们哈,是另外一个部门做的

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