一 概述
1: app 测试内容:
(1) 常规的功能和性能:功能遍历,业务响应速度,界面测试等等.
(2):专项测试:主要是系统指标:(包括耗电,内存占用,流量消耗,cpu(计算量),启动速度,流畅度,安装包大小);
(3):特殊测试:弱网络测试, 用户体验测试(流畅度,易用性);终端兼容性测试
(4)信息安全测试
2: app 测试工具
3: 测试效果评价(二) app 测试
常规测试
这部分和一般的软件测试时比较相似的。重点还是:功能覆盖测试
界面的易用性测试。 这个基本上要靠人来看。
目前常规功能测试这块，业界比较推崇的工具是：Appium。
其实对服务端也要关注：
重点就是业务响应速度。专项测试特别流畅度是关心终端性能，业务响应速度是从服务端来说的。当然这些和普通的Web测试没有太大区别。
(三) # 专项测试(专项性能测试)
3.1 启动
启动一般分为：
冷启动：首次启动 时间一般为ms，通常要求1000ms以下，600ms为较好指标
冷启动命令：adb shell am start -W -n 包名/activity
冷启动停止：adb shell am force-stop 包名
热启动：应用切换到后台再次被唤起
热启动命令：adb shell am start -W -n 包名/activity
3.2 电量
GT(测试安卓手机的工具)可以直接看到
命令（5.0以上系统才可以）：
1.下载historian.py脚本，下载地址：https://github.com/google/battery-historian，后面用
2.执行步骤
1)初始化batterystats数据
adb shell dumpsys batterystats–reset
2）拔掉手机，操作app，操作完成后，重新连接手机，执行下面的命令，收集系统整体的Battery数据:
adb shell dumpsys batterystats > batterystats.txt
3）得到这些数据后，这个时候使用我们的battery-historian来生成我们可见HTML报告:
python historian.py batterystats.txt > batterystats.html
4）用google浏览器打开此文件即可
备注：阅读腾讯TMQ的《移动APP性能评测和优化》，基本思路也是分析batterystats日志，找到异常，再回头来看是代码问题还是系统设置或用户环境原因。
3.3 内存
Android用AS中的MemoryMonitor大概看看，比如内存始终在增长、内存抖动等。然后dump内存hprof文件出来用MAT分析一下，一般的Heap的内存问题基本就可以发现了。
摘抄腾讯TMQ的《移动APP性能评测和优化》中的一些方法和经验：
1）最常规也最重要的当然是MAT，分析hprof文件，获得内存消耗的排行分析，据此有针对性地来改良代码。一般地图片和大数组消耗没有释放等，可以很快发现。
2）代码中存在的内存泄漏，一般可以用代码白盒分析工具，找到疑点。常见的如Klocwork。
3）dumpsys meminfo来观察应用的内存消耗情况。了解APP运行过程中，内存组成各部分的变化情况。
内存中存在大量的Dalvik Pss，一般就是出现碎片问题。可能原因如大循环中的临时变量等。
dex文件优化：中载入类文件，由于次序问题（按照类名字母顺序）载入，但释放时不是这个顺序，合理命名有助于次序一致，减少载入类文件带来的碎片的出现。（这个一般对大应用比较明显）
3.4 流畅度
现在一般的方法是测试FPS。用TraceView来看。但其实这种方法有它不合理的地方，比如画面静止的时候，FPS为0，但不卡。因此，腾讯TMQ的《移动APP性能评测和优化》中，采用平滑度（SM）来评估，就是评估CPU能不能处理得过来，60次每秒的处理率，能够满足说明处理得过来，不卡。
3.5 cpu 使用率
这个指标其实是很有误导性的，多核和单核；多线程和单线程处理；为省电降频；等等；例如，多核移动CPU为了省电，平时只用低频的4核工作，不搞清楚原理，只是全速运行然后得到一个数值，其实是不太合适。腾讯TMQ的《移动APP性能评测和优化》中，提出Jiffies来考核，就是处理事务所用的CPU周期数
3.6 流量统计
App的流量消耗是必须要测试的。但这个测试其实是一个伪命题，简单来说，应该是两种业务需求的测试：一个是测试网络环境优良情况下，APP业务工作时候的流量情况；一个是日常没有业务操作的守候情况下的流量消耗情况；至于弱网络情况下的，这个应该放到特殊专项测试里面去处理。其他的应该根据业务场景来分别设计。
流量测试的基本方法就是抓包，例如tcpdump；不过常用方法应该还是设置PC为代理服务器，通过安卓终端连接PC，在PC上抓包。抓包前准备工作：把其他APP能卸载的卸载掉，能关闭连接的都关闭掉后台服务，减少干扰。抓包一般转化成txt或者xml文件，然后用python等编制好的自动化处理脚本提取出来，方便分析。3.7 安装包大小
这个一般不需要单独测试了，打包后看下大小就知道了。关键的在于如何去优化，减小安装包。方法当然很多，着手的方向主要是两个，一个是代码，一个是资源。（腾讯TMQ的《移动APP性能评测和优化》第6章）
代码：1、去除废代码、冗余代码 用Lint一般可以发现；2、去掉不必要功能；3、调整代码，去掉一些method；4、使用代码混淆（文件命名等处理）；
资源：1、去除冗余资源 用Lint扫描；2、资源混淆；3、压缩图片大小，不必要的可以降低图片精度，调整图片格式等；4、减少一些资源，非常偶尔用的可以用到时再去服务器下载；
最后，还可以 优化压缩算法，也许可以进一步减少安装压缩包。四 特殊测试
4.1 兼容性测试
这个一般测试都不会有那么多真机或者平台。可以考虑使用云测平台，比如tetsin；或者自建单位内部众包平台，拉单位人员和外部一些友好用户进来，和用灰度测试的方式，预发布，在一段时间内收集问题。
4.2 弱网络测试
一般的方法都是使用模拟软件，控制丢包率来进行模拟，搭好平台实测一下即可。其实众包平台往往更合适。另外，腾讯GT诞生时就是所谓的随身调平台，带上这个工具，去实际路测一下，也可以算是一种简化版的测试方式。
4.3 用户体验测试
这个其实很难说，因为流畅度、易用度、界面设计等等这些真的是要人来体验了。一些可靠性的问题，例如，适时保存数据；提示存盘；防止外部通知、外部访问、网络中断或网络延迟较大等导致crash这一类APP必然会遇到的实际应该算功能问题，应该考虑作为功能问题来覆盖，而不是放到用户体验里面来笼统地应付。可以根据策略简化测试，但是要独立出来，不要混。
4.4 信息安全测试
非常非常重要。现在没有也没有特别好办法，一般还是用Burpsuite或Drozer一类软件扫描来
# 五 app 测试工具
工具太多，其实用好Android自带的各个工具基本就可以了：Lint、MAT、DDMS、Systrace、Traceview。抓包的Fiddler设呢么的酬和着用用。其他的建议关注Appium和GT。1、Appium
2、GT 使用比较方便
六 测试效果评价
1: 测试前评审、测试执行中和测试后总结-----覆盖完整度：（新应用，要求花一定时间来设计和讨论（相当于评审）；每日测试完成，要讨论和评估一下测试效果）
a) 测试设计首先要覆盖完整，比如不要漏了服务端，不要漏了信息安全测试，不要缺了一些重要的专项测试，考虑了，但是根据实际情况可以不测试，这个是另外一回事；测试范围和测试策略选择始终是测试方案设计的重点；
b)常规功能首先覆盖完整；各种应用场景要考虑清楚，不要美其名曰探索性测试，然后随意点来点去，发现一堆问题，最后发现弱网络没测试，网络切换场景没做，跳转支付没考虑等等。
c)测试手段覆盖完整：可以在APP开发的时候就先做一下设计评审，评估需求是否合适、合理；测试前可以先上Lint一类的白盒工具，或者并行
2:测试中和测试后及时总结
a): 测试覆盖度，必要时要补充设计，重新测试
b):发现问题的情况：问题的类别和趋势还是要适时分析评估，顺便可以要求开发者改进
c):测试工作本身是否可以模板化甚至工具化
d):其实团队负责人要借这个总结评估一下团队成员情况
