终端测试
一、终端测试简介
和传统的PC端测试相比，因为移动终端自身的特性影响，导致终端应用的测试和常见的系统测试有很多不同点。在介绍终端测试之前，我们有必要先熟悉一下移动终端以及终端应用的特性。
移动终端，或许换用智能机我们更加熟悉一些。最常见智能平台有IOS、android、window mobile、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（Out Of Memory）。
二、专项测试VS系统测试
到这里，我们对目前终端环境和终端应用有一个了解，如何对终端APP应用进行高效的测试？如何保证应用在这么多平台、这么多机型上能稳定运行？完全沿用传统的PC端的测试方法显然已经不能完全解决目前的问题了。所以，我们引进了终端专项测试的概念，那终端专项测试和传统意义的系统测试有什么不同？
专项测试的目的是？为啥要做专项？
专项测试就是基于移动设备进行各方面的检测，达到有效性、可用性的要求。终端由于涉及应用程序上架审核以及开发者能力不足等因素，开发周期偏长，且终端的用户并不喜欢频繁主动升级，因此决定了每次更新都需要对引用程序进行专项测试，发现并解决各种功能测试难以发现的问题。
了解了专项测试的目的之后，我们再来看看专项测试和系统测试到底有哪些区别。系统测试的出发点是保证应用程序逻辑正确、功能稳定，专项测试就有些特别了，专项测试会制定特别的测试场景（界面FPS值、界面切换耗时），构造特殊测试环境（弱网络、低电量），借助专门的测试工具monkey（稳定性）、MonkeyRunner（自动化）、AndroidresMonitor（资源监控）、PowerMonitor（耗电量）等，对应用程序进行测试。测试过程中不再是发现功能逻辑的bug，通过专项测试我们可以对应用有一个更深入、全面的了解，了解它的兼容性，网络特性，了解资源占用情况，获取除了功能之后的更多的信息，更像是一个全面的体检。
三、专项测试测什么？
除了功能之后，我们还需要从哪些方面对应用进行测试才能真正做到测试高效和产品质量的把关，也就是专项测试我们需要测试什么？用一句话来回答：“专项测试可以测的东西很多很多，只要是你想测的都可以去测！”似乎说了等于没说，实际上针对终端应用的专项测试项是有很多，除了一些比较通用的测试项如兼容性、性能、资源消耗、网络测试之外，还有很多是需要根据应用自身特性进行“定制”的，以一淘Android客户端为例，启动耗时、登录耗时和流量、打开商详页面的速度、数据的冗余比、界面FPS等等。
基本上专项测试可以简单的分为两大类：一类是通用的测试项，不同终端应用都要测试的点；另一类就是应用的“定制测试项”，具体因产品而异。下面我们来梳理一下专项测试的常见测试场景。
资源类性能测试
Ø CPU占用
Ø 内存占用/内存泄漏
Ø 低资源环境表现
Ø 弱网络测试
速度类性能测试
Ø FPS测试
Ø 端到端业务延时
Ø 速度分析：客户端+网络+服务器
稳定性测试
Ø MTTF
Ø Monkey test
兼容性测试
Ø 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助手等
Ø 测试方法：
资源源消耗测试的方法基本上是，在各种场景下进行操作，通过监控工具获取到应用的资源消耗数据；为了提高执行的效率和减少人工操作的影响，不同测试场景下的操作，也是通过脚本的方式进行执行的。