鲁班：移动App端自动化性能测试的一种实践

我们先了解一下移动端app性能评测相关问题和诉求，app性能评测或者度量常常碰到这样的问题，首先通过系统原生支持的api或者开源的工具单纯的去获取数据的话，需要了解许多相关的命令或者需要测试者至少具备很多跨平台的知识内容去手工获得，这就在实际操作过程中产生了几个问题：

数据的准确性

数据的可靠性

数据的量

这三个问题是基本同时发生的，对于评测移动端性能测试活动来说，这些要求是最基本的和最重要的，其次在这个基础上面我们也希望无人或者少有人工参与的投入，来实现对App的性能数据收集（包括对竞品App），产出足够数据量的评测数据报告，使得测试效率能够大大增强。但是现在面临上面的几个问题，是在Android和iOS 端都有的。

另外评测需要有本品和竞品的对比，既然是对比肯定需要相同条件场景下执行的测试活动，比如同等网络环境，设备机型，类似业务，触发时机等， 这里最重要的是类似业务，体现在App中就是有序的ui操作场景，所以非常大的区别于monkey这种无序执行活动。

那么对于ui这种有序的自动化实现，肯定要不管是录制脚本还是，自己写脚本，都是需要参与脚本的修改活动，因此，这里最好能有一个简单的配置化将复杂的脚本实现滤去，提供一个人人都懂的，易上手的配置服务，同时支持线下调试的工具，以保证配置的内容能够在线上多台设备上正常运行。

对于设备数量问题，尤其是Android设备厂商，主流机型多不胜数，选择多台设备，下发自己的测试业务场景的配置，实现多台设备自动化性能数据收集，也是需要大量计算资源和设备池的。这块我们后面会讲到借助百度现有平台实现这样远程设备租赁，开启自动化场景。

因此，我们总体概括了一下业务线的诉求为：能执行有序ui自动化场景，数据实时精准收集展示，设备远程服务下发执行和采样数据量足够多，双端上执行支持线下调试。

我们把以上一些需求和问题分为有这样几点，来实现：

有简单的配置服务可以触发性能测试驱动，实时数据收集；

性能收集数据能和页面驱动结合在一起；

报告邮件整体数据汇总，单次运行数据图形展示；

支持App自动安装和特殊设备资源选择；

双端支持线下对配置的内容调试；

我们先看一下Android端的这种技术实现方式

a、Android自动化性能测试方案的实现方式：

对于Android端的性能自动化测试评测方案，我们提供两种方式第一种方式是通过pc工具支持客户端线下调试的性能自动化测试，第二种是远程端批量设备性能自动化测试。

先提一下客户端线下调试的性能自动化测试：

提供客户端支持自动化性能测试主要有两个目的：

第一个：配置场景在用户接入的单台或者几台设备下能正常运行后，可以提交到鲁班平台来做大量设备运行的一种调试目的。

第二种：特殊场景无法自动化实现的或者远程控制无法达到目的的，比如扫码跳转，AR场景，语音输入测试等这些无法通过自动化实现的或者远程控制无法满足的场景，可以通过客户端支持少量设备的手工驱动来实时自动收集数据，以达到评测目的。

这种pc客户端支持的方式可以极大的解决用户需要参与脚本的编写和学习一门工具的成本，同时客户端也提供易用的向导型操作。提供一张截图，可以一观究竟：

可以看到支持触发方式有两种：手工（自动化无法满足但是可以自动性能数据收集），Daily驱动，其实是自动驱动App ui，同时自动收集性能数据。目前，性能数据在Android端支持有：cpu，内存使用率，App打点的响应时间，耗电数据，和帧率，这些数据的获取方式基本采用adb现有命令，通过配置间隔时间的长短来获取，这里不是一种什么创新内容，因此不过多说明。

我们接下来主要看一下这个工具的整体实现方式，大家可以看一下如下图：

总共分为三个部分，鲁班pc，鲁班App，和鲁班平台。

鲁班pc：提供的向导支持，同时将adb的执行能力封装在内部，使得用户无需对手机进行root，就可以吊起和收集性能数据。

鲁班App封装了底层的uiautomator的动作api，同时也提供个性化的组合形式动作对应到鲁班平台上支持用户配置选择，同时支持手机内被测试App的下载，和数据的http传输，避免由于大量数据走远程tcpip端口，连接中断的带宽问题。

鲁班平台支持配置化序列动作，提供诸如滑动，点击，图像OCR识别（主要针对h5的页面，或者定位较复杂的一种方式）的点击，输入等一系列动作内容。支持case的集合等。平台支持场景下发到手机端进行触发就是上面看到的“daily运行”触发方式，一旦用户在鲁班pc客户端调试好，并能运行正常，即可将这些配置提供给线上集群测试手机运行起来。

因此这里的流程上是整体贯通且在使用上也符合基本用户习惯，方便于新功能的扩充以及用户的可视化配置可视化运行的需求。

远程端批量设备性能自动化测试

一般很多公司都会提供不同网段的网络连接给到服务器和手机，所以对于Android的远程连接这种跨网段方式就成为了问题，百度QA的RMTC远程手机租赁平台就是将这种手机与服务器的网络进行穿透，使得手机能够被服务器远程挂载，同时也支持了类似开源工具STF的设备集中管理的内容，具体大家可以去参考STF，对于如何搭建这样的技术平台，感兴趣的同学可以耐心等待这块后面分享的内容。

很多人知道在adb client挂载到服务器后就会和adb server进行连接，如果用户想要对手机进行远程控制，就会由adb server和手机的adbd连接通过tcp进行通信。

那么我们又碰到一个技术问题，一个App如果需要有30台主流设备进行这样的自动化性能测试，一台服务器最多能挂多少台？答案不确定，我们尝试一台8核128G内存的服务器最多20台，由于adb server的本身设计并不是给到有这样大规模的调度上面使用的，所以在稳定性上面存在问题，如果我们在往上面挂载就会碰到手机无法远程连接成功的情况。

对于鲁班平台需要为多数产品App提供稳定性能测试服务的情况，因此，我们就需要部署挂载这样的连接环境，最大限度的使用一台服务器的资源。下面就是对于Android远程设计的整体架构。

我们通过把手机调度的能力和对接到远程设备资源池的申请服务能力以及adb server相关依赖镜像打包到各个服务器,如上图业务逻辑层封装了远程设备资源的申请能力，任务调度层实现负载均衡，并封装了abd server所有镜像依赖，通过鲁班server api对外实现上层的任务触发，在手机端预装有鲁班App来实现这些服务被调用。这样就克服了之前说的adb sever不稳定情况，以及最大程度的利用好资源。

上面在鲁班pc客户端的性能测试中我们提到了鲁班App的作用，这里其实是一样的，在用户把场景配置完毕，在鲁班pc上运行调试后就可以直接在平台上选择性能测试任务将场景下发到指定的多台设备上，就可以触发多台设备测试了。下面是实际用户会执行的操作内容。

1、填写配置场景

2、选择多设备执行case

3、具体设备的执行性能趋势图

在实际使用中其实还是有面临一些用户不清楚的地方，诸如设备申请，ip切换，场景配置下发动作等等，因此我们将一些使用的经验值作为默认值，通过用户一次配置，把所有的执行过程都通过接口一次调用，并加入到App编译打包快速迭代流程后的过程中，默认下载到手机设备里安装，执行有序的场景集合的性能测试，最后到App自身性能测试数据的一键产出的能力。减少用户的配置成本。

讲完了Android的客户端和远程控制的自动化性能测试方案，我们来看一下iOS端，

b、iOS自动化性能测试方案的实现方式：

我们始终按照上面提到的这种原则，避免用户投入大量的时间配置环境或者对平台工具的学习，将其分解为ui自动化的驱动加上数据的自动化收集，和平台对收集的数据进行分析，这三种。主要用于本品的数据与竞品的数据之间的对比与评估。

我们看一下下面的框架图：

主要采用的是facebook的WDA的开源的自动化方案一台mac一拖4~6台iOS设备（xcode远程连接或者有线连接都支持该服务能力）通过iproxy的端口映射，客户端如上图就是launchclient.py的一个运行器，实际在使用中这个已经二进制化转为被鲁班pc调用的文件，可以远程通过http发送平台下发的配置转成指令到mac上进行多台设备的驱动运行。

对于iOS性能数据的收集，其实有些复杂，一般做法是开发一个sdk嵌入到宿主App中，在App稳定接近发布前状态后交付QA，做线下性能的本品与竞品的评估。只要打开预先设置的开关，这样当场景被驱动执行时，数据也会按照设定的间隔时间进行收集，并传输到后端进行实时分析处理。这样的方案对于线上的性能数据监控其实非常不错，但是问题竞品怎么办？这样的问题就需要亟待解决。

对于竞品App，如上图，我们需要准备一台已经越狱的设备主要是对App进行破壳处理生成App的. Decrypted文件，然后对破壳处理后的ipa文件进行重签名，使得Instruements能够获取到性能数据，包括：

cpu使用率, memory使用率，帧率FPS，以及流量等指标，对于耗电量数据需要xcode9.2以上的无线支持。

对于以上破壳重签名的操作步骤，详细可以联系鲁班平台接口人即可，这里不加篇幅说明。

在针对iOS性能数据获取方案，以上步骤即便做好了，也会在接下来碰到一个致命的问题，数据虽然出来了，但是数据怎么保存呢，Instruments保存的是二进制文件，对于长时间运行需要直观地看整个App场景的数据趋势情况以及运行的历史数据情况，这就要求对数据以明文出现，并提供存储方案。

鲁班平台后端对这种二进制文件也做了很好的解析，这里instruments的数据收集产生的二进制文件内容，首先我们肯定该工具是苹果官网认可的最可信的工具了，所以我们可以不用怀疑它的数据准确性，该内容中有cpu和内存的现成的值，但是没有流量和耗电数据的值需要在该文件找到对应id号去找关联的有苹果公司在手机中自动生成的一个sqlite数据库文件，找到流量和耗电的相关的几张表格（可以查看官网各个字段都有说明）就可以获取你需要的内容了。

通过将二进制文件进行解析为明文保存在手机中，一旦测试场景中断或者运行完成就会将这些数据上传到鲁班后端进行分析。

大家可以看一下以下针对百度App的性能测试自动化实际效果，场景配置完成后生成一个测试集合id，这些配置内容对应Android都是一样，因此可以互相转换，实际使用流程也完全一样。再通过鲁班pc选择对应设备触发，就可以吊起之前提到的lauchclient.py的转化后的二进制执行文件。

当选择了iOS设备并进行相关的mac的环境检查完毕后，就可进入后面的自动化性能数据，之所以使用的wda驱动，主要是考虑在响应速度上比appium更加快速稳定性也相比较高，百毫秒内基本得到响应，足以满足日常的使用者的要求：

通常平台上对于数据展示其实最为客观，但是某种程度上我们还是希望邮件中也能够整体汇总出这种数据对比趋势和数据的客观性。

如下图大家可以看到，按照场景纬度，筛选核心用例对多个竞品展开分析的邮件报告，增减情况一目了然。

对于Android／iOS端的自动化性能评测方案基本就说到这里，里面的有很多细节没有过多提到，希望大家可以直接通过官方hi号或者公众号留言给我们。

也希望和大家在这方面共建发展。

作者介绍

孙健百度资深测试开发工程师，负责糯米相关项目测试开发工作