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

©️2020 CSDN 皮肤主题: 大白 设计师:CSDN官方博客 返回首页