最开始进行内存测试时，我们可能还有些摸不着头脑，试着找了些工具，看了看教程就开始动手了。有时候因为问题比较明显，就真的发现了问题。再之后遇到类似的测试需求，我们就会按上次的经验去做。有时候可能发现问题，也可能发现不了，还有些时候甚至是在白费工夫。因为随着明显的问题逐渐被找出来，剩下的都是更加复杂而不太明显的问题了，甚至有些问题更是可以归属到优化范畴或者产品策略之内，而不再是简单的内存问题。
随着经验的逐渐增加，我们逐渐意识到，以前的很多测试方法都属于随机乱测。对于较为成熟的软件，这类方法的测试有效性往往比较低，运气好了才会遇到问题。如果是较深层次的问题，要么遇不到，要么遇到了也找不出原因。因此，有必要总结出一套成熟的流程方法，能够考虑到各个方面，才能提高测试的有效性。
1.2.1 测试流程
由于内存测试属于性能测试，Android系统又和Linux有很多相通之处，因此我们可以参考常见的Linux性能测试方法和指标，来制定客户端性能测试方案。常见的测试方法包括Monkey/UIAutomator类的常规压力测试、大数据/操作的峰值压力测试、长时间运行的稳定性测试等。这些方法都可以叠加在内存测试的方案中，观察这类场景下的应用内存情况，经常能够发现类似内存泄漏或OOM的问题。
参考了常见性能测试的方案，以及总结了以往对内存性能测试的经验后，我们总结出了一套进行内存测试的经验性流程，下面介绍这个流程中的要点。
1.代码
通常用来进行内存测试的版本是纯净版本，不应该附加多余的Log和调试用组件。例如有些情况下，为了测试界面延迟/函数执行时间等性能，会加入一些桩点代码。在内存测试中这些代码是不必要的，它们可能会分配临时内存，引起更多的GC，导致应用出现运行缓慢、卡顿等现象。
2.测试场景
测试场景通常有两类。一类是当前有新开发或改动的某项功能，需要对该功能进行性能测试。因此测试场景主要针对该功能组织，包括功能的开启前、运行、结束后等测试点。另一类是整体性能，考察应用的常见场景，在综合使用情况下的性能指标。测试场景应当包括启动后待机，切换到后台，执行主要功能，以及反复执行各功能后。
在各类场景中，经常作为测试重点的有：
- 包含了图片显示的界面。
- 网络传输大量数据。
- 需要缓存数据的场景。
3.场景转换成用例
选取了测试场景后，用例设计也要考虑内存测试的特点。一些常见的方法是：
- 结合场景比较操作前后或不同版本的内存变化。
- 显示多张图片的前台进程。
- 多个场景来回切换。
- 长时间运行进程的内存增长。
4.执行
由于GC和广播机制的存在，应用内存通常都在不停地波动，幅度可能会达到几百KB，因此执行时需要考虑这种情况。在采集数据时，需要多次采集并计算平均值。
执行完成，我们就可以根据数据进行比较初步的分析以确定方向。一方面是我们熟悉的Dalvik Heap部分，即由Java代码直接分配的内存，可以通过IDE直接观察到使用情况，也可以使用MAT进行细致的分析。
另一方面，假如我们发现Dalvik Heap没怎么增长，而其他部分增长了许多，这种情况下的分析就要复杂一些，我们留待后面的章节再说。
1.2.2 Dalvik Heap的常见问题
随着测试的执行，随之而来的就是一大堆产生的数据。对产生的数据进行分析，找出可能存在的问题，以及问题可能的原因是接下来的重点。
由于大部分Android应用是以Java代码开发的，所以Dalvik Heap内存出现问题也是最常见的情况。常见的现象有以下几种：
- 随着功能的反复执行，Heap内存一直在持续增长。这种情况通常是出现了内存泄漏，这种情况最适合用LeakCanary等泄漏检查工具进行白盒测试分析。
- 代码执行时出现了频繁的GC，Heap Alloc内存大幅度波动。这种情况通常是分配了许多临时变量或数组，随后又被迅速回收，这种情况在确定具体场景后适合使用Heap Viewer/Allocation Tracker等工具来查看具体分配的对象。
- 每次启动应用后，Heap内存相比以前版本稳定增长。这种情况通常出现在启动后待机或使用某功能后，可能是由新功能及代码改动引入的固定内存增长。这种情况适合获取Heap Dump后进行多版本或功能使用前后的对此，能够迅速找到增长原因。
- Heap Alloc变化不大，但进程的Dalvik Heap Pss（Proportional Set Size）内存明显增加。这种情况比较少见，是由于分配了大量小对象造成的内存碎片。
摘自：《移动App性能评测与优化》 — TMQ专项测试团队 编著
在豆瓣阅读书店查看：https://read.douban.com/ebook/25653260/
本作品由华章数媒授权豆瓣阅读全球范围内电子版制作与发行。
© 版权所有，侵权必究。
网友评论