APP专项测试 _link之家

1.为什么做专项测试？专项测试包含哪些？

也许你会经常发现，我们已经做了完整的功能测试，但是却依然会在客户手机上出现：app崩溃了？用久了手机发烫？流量消耗很大？一开手机就卡...这些问题通过普通的功能测试很难发现，于是我们需要做专项测试去发现这些问题：Crash、设备兼容、流量使用过大、APP导致用户手机电量消耗过快的问题、在不同的网络下不稳定（比如卡死和白屏）

专项测试包含：稳定性测试、内存测试、CPU测试、耗电量测试、流畅度测试、流量测试

2.adb

见前面文章 juejin.cn/post/684490…

使用模型器安装app会出现如下错误，需要下载Genymotion-ARM-Translation-Librarities工具转换包；下载路径： pan.baidu.com/s/1kUAftyR，…

3.monkey

见前面文章 juejin.cn/post/684490…

4.内存测试

adb shell cat /proc/meminfo #查看设备内存使用情况
复制代码

MemTotal：可以使用的内存总和（小于实际RAM，操作系统预留了一部分）
MemFree：未使用的内存
Caced:缓存（app可以申请到的内存）
HightTotal:内存中地址高于860M的物理内存总和，只能被用户空间的程序使用
HightFree：内存中地址高于860M的未使用内存
LowTotal:内存中内核和用户空间程序都可以使用的内存总和（对于512M的RAM LowTotal=MemTotal）
LowFree:内存中内核和用户空间程序未使用的内存（对于512M的RAM:LowFree=MemFree）
----一般SwapCached（交换内存）内存有值的时候可能内存不够用
复制代码

adb shell dumpsys meminfo xxx(包名)#查看某个应用内存使用信息
#一般先记录内存占用情况，然后运行APP，再记录内存占用，对比2次发生的变化
复制代码

内存采集工具：(sdk里自带)sdk>tools>monitor.bat
采集内存左侧进程只有模型器可以显示出来，真机无法显示
内存分析工具：下载地址http://www.eclipse.org/mat/downloads.php
采集导出的文件需要首先转换下然后再导入到内存分析工具中，转换工具在sdk里：sdk>platform-tools>hprof-conv.exe
DOS下进入到导出hprof文件路径下执行hprof-conv xxx(原文件名) XXX（转换文件名）
分析工具的使用教程参考：https://www.cnblogs.com/gongshun/articles/10082750.html
Histogram可以列出内存中每个对象的名字、数量以及大小。
Dominator Tree会将所有内存中的对象按大小进行排序，并且我们可以分析对象之间的引用结构。
一般最常用的就是以上两个功能了
现在点击Dominator Tree，结果如下图所示：
Retained Heap表示这个对象以及它所持有的其它引用（包括直接和间接）所占的总内存，因此从上图中看，前两行的Retained Heap是最大的，我们分析内存泄漏时，内存最大的对象也是最应该去怀疑的。
另外大家应该可以注意到，在每一行的最左边都有一个文件型的图标，这些图标有的左下角带有一个红色的点，有的则没有。带有红点的对象就表示是可以被GC Roots访问到的，根据上面的讲解，可以被GC Root访问到的对象都是无法被回收的。那么这就说明所有带红色的对象都是泄漏的对象吗？当然不是，因为有些对象系统需要一直使用，本来就不应该被回收。我们可以注意到，上图当中所有带红点的对象最右边都有写一个System Class，说明这是一个由系统管理的对象，并不是由我们自己创建并导致内存泄漏的对象。
那么上图中就无法看出内存泄漏的原因了吗？确实，内存泄漏本来就不是这么容易找出的，我们还需要进一步进行分析。上图当中，除了带有System Class的行之外，最大的就是第二行的Bitmap对象了，虽然Bitmap对象现在不能被GC Roots访问到，但不代表着Bitmap所持有的其它引用也不会被GC Roots访问到。现在我们可以对着第二行点击右键 -> Path to GC Roots -> exclude weak references，为什么选择exclude weak references呢？因为弱引用是不会阻止对象被垃圾回收器回收的，所以我们这里直接把它排除掉，结果如下图所示：
可以看到，Bitmap对象经过层层引用之后，到了MainActivityLeakClass这个对象，然后在图标的左下角有个红色的图标，就说明在这里可以被GC Roots访问到了，并且这是由我们自己创建的Thread，并不是System Class了，那么由于MainActivity$LeakClass能被GC Roots访问到导致不能被回收，导致它所持有的其它引用也无法被回收了，包括MainActivity，也包括MainActivity中所包含的图片。
通过这种方式，我们就成功地将内存泄漏的原因找出来了。这是Dominator Tree中比较常用的一种分析方式，即搜索大内存对象通向GC Roots的路径，因为内存占用越高的对象越值得怀疑。
接下来我们再来学习一下Histogram的用法，回到Overview界面，点击Histogram，结果如下图所示：
这里是把当前应用程序中所有的对象的名字、数量和大小全部都列出来了，需要注意的是，这里的对象都是只有Shallow Heap而没有Retained Heap的，那么Shallow Heap又是什么意思呢？就是当前对象自己所占内存的大小，不包含引用关系的，比如说上图当中，byte[]对象的Shallow Heap最高，说明我们应用程序中用了很多byte[]类型的数据，比如说图片。可以通过右键 -> List objects -> with incoming references来查看具体是谁在使用这些byte[]。
那么通过Histogram又怎么去分析内存泄漏的原因呢？当然其实也可以用和Dominator Tree中比较相似的方式，即分析大内存的对象，比如上图中byte[]对象内存占用很高，我们通过分析byte[]，最终也是能找到内存泄漏所在的，但是这里我准备使用另外一种更适合Histogram的方式。大家可以看到，Histogram中是可以显示对象的数量的，那么比如说我们现在怀疑MainActivity中有可能存在内存泄漏，就可以在第一行的正则表达式框中搜索“MainActivity”，如下所示：
可以看到，这里将包含“MainActivity”字样的所有对象全部列出了出来，其中第一行就是MainActivity的实例。但是大家有没有注意到，当前内存中是有11个MainActivity的实例的，这太不正常了，通过情况下一个Activity应该只有一个实例才对。其实这些对象就是由于我们刚才不断地横竖屏切换所产生的，因为横竖屏切换一次，Activity就会经历一个重新创建的过程，但是由于LeakClass的存在，之前的Activity又无法被系统回收，那么就出现这种一个Activity存在多个实例的情况了。
接下来对着MainActivity右键 -> List objects -> with incoming references查看具体MainActivity实例，如下图所示：
如果想要查看内存泄漏的具体原因，可以对着任意一个MainActivity的实例右键 -> Path to GC Roots -> exclude weak references，结果如下图所示：
可以看到，我们再次找到了内存泄漏的原因，是因为MainActivity$LeakClass对象所导致的。
好了，这大概就是MAT工具最常用的一些用法了，当然这里还要提醒大家一句，工具是死的，人是活的，MAT也没有办法保证一定可以将内存泄漏的原因找出来，还是需要我们对程序的代码有足够多的了解，知道有哪些对象是存活的，以及它们存活的原因，然后再结合MAT给出的数据来进行具体的分析，这样才有可能把一些隐藏得很深的问题原因给找出来。
5.CPU测试
adb shell dumpsys cpuinfo
adb shell dumpsys cpuinfo | grep packagename
adb shell "top -n 1|grep com.douban.frodo"  #具体看某一应用占用情况
6.耗电量
#1.重置电池手机数据
adb shell dumpsys batterystats --reset
#2.操作APP
#3.将采集数据保存到文件
adb shell dumpsys batterystats > batterystats.txt
复制代码
7.流畅度
流畅度谷歌官方解释:每秒60帧（每帧16.6ms）的速度运行，也就是60fps,并且没有任何延迟或者掉帧。
三个考量指标：
FPS：每秒的帧数
丢帧（SF：Skipped Frame）：在16.6ms完成工作因各种原因没做完，占了后n个16.6ms的时间，相当于丢了n帧
流畅度（SM:SMoothness）：和丢帧相对，在VSync机制（安卓系统每隔16ms发出VSync信号,触发对UI进行渲染）中1s内Loop运行的次数
分析参考：blog.csdn.net/adyw2565876…
复制代码
8.流量测试
#获取APP的pid（注意对于高版本的andriod需要加上-A，低版本的可以不用）
adb shell ps -A |findstr com.chinaymt.app # 结果第二列为app的pid
#根据pid获取流量(28332为上一步得到的pid)
adb shell cat /proc/28332/net/dev#下图展示的为APP的下载和上传流量，然后操作业务再次记录下载和上传的流量，两次结果相差值为对应业务的流量值
常见问题：请求的内容包含一些相对静态的信息，可第一次请求包括静态信息，后面的同类请求只包含即时的变化的信息即可；短时间内发送多个同样的请求，收到结果也几乎一样，这种情况应该较少请求次数，同时注意排查程序逻辑问题，问题可能不像表面那样简单；无用请求，以前版本遗留下来的获取其他代码偷偷发出的；永远连接失败或返回404，可能是某个失效的功能，后台取消了前台还未取消不停的发送请求。
9.弱网测试
弱网测试主要进行特殊网络状态下的功能测试并同时关注用户体验，主要包括:弱网功能测试、无网状态测试、网络切换测试、用户体验
弱网功能测试:非wifi(2G/3G/4G)网络环境下，同时模拟高延时和高丢包的异常情况下进行健壮性测试。将整体的所有功能测试用例在弱网环境下进行一轮测试。
常见发现的问题：页面图片在弱网环境下加载不出来（图片加载逻辑需优化）、页面响应时间较长没有任何提示（一般可以显示网络加载超时或者重试机制）、需要模板的页面版式结构混乱（模板文件在弱网环境的加载需优化）等。
无网状态测试：在切断网络的情况下进行测试，主要关注页面的显示与交互、本地数据的存储、断网后功能的使用。
断网状态下如果请求的非本地数据的页面需要设定等待上限提示网络异常或重试；
如果请求一部分本地数据，一部分非本地数据的页面，本地数据需要加载正常，待请求的数据是否符合交互给的缺省样式一致；如果请求完全本地数据的页面，显示是否正常，同时还需考虑本地数据存储的情况，有些需要联网后上报服务器的数据本地是否正确存储，联网后这些数据能否正常上报。
综上无网测试按照页面划分进行，针对每个页面单独测试无网状态的显示，页面跳转显示，页面内功能的点击和显示，同时关注无网到有网时的页面恢复显示状态，数据上报是否正常。
网络切换测试：主要针对不同网络环境场景的切换，wifi->2G/3G/4G、wifi->无网、2G/3G/4G->wifi、2G/3G/4G->无网、无网->2G/3G/4G、无网->wifi。主要关注页面的显示与交互，特别是弱网到wifi,WiFi到弱网的情况，是否会出现页面的crash以及显示错乱、session是否一致、请求堆积处理等。
用户体验：弱网的测试目的主要是保证用户体验，主要关注的点：
页面的响应时间是否可接受，关注包括热启动、冷启动，页面切换，前后台切换，首屏时间；页面显示是否完整一致；超时文案是否符合定义，异常信息是否显示正常；是否会有超时重连机制；是否发生dns劫持、登录IP更换频繁、单点登录异常；大流量事件风险：是否会在弱网下进行更新apk包、下载文件等大流量动作。
弱网模拟使用工具fiddler:
点击工具栏Rules->Customize Rules,修改delay改变上传和响应的速度，改完之后保存，记得再去勾选Rulues-Perfomances-Simulate Modem Speed
上面红框里标出的是设置延时时可以操作的上行和下行网络延时时间（每上传/下载1kb的数据要延迟多少毫秒）默认为3000ms,下载上行的速度=1000/delay的毫秒数
复制代码