能用机器完成的,千万别堆工作量:持续集成中的性能自动化测试

栏目: 服务器 · 发布时间: 5年前

内容简介:背景

能用机器完成的,千万别堆工作量:持续集成中的性能自动化测试

背景

能用机器完成的,千万别堆工作量:持续集成中的性能自动化测试

当前闲鱼在精益开发模式下,整个技术团队面临了诸多的能力落地和挑战,尤其是效能方面的2-1-1的目标(2周需求交付周期,1周需求开发周期,1小时达到发布标准),在这个大目标下,就必须把每个环节都做到极致。自动化的建设是决定CI(持续集成)成败的关键能力,今天分享一下闲鱼Android客户端性能自动化环节的实践。

能用机器完成的,千万别堆工作量:持续集成中的性能自动化测试

面临的问题

能用机器完成的,千万别堆工作量:持续集成中的性能自动化测试

1 发现问题

  • 工具缺失:

目前淘宝系,对于线上性能水位的监控有一套完善的体系,但是针对新功能的性能测试,每个业务团队都有对应的性能专项小组,产出的 工具 都是根据自己业务特点的定制开发的,闲鱼客户端目前使用Flutter做为客户端主开发语言,对于Flutter性能数据的获取及UI自动化测试支撑工具目前是缺失的,同时业界对Flutter自动化和性能相关的实践几乎没有;

  • 测试工作量翻N倍(N=一个版本周期内的分支数):

原先的开发模式是功能测试集成测试一起进行的,所以性能测试只需要针对集成后的包进行测试即可,到现在转变为泳道的开发模式,一个版本内会一般包含十几个左右的泳道分支甚至更多,我们必须确保每个泳道的分支的性能是达标的,如果有性能问题需要第一时间反馈出来,如果遗留到集成阶段,问题的排查(十几个分支中筛查),问题的解决将会耗费大量的时间,效率很难得到大的提升;

2 分析问题

体系化解决,要让每个泳道分支都得到有效测试覆盖,测试件能够自动化执行,持续反馈结果。

能用机器完成的,千万别堆工作量:持续集成中的性能自动化测试

能用机器完成的,千万别堆工作量:持续集成中的性能自动化测试

解决方案

能用机器完成的,千万别堆工作量:持续集成中的性能自动化测试

综合上述问题,梳理如下解决方案:

  • 针对Flutter性能数据的获取(比如,Flutter有自己的SurfaceView,原有Native计算FPS的方式无法直接使用)

  • 针对Flutter UI自动化的实现(Flutter/Native UI混合栈的处理)

  • 性能自动化脚本 / 性能数据自动采集、上报 融入CI流程

  • 性能问题的通知 / 报表展示 / 分析

1 性能数据

[FPS]

解析处理 adb shell dumpsys SurfaceFlinger --latency 的数据,详细请见文末参考链接(该方式兼容Flutter及Native的解决方案,已在Android4.x-9.x验证可行),处理SurfaceFlinger核心代码如下:

[CPU]

使用的是top的命令获取(该方式获取性能数据时,数据收集带来的损耗最少)

[内存]

解析 dumpsys meminfo $package 拿到 Java Heap,Java Heap Average,Java Heap Peak,Native Heap,Native Heap Average,Native Heap Peak,Graphics,Unknown,Pss 数据

[流量]

通过 dumpsys package packages 解析出当前待测试包来获取流量信息

2 性能自动化脚本

  • 基于Appium的自动化用例,这个技术业界已经有非常多的实践了,这里我不再累述,如果不了解的同学,可以到Appium官网 http://appium.io

  • Flutter和Native页面切换使用App内的Schema跳转

  • Flutter页面的文本输入等交互性较强的场景使用基于Flutter框架带的Integration Test来操作

An integration test
Generally, an integration test runs on a real device or an OS emulator, such as iOS Simulator or Android Emulator. The app under test is typically isolated from the test driver code to avoid skewing the results.

Flutter的UI自动化及Flutter/Native混合页面的处理在测试上的应用后续单独开文章介绍,原理相关可以先参考《千人千面录制回放技术》。

3 性能自动化CI流程

能用机器完成的,千万别堆工作量:持续集成中的性能自动化测试

4 性能数据报表

[ FPS ]

能用机器完成的,千万别堆工作量:持续集成中的性能自动化测试

  • Framediff: 绘制帧的开始时间和结束时间差

  • FPS: 每秒展示的帧数

  • Frames: 一个刷新周期内所有的帧

  • jank: 一帧开始绘制到结束超过16.67ms 就记一次jank,jank非零代表硬件绘制掉帧,和屏幕硬件性能及相关驱 动性能有关

  • jank2: 一帧开始绘制到结束超过33.34ms 就记一次jank2

  • MFS: 在一个刷新周期内单帧最大耗时(每两行垂直同步的时间差代表两帧绘制的帧间隔)

  • OKT: 在一个刷新周期内,帧耗时超过16.67ms的次数

  • SS: 流畅度,通过FPS,MFS,OKT计算出来,流畅度 = 实际帧率比目标帧率比值 60【目标帧率越高越好】 + 目标时间和两帧时间差比值 20【两帧时间差越低越好】 + (1-超过16ms次数/帧数)*20【次数越少越好】

[ CPU ]

能用机器完成的,千万别堆工作量:持续集成中的性能自动化测试

[ Memory ]

能用机器完成的,千万别堆工作量:持续集成中的性能自动化测试

能用机器完成的,千万别堆工作量:持续集成中的性能自动化测试

成果展示

能用机器完成的,千万别堆工作量:持续集成中的性能自动化测试

1 指定泳道分支性能监控

泳道分支出现了性能问题再报表上一目了然

能用机器完成的,千万别堆工作量:持续集成中的性能自动化测试

2 性能专项支撑

Flutter商品详情页重构 14轮测试

能用机器完成的,千万别堆工作量:持续集成中的性能自动化测试

客户端图片统一资源测试 4轮测试

能用机器完成的,千万别堆工作量:持续集成中的性能自动化测试

能用机器完成的,千万别堆工作量:持续集成中的性能自动化测试

总结

能用机器完成的,千万别堆工作量:持续集成中的性能自动化测试

性能自动化只是整个CI流程中的一个环节,为了极致效率的大目标,闲鱼质量团队还产出了很多支撑工具,CI平台,遍历测试,AI错误识别,用例自动生成等等,后续也会分享给大家。

能用机器完成的,千万别堆工作量:持续集成中的性能自动化测试

参考

能用机器完成的,千万别堆工作量:持续集成中的性能自动化测试

https://testerhome.com/topics/2232

https://testerhome.com/topics/4775


以上就是本文的全部内容,希望本文的内容对大家的学习或者工作能带来一定的帮助,也希望大家多多支持 码农网

查看所有标签

猜你喜欢:

本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们

Orange'S:一个操作系统的实现

Orange'S:一个操作系统的实现

于渊 / 电子工业出版社 / 2009-6 / 69.00元

《Orange S:一个操作系统的实现》从只有二十行的引导扇区代码出发,一步一步地向读者呈现一个操作系统框架的完成过程。书中不仅关注代码本身,同时关注完成这些代码的思路和过程。本书不同于其他的理论型书籍,而是提供给读者一个动手实践的路线图。读者可以根据路线图逐步完成各部分的功能,从而避免了一开始就面对整个操作系统数万行代码时的迷茫和挫败感。书中讲解了大量在开发操作系统中需注意的细节问题,这些细节不......一起来看看 《Orange'S:一个操作系统的实现》 这本书的介绍吧!

JS 压缩/解压工具
JS 压缩/解压工具

在线压缩/解压 JS 代码

MD5 加密
MD5 加密

MD5 加密工具

HEX CMYK 转换工具
HEX CMYK 转换工具

HEX CMYK 互转工具