【腾讯TMQ】【Android场景化性能测试】UI流畅度篇

一、背景介绍

UI流畅度测试，是笔者设计整个框架的最初的痛点，前述的耗电、内存等属于框架拓展功能。

在本框架之前，部门一直使用GT工具来获取流畅度数据，并使用SM量化模型(一种收集丢帧，并通过合适算法得到最终分数的评估模型)评估流畅度，使用页面驱动的UI自动化来编写用例。但执行了多轮测试后，发现存在一些问题：

1、原方案测试流畅度依赖于ROOT手机，如果需要对某款手机做专门评测，存在局限；

2、由于是借助GT方案收集SM数据，UI驱动中需要先拉起被测应用，以确保GT拿到被测应用的pid，然后拉起GT工具开始收集SM数据，再拉起被测应用开始测试。这样的流程将被重复多次，导致进行一轮性能测试的周期在1小时以上；

3、方案为页面驱动方案，特点是以用户点击为分界点，将流畅度数据拆分成不同页面的数据；

4、UI驱动方案主要是点击文本，在UI自动化中，text点击是需要经过查找、点击，这样会导致每次点击的间隔并不一致。流畅度数据建立在大样本之上才更为准确（反复执行被测场景），但该框架对这种用例逻辑的支持力度不够。

二、GT原理分析

GT工具是腾讯开源的用于测试各类性能数据的工具，分析下它收集流畅度数据的原理。如下图，GT所做的工作有4部分：

1、将系统丢帧告警log的阈值从30修改为1。这个只能在root手机上才操作有效；

2、SMLogService：收集系统中Choreographer打出的丢帧日志，并过滤掉非被测应用的日志，将被测应用的丢帧offer到一个BlockingQueue中；<