monkeyrunner

终端测试概要

终端测试

⼀、终端测试简介

和传统的PC端测试相⽐，因为移动终端⾃⾝的特性影响，导致终端应⽤的测试和常见的系统测试有很多不同点。在介绍终端测试之前，我

们有必要先熟悉⼀下移动终端以及终端应⽤的特性。

移动终端，或许换⽤智能机我们更加熟悉⼀些。最常见智能平台有IOS、android、windowmobile、blackberry等等，从市场占⽐来

看，IOS和android是绝对的主导者。移动终端除了平台的多样化之外，各个移动设备⽣产商提供的产品更是五花⼋门，让⼈眼花缭乱。每

⼀款⼿机的屏幕⼤⼩、分别率、CPU和内存的⼤⼩等等都不相同，平台和硬件配置的差异化给终端应⽤带来了巨⼤的挑战。开发如何能保证

应⽤能兼容不同平台、不同硬件环境下正常使⽤？测试⼈员怎么样去⾼效测试终端应⽤？这些问题都需要我们进⼀步去探索。

和PC端对⽐，我们可以梳理出终端的⼏个不同点：

①⽹络因素影响⼤：移动设备的⽆线⽹络有不同的运营商（移动联通电信），还有2G、3G、WIFI等等对应⽤⽹络相关功能都有产⽣影

响；

②硬件配置限制：由于移动设备的CPU内存电量等等跟PC相⽐都是有限的，所以对应⽤的运⾏环境和资源消耗产⽣了很⼤限制；

③设备机型多：不同的⼚商的不同型号的设备，CPU型号、内存的⼤⼩、屏幕⼤⼩等等有差异；

④应⽤随机Crash：应⽤程序的Crash也是我们使⽤过程最不能容忍的问题，也是开发和测试最先需要发现和解决的问题。

因为终端⾃⾝特性的影响，移动终端应⽤⽬前最⼤的问题有三个⽅⾯：

1.慢

终端应⽤的“慢”主要体现在两个⽅⾯，⼀个是移动⽹络的慢，⽤户当前的⽹络状况不好（⽹络拥塞），或者⽤户使⽤的是2G⽹络（和3G

还有WIFI⽐确实是慢），这种情况下⽤户登录、数据上传、下载、刷新等等都会出现卡顿现象。此外，应⽤程序⾃⾝的慢也是⼀个常见的问

题。应⽤有⼤量消息需要接收，打开⼀张10M的图⽚、滑动界⾯刷新内容，我们这些操作之后往往需要等待；

2.卡

程序运⾏的流畅度也是我们测试过程中，除了功能之外的⼀个重要的⽤户体验考察点。点击后很长时间才响应，滑动过程很卡，界⾯切换不

流畅等等都是应⽤需要解决和优化的问题。究其原因，主要是对硬件环境的不兼容还有就是应⽤占⽤的CPU过⾼，导致系统长时间不响应或

者功能的计算量很⼤使部分中低配置⼿机的CPU负荷过⾼。

3.随机Crash

对于程序⽽⾔最致命的bug就是crash。但是终端应⽤在各种操作、不同硬件环境、系统平台都会出现crash。通过crash的⽇志我们可以定

位到crash的原因，测试过程中最常见的crash原因就是系统/硬件不兼容导致的启动crash、部分API调⽤crash、读写数据crash等,还有就

是OOM（OutOfMemory）。

⼆、专项测试VS系统测试

到这⾥，我们对⽬前终端环境和终端应⽤有⼀个了解，如何对终端APP应⽤进⾏⾼效的测试？如何保证应⽤在这么多平台、这么多机型上能

稳定运⾏？完全沿⽤传统的PC端的测试⽅法显然已经不能完全解决⽬前的问题了。所以，我们引进了终端专项测试的概念，那终端专项测

试和传统意义的系统测试有什么不同？

专项测试的⽬的是？为啥要做专项？

专项测试就是基于移动设备进⾏各⽅⾯的检测，达到有效性、可⽤性的要求。终端由于涉及应⽤程序上架审核以及开发者能⼒不⾜等因素，

开发周期偏长，且终端的⽤户并不喜欢频繁主动升级，因此决定了每次更新都需要对引⽤程序进⾏专项测试，发现并解决各种功能测试难以

发现的问题。

了解了专项测试的⽬的之后，我们再来看看专项测试和系统测试到底有哪些区别。系统测试的出发点是保证应⽤程序逻辑正确、功能稳定，

专项测试就有些特别了，专项测试会制定特别的测试场景（界⾯FPS值、界⾯切换耗时），构造特殊测试环境（弱⽹络、低电量），借助专

门的测试⼯具monkey（稳定性）、MonkeyRunner（⾃动化）、AndroidresMonitor（资源监控）、PowerMonitor（耗电量）等，对

应⽤程序进⾏测试。测试过程中不再是发现功能逻辑的bug，通过专项测试我们可以对应⽤有⼀个更深⼊、全⾯的了解，了解它的兼容性，

⽹络特性，了解资源占⽤情况，获取除了功能之后的更多的信息，更像是⼀个全⾯的体检。

三、专项测试测什么？

除了功能之后，我们还需要从哪些⽅⾯对应⽤进⾏测试才能真正做到测试⾼效和产品质量的把关，也就是专项测试我们需要测试什么？⽤⼀

句话来回答：“专项测试可以测的东西很多很多，只要是你想测的都可以去测！”似乎说了等于没说，实际上针对终端应⽤的专项测试项是

有很多，除了⼀些⽐较通⽤的测试项如兼容性、性能、资源消耗、⽹络测试之外，还有很多是需要根据应⽤⾃⾝特性进⾏“定制”的，以⼀

淘Android客户端为例，启动耗时、登录耗时和流量、打开商详页⾯的速度、数据的冗余⽐、界⾯FPS等等。

基本上专项测试可以简单的分为两⼤类：⼀类是通⽤的测试项，不同终端应⽤都要测试的点；另⼀类就是应⽤的“定制测试项”，具体因产

品⽽异。下⾯我们来梳理⼀下专项测试的常见测试场景。

资源类性能测试

ØCPU占⽤

Ø内存占⽤/内存泄漏

Ø低资源环境表现

Ø弱⽹络测试

速度类性能测试

ØFPS测试

Ø端到端业务延时

Ø速度分析：客户端+⽹络+服务器

稳定性测试

ØMTTF

ØMonkeytest

兼容性测试

ØAndroid版本

Ø分辨率

Ø硬件配置

应⽤定制测试项

Ø协议测试、数据冗余⽐、成功率

Ø。。。

上⾯列举了这么多测试项，那怎么才能和我们具体的应⽤测试结合起来呢？应⽤的定制项要怎么来制定呢？下⾯将会以⼀个拍照装扮类的应

⽤为例，介绍如何分析应⽤的专项测试点以及制定⼀个全⾯的专项测试计划。

我们现在要测试是⼀个android上的拍照应⽤（例如美图秀秀），应⽤的主要功能是拍照，然后可以编辑照⽚，添加相框、⽂字和LBS等，

此外，⽤户也可以把装扮好的照⽚分享到空间、微博、微信等平台。

在我们开始系统测试之前，我们⾸先需要做的就是梳理测试点，专项测试也是如此。⾸先我们需要了解我们需要测试的应⽤，它的核⼼功

能，使⽤场景，⽹络特性等⽅⾯，然后就是分析每⼀个功能点对应的专项测试点。

在梳理出应⽤核⼼功能和关键路径等需要关注的测试点后，接下来要做的就是对这些测试点“取并集”，并根据每⼀项测试点的重要性划分

对应的优先级以及⼯作耗时，前期也可以确定相对应的测试⽅法和⼯具，测试数据标准和辅助数据等。

在完成专项测试计划之后，我们还有⼀个⼯作需要完成，和系统测试⼀样，我们也要有专项测试的测试⽤例。基本的流程也是需求分析、测

试设计、测试⽤例编写、⽤例评审。下⾯以资源消耗测试项的⽤例举例，我们在资源消耗⽅⾯主要考虑的是CPU和内存的使⽤量，特别需要

说明的是，应⽤是否有内存泄漏也是我们更加关注的，所以在进⾏资源消耗测试时，我们要保证应⽤没有内存泄漏的前提下，开展相关测

试。

四、专项测试怎么做四、专项测试怎么做

在制定完应⽤的专项测试计划之后，在什么阶段进⾏专项测试呢？是在系统测试的时候才执⾏，还是不同的开发阶段可以执⾏不同的测试

项？执⾏的时候有哪些⾼效的⽅法和⼯具呢？怎样通过测试数据分析是否有问题呢？带着这些问题，我们了解⼀下专项测试要怎么做。

⾸先我们通过⼀个项⽬流程图来分析⼀下开发流程、系统测试和专项测试的流程关系，专项测试的流程⼤体上和系统测试类似，也是先根据

需求制定出测试计划，完成专项测试⽅案，待功能实现之后，再进⾏专项测试。专项测试在切⼊的时间点上以及各阶段完成的⼯作内容上也

有很⼤的不同。

在新功能稳定（没有功能bug）之后，专项测试已经可以介⼊完成⼀些测试项的⼯作。系统测试阶段，是测试主要阶段，此外，灰度发布和

发布之后，专项测试⼯作还会继续，如完成竞品测试、⽤户反馈问题跟进。下⾯我们从专项测试的介⼊时间点来分别介绍各阶段专项测试需

要完成的⼯作和测试的⽅法。

1.需求评审阶段

在需求评审阶段，除了全⾯的了解产品的特性、技术需求、技术⽅案外，专项测试同事需要做的是根据现有的需求信息分析其中的风险点，

并根据这些风险点制定相应的测试项，通过后期的专项测试发现和规避问题。

Ø⽹络风险

断⽹重连，断点续传逻辑

是否会产⽣⼤流量，流量合理性（流量消耗和发送的⽂件⼤⼩是否近似）

请求-响应来回次数较多，是否会增加失败率

协议必须有压缩策略

有没有缓存机制

ØUI风险

存在IO操作，例如保存，导⼊，导出，发送，上传，当遇到⼤数据时是否有加载过程

元素或动态/可变元素过多过复杂，是否会造成界⾯卡顿和CPU长期偏⾼（如LISTVIEW复杂格式或有动态图）

元素加载时机（如滑动列表时，头像加载的时机）

Ø电量/CPU风险

地理位置相关逻辑，检测逻辑（如⼈脸识别、贴⽿检测），

后台服务（如tcp⼼跳逻辑），

⾳视频相关

ØOOM风险

缓存策略，加载⼤数据策略（如拉取查看⼤图bitmap）

GC策略

Ø兼容性风险

较新的系统特性

通过系统API/系统数据库获取数据

硬件相关（摄像头，屏幕触碰效果，声⾳⼤⼩，gps）

除了上⾯提到的五个⼤类的风险之外，还需要根据应⽤⾃⾝的特性和实现技术⽅案等因素考虑其他的风险点，原则是“具体问题，具体分

析”。

2.新功能阶段

在开发同事紧张的编码实现新功能过程中,针对已有的功能模块(或者提测的demo版本)也可以开展部分专项测试⼯作。在介绍新功能测试阶

段专项测试的⼯作内容之前，我们先关注⼀下这个阶段我们在执⾏专项测试时需要注意的⼏个问题：

Ø原则：发现问题为先，兼顾数据沉淀

Ø事前能做的：

可对⽐的历史场景数据（注意再测试的设备/环境⼀致性）

缺乏对⽐的历史数据先补充，沉淀现有数据

⽤MonkeyRunner简单的⾃动化脚本，可以让资源监控的曲线的趋势更加明显

测试环境准备：如测试号码，⼿机选型，测试数据预先构造等等

Ø流量指标可以先测

Ø发现专项问题，请直接先提单

Ø功能稳定后，再关注FPS,内存,CPU等

在把握这些测试注意事项之后，我们来分析⼀下新功能测试阶段，专项测试的主要关注点/测试项，如果和⼤家测试的应⽤不完全覆盖，实

际操作时⼤家可以⾃⾏裁剪：

Ø关注FPS:动画效果

例如，列表滚动，展⽰内容的滚动

Ø关注内存，CPU,线程：可重复执⾏的动作

例如，切换帐号，界⾯打开关闭

Ø关注流量，耗时，成功率：⽹络相关操作

例如，发送消息，发送图⽚，下载数据

Ø关注电量/CPU:持续的动作和⽤户⾼频率的操作

例如，放置后台，发送⼼跳包

Ø关注速度：界⾯切换，内容加载

例如，启动速度

下⾯将会以新功能测试阶段常见的3个专项测试项实例，资源类测试、⽹络测试和流畅度测试，给⼤家介绍专项测试具体的执⾏过程和测试

⽅法。

2.1资源类测试

由于移动终端本⾝资源的限制，⼿机应⽤的资源消耗也是终端测试的⼀个重要的关注点。⾼资源消耗不仅会降低应⽤的⽤户体验，对应⽤⾃

⾝的稳定性也有很⼤的影响。所以，通过测试分析应⽤是否有资源问题（如内存泄漏），或者可以优化点（资源占⽤过⾼），降低应⽤的资

源消耗，提⾼应⽤的稳定性，是必要⽽且有价值的。

实际测试过程中，资源测试我们主要关注的是CPU、内存和流量，还有就是电量。

Ø主要测试场景：

1)测试场景是和⽤户密切相关的：要包含⽤户实际的使⽤场景、特性；

2)⾼资源消耗场景：加载⼤数据、重复性⾼的操作；

3)产品的关键路径：更多的考虑产品的特性，制定明确的关键路径；

4)需要尝试/探索测试的点：专项测试中的资源类和速度类测试包括发现相关问题以及性能的优化两⽅⾯；

Ø测试⼯具：

1)CPU、内存、流量：AndroidResMonitor（python脚本⼯具）;

2)电量消耗：PowerMonitor（硬件设备检测），⼿机管理软件，如android助⼿等

Ø测试⽅法：

资源源消耗测试的⽅法基本上是，在各种场景下进⾏操作，通过监控⼯具获取到应⽤的资源消耗数据；为了提⾼执⾏的效率和减少⼈⼯操作

的影响，不同测试场景下的操作，也是通过脚本的⽅式进⾏执⾏的。