17年刚接触移动端非功能测试，当时对移动端测试虽然不是很陌生，但更多的停留在概念层次，没有很好的去实践，入职第一件事情就是要做App的性能测试，当时通过了很长时间实践，逐渐总结出来一套移动端性能测试、现象分析、问题定位一套方法。我称之为“移动端性能测试四步法”。本文以京东金融某次性能专项测试为例，阐述移动端性能测试四步法的具体应用与实践。
移动端性能测试四步法，主要是通过四轮测试，解决发现并排除移动端性能问题的所在。
第一轮进行基本排查，主要检视和发现各种异常数据；
第二轮针对基本用例进行多次对比测试，进一步定位和发现风险和异常场景；
第三轮针对问题场景长时间多次测试，通过日志和抓包、内存堆栈等进行分析，进一步排查异常测试场景的问题所在；
第四轮部分重要功能对标竞品测试。
1）常规风险排查
在本轮测试主要涉及到基础业务中九个场景：未登录，划过引导页；登录、底部tab页点击、FL业务、LQ业务、QD业务、RW中心、ZQ业务、DD业务、BH业务和BQ业务等功能。
通过第一轮测试结果如下：
根据多次测试结果显示:
DD业务：在点击DD业务时，整机CPU和APP进程CPU较高，分别达到63% 和80%左右，其平均值分别为20%和40%
RW业务：点击 RW业务时，整机CPU和APP进程CPU分别达到61%和78%左右，其平均值分别为20%和40%
已知问题：通过前期优化，登录cpu占用有所下降，但依然在80%左右
通过多次测试平均取值福利中心、领券中心、签到功能在操作过程中内存占用较高，达到30M左右。
操作DD业务、RW业务手机端cpu占用比较高，存在风险。
操作FL业务、LQ业务、QD业务功能内存增加较多。
2） 业务比对测试与排查
通过第一轮测试，初步发现部分业务场景的风险；第二轮通过多用例重复执行，通过对比发现异常情况。测试结果如下：
CPU占用
内存占用
由内存占用图片很明显可以看到某个功能存在内存泄漏的风险，经过分析查看，发现该LQ业务存在内存泄漏。另外由CPU占用可以看到单单返和任务中心CPU占用依然偏高。
3） 异常定位排查
LQ业务内存排查
在第二轮测试过程中发现领券中心存在内存泄漏的风险。本次测试专门针对LQ业务进行多次反复测试（100次）。
如图所示，当执行到15次时，APP崩溃，内存占用直线下跌，内存恢复正常。
本次测试确定LQ业务存在内存泄漏问题。需要进一步进行排查崩溃原因。
BH业务和BQ业务
针对白条还款、取现、借钱功能进行反复验证测试发现，白条取现、白条借钱功能在操作过程中CPU和内存偏高，操作前后内存增幅达到35-50%，CPU最高增幅是平均CPU的6倍，但在操作后基本恢复到正常值。
BH业务问题排查
通过分析对比，BH业务内存和cpu占用均比其支付相关业务要高，为此对BH业务进一步分析排查。
为了方便排查对比，部分抓包和数据分析数据通过pc页面抓包。由以下抓包数据可以看到， bundle.js业务一次请求时间为1163ms，请求时间站到整个业务请求时间的95%以上，手机端数据流量是429KB,站到流量数据的95%以上。
第二次请求同一个页面（PC），发现bundle.js页面请求时间变短，请求流量1.1MB，说明数据缓存没有起作用。
通过对bundle.js页面代码分析，发现有7张图片占用比较大。
BQ业务问题排查
在测试时BQ业务内存一直较高，通过对抓包分析发现
BQ业务功能在操作时内存偏高，通过简单数据抓包不能定位和确定问题所在，但暴露出来一些问题。比如请求次数过多，需要进一步梳理业务，另外从代码规范上需要进一步加强。
4） 京东金融与支付宝对标测试
选取支付宝和京东金融部分基础公共业务进行对比测试（因业务敏感性，此处省略若干）。下图分别是支付宝和京东金融流量累计图
支付宝流量累计图
京东金融流量累计图
由流量累计图对比可知，相似功能京东金融流量消耗14M,支付宝流量消耗1M，京东金融流量消耗是支付宝的14倍。
（1）LQ业务存在
内存泄漏问题
，需要修改，通过和开发进一步排查，发现RN框架中的其他RN框架相关的功能都存在问题。初步
定位到RN框架问题
。
（2）DD业务、RW业务、BQ业务、BH业务等功能在操作时cpu和内存增幅偏高，虽然目前对APP功能使用没有影响，但打开速度慢会影响用户体验。需要优化。
（3）在和支付宝对标测试中，涉及8个测试场景，支付宝大部分场景是原生功能；而京东金融基本都是H5。所以在流量消耗上京东金融流量消耗是支付宝的14倍。需要产品及其相关人员重点关注。
（4）SS功能加载慢。通过分析竞品支付宝、招商银行网上生活、京东商城，发现SS业务入口基本和首页一起加载出来，京东金融扫一扫功能延迟约1.68s后加载出来（不同手机取平均值）
在本次测试过程中对对存在内存、cpu操作时占用过高问题持续分析，提出以下建议。
在测试分析中发现bundle.js在整个请求过程，耗时和流量消耗占用该业务的95%以上。建议优化
（1）在合并bundle.js时考虑去掉无用信息。在该文件中最占资源的7张图片是否有用？如果没用建议去掉。
（2）在bundle.js 中DataURL是用Base64的方式，将图片变成文本编码放入代码的方式 。建议优化Base64编码方式，对于较大图片改成使用二进制图片编码格式，减少数据流量。
（3）bundle.js数据缓存数据无效，通过抓包分析bundle.js返回304，说明使用缓存，但实际数据交互过程中没有缓存，通过多次抓包分析，每次返回数据包为手机端464kb、pc大概1.1M说明缓存没有起效果。缓存没有效果，其原因是Base64编码，每次页面刷新都需要重新加载这部分数据。
在BQ功能中，通过初步分析主要原因是请求次数过多。建议优化
（1）建议重新梳理业务，减少请求次数，减少无用信息；合并js、css等代码。
（2）Js脚本进行压缩，比如example.js。
（3）确定引入的js脚本是否都有必要，剔除没必要的js脚本引入。
（5）建立三方接入规范，形成初步代码准入机制和代码规范框架。
以上通过一次真实的移动端专项测试为例，说明移动端性能测试四步法的应用，在实际过程中业务可能更加复杂，需要根据实际情况灵活运用，但四步法的整体逻辑是具有一定的通用性，如在使用过程中出现任何问题，欢迎沟通交流。
文章来源：MiniStarClub北京，致力于提供最具价值的测试及测试管理领域原创文章。包括测试技术、测试方法、测试思想、测试管理等。
你点的每个“在看”，我都认真当成了喜欢
