基于UI响应时间的移动App性能测试解决方案

抛出问题

    移动端的性能测试指标有很多,分为响应时间类,资源消耗类,包括cpu、mem、电量、流畅度,网络流量,其中最影响用户体验的就是响应时间,因为它的好坏直接关乎用户的直观感受,所以参考价值也最高。而已有响应时间测试方法存在局限性,如何低成本的快速开展App响应时间性能测试呢?

已知的方法

  • 方法一:Android端可通过AM计算App启动时间,或者通过DisplayManager日志计算activity打开时间。
  • 方法二:程序植入log打点代码,通过特定位置的日志标签计算启动或页面加载时间。
  • 方法三:通过摄像或者截图,然后使用手工或程序的图像对比方法计算。

存在的缺点

  • 方法一计算得出的结果往往和人眼感知的结果存在差距,这是因为页面加载一般存在网络异步交互,原生的系统日志,无法准确表达App的响应时间,且测试范围存在局限性,对于特定场景,例如控件级别的加载或渲染无法实现测量。
  • 方法二涉及到产品代码的侵入,需要保证测试代码和产品发布代码的有效隔离,无形中增加了产品代码维护成本。除非必要,一般也不会在实际项目中使用。
  • 方法三缺点是,要么依赖高速摄像器材,要么使用手机自身截图的方式,后者容易对测试本身产生干扰,测试结果的权威性无法保证,因为截图本身消耗了计算资源。前者测试成本投入较大。另外,程序图像对比也经常产生误差,例如手机屏幕上的时间标签刚好在图像对比那一帧发生了变化,图像对比结果就会出现错误。

基于UI响应时间的移动App性能测试解决方案_第1张图片

聚焦关键点

    从已有方法看出,方法三最契合我们的诉求,但它的缺点也比较明显,例如,高速摄像采集成本高;截屏采集对测试环境产生污染;图像对比容易受干扰。为了能给出人眼视觉的响应时间的量化值,并且保证结果准确、项目应用成本低。我们采用自动化+外置图像采集+图像对比算法优化的整体技术方案。

关键点一:无污染

目标:屏幕采集,需要避免对测试环境产生污染,保证测试环境本身干净。
方案:外置摄像头录屏
实施:1、win pc+外置摄像头2、手机、外置摄像头连接电脑,win窗口显示摄像头采集内容3、win api抓取win窗口图片
说明:截图频率直接影响测试结果的误差精度,窗口截屏抓取程序运行时,图片数据使用内存存储,只在case结束时,完成一次硬盘IO存储操作。这样做是为了提高截图速度,实现了20ms一次截图。
基于UI响应时间的移动App性能测试解决方案_第2张图片

关键点二:抗噪点

目标:图像对比,需要过滤图片色差、局部变化的干扰,尽可能贴近人眼观察认知。
方案:图像对比算法忽略局部噪点,采用感知哈希算法,只关注图片整体结构,忽略细节。
算法:
基于UI响应时间的移动App性能测试解决方案_第3张图片

完整的实施路线图

基于UI响应时间的移动App性能测试解决方案_第4张图片

技术实现

  1. 自动化驱动:MonkeyRunner驱动
  2. 图像对比:python PIL感知哈希算法实现
  3. 截屏:WIN API截屏,20ms截取一次
  4. 时间一致性保障:时间系统统一,都采用windows系统时间。

原理说明

    Case驱动原理,在一个操作之后等待较长时间,app界面处于响应结束状态。开始时间是自动化脚本触发的,可以记录,结束时间从图片序列由后往前对比,找到最后一个变化的图片代表的时间就是结束时间。两者之差就是响应时间。以app启动时间的响应时间为例,自动化case伪代码就是:1、启动app并记录启动时间2、开启截图程序,实现录屏 3、等待足够久的时间4、case结束,截图程序保存截屏图片。5、图像对比使用感知哈希算法计算结束时间。

你可能感兴趣的:(移动测试工具,app性能测试)