App测试实战：测试内容、测试工具、测试效果

零、概述

  0.1App测试内容：

       1、常规的功能和性能：功能遍历、业务响应速度、界面测试等

       2、专项测试：主要是 系统指标包括耗电、内存占用、流量消耗、CPU（计算量）、启动速度、流畅度、安装包大小

       3、特殊测试：弱网络测试、用户体验测试（流畅度、易用性）、终端兼容性测试

       4、信息安全测试

    0.2 App测试工具：

        

   0.3  测试效果评价

 

一、APP测试

1、常规测试

这部分和一般的软件测试时比较相似的。重点还是：

功能覆盖测试。  

界面的易用性测试。 这个基本上要靠人来看。

目前常规功能测试这块，业界比较推崇的工具是：Appium。

其实对服务端也要关注：

   重点就是业务响应速度。专项测试特别流畅度是关心终端性能，业务响应速度是从服务端来说的。当然这些和普通的Web测试没有太大区别。

2、专项测试（专项性能测试，也是终端特有的）

2.1 启动

启动一般分为：

冷启动：首次启动   时间一般为ms，通常要求1000ms以下，600ms为较好指标

冷启动命令：adb shell am start -W -n 包名/activity

冷启动停止：adb shell am force-stop 包名

热启动：应用切换到后台再次被唤起

热启动命令：adb shell am start -W -n 包名/activity

2.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日志，找到异常，再回头来看是代码问题还是系统设置或用户环境原因。

2.3  内存

Android用AS中的MemoryMonitor大概看看，比如内存始终在增长、内存抖动等。然后dump内存hprof文件出来用MAT分析一下，一般的Heap的内存问题基本就可以发现了。

摘抄腾讯TMQ的《移动APP性能评测和优化》中的一些方法和经验：

1）最常规也最重要的当然是MAT，分析hprof文件，获得内存消耗的排行分析，据此有针对性地来改良代码。一般地图片和大数组消耗没有释放等，可以很快发现。

2）代码中存在的内存泄漏，一般可以用代码白盒分析工具，找到疑点。常见的如Klocwork。

3）dumpsys  meminfo来观察应用的内存消耗情况。了解APP运行过程中，内存组成各部分的变化情况。

   内存中存在大量的Dalvik Pss，一般就是出现碎片问题。可能原因如大循环中的临时变量等。

  dex文件优化：中载入类文件，由于次序问题（按照类名字母顺序）载入，但释放时不是这个顺序，合理命名有助于次序一致，减少载入类文件带来的碎片的出现。（这个一般对大应用比较明显）

2.4 流畅度

现在一般的方法是测试FPS。用TraceView来看。但其实这种方法有它不合理的地方，比如画面静止的时候，FPS为0，但不卡。因此，腾讯TMQ的《移动APP性能评测和优化》中，采用平滑度（SM）来评估，就是评估CPU能不能处理得过来，60次每秒的处理率，能够满足说明处理得过来，不卡。

2.5  CPU使用率

         这个指标其实是很有误导性的，多核和单核；多线程和单线程处理；为省电降频；等等；例如，多核移动CPU为了省电，平时只用低频的4核工作，不搞清楚原理，只是全速运行然后得到一个数值，其实是不太合适。腾讯TMQ的《移动APP性能评测和优化》中，提出Jiffies来考核，就是处理事务所用的CPU周期数。

2.6  流量统计

       App的流量消耗是必须要测试的。但这个测试其实是一个伪命题，简单来说，应该是两种业务需求的测试：一个是测试网络环境优良情况下，APP业务工作时候的流量情况；一个是日常没有业务操作的守候情况下的流量消耗情况；至于弱网络情况下的，这个应该放到特殊专项测试里面去处理。其他的应该根据业务场景来分别设计。

      流量测试的基本方法就是抓包，例如tcpdump；不过常用方法应该还是设置PC为代理服务器，通过安卓终端连接PC，在PC上抓包。抓包前准备工作：把其他APP能卸载的卸载掉，能关闭连接的都关闭掉后台服务，减少干扰。抓包一般转化成txt或者xml文件，然后用python等编制好的自动化处理脚本提取出来，方便分析。

2.7安装包大小

       这个一般不需要单独测试了，打包后看下大小就知道了。关键的在于如何去优化，减小安装包。方法当然很多，着手的方向主要是两个，一个是代码，一个是资源。（腾讯TMQ的《移动APP性能评测和优化》第6章）

       代码：1、去除废代码、冗余代码  用Lint一般可以发现；2、去掉不必要功能；3、调整代码，去掉一些method；4、使用代码混淆（文件命名等处理）；

        资源：1、去除冗余资源 用Lint扫描；2、资源混淆；3、压缩图片大小，不必要的可以降低图片精度，调整图片格式等；4、减少一些资源，非常偶尔用的可以用到时再去服务器下载；

        最后，还可以 优化压缩算法，也许可以进一步减少安装压缩包。

3、特殊测试

         3.1  兼容性测试 

          这个一般测试都不会有那么多真机或者平台。可以考虑使用云测平台，比如tetsin；或者自建单位内部众包平台，拉单位人员和外部一些友好用户进来，和用灰度测试的方式，预发布，在一段时间内收集问题。

        3.2 弱网络测试

        一般的方法都是使用模拟软件，控制丢包率来进行模拟，搭好平台实测一下即可。其实众包平台往往更合适。另外，腾讯GT诞生时就是所谓的随身调平台，带上这个工具，去实际路测一下，也可以算是一种简化版的测试方式。

         3.3 用户体验测试

         这个其实很难说，因为流畅度、易用度、界面设计等等这些真的是要人来体验了。一些可靠性的问题，例如，适时保存数据；提示存盘；防止外部通知、外部访问、网络中断或网络延迟较大等导致crash这一类APP必然会遇到的实际应该算功能问题，应该考虑作为功能问题来覆盖，而不是放到用户体验里面来笼统地应付。可以根据策略简化测试，但是要独立出来，不要混。

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）其实团队负责人要借这个总结评估一下团队成员情况。