17年剛接觸移動端非功能測試，當時對移動端測試雖然不是很陌生，但更多的停留在概念層次，沒有很好的去實踐，入職第一件事情就是要做App的性能測試，當時通過了很長時間實踐，逐漸總結出來一套移動端性能測試方法。我稱之爲“移動端性能測試四步法”。
1.移動端性能四步測試法
移動端性能測試四步法，主要是通過四輪測試，解決發現並排除移動端性能問題的所在。
第一輪進行基本排查，主要檢視和發現各種異常數據；
第二輪針對基本用例進行多次對比測試，進一步定位和發現風險和異常場景；
第三輪針對問題場景長時間多次測試，通過日誌和抓包、內存堆棧等進行分析，進一步排查異常測試場景的問題所在；
第四輪部分重要功能對標競品測試。
2. 測試實驗過程分析
在本輪測試主要涉及到基礎業務中九個場景：未登錄，劃過引導頁；登錄、底部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業務功能內存增加較多。
通過第一輪測試，初步發現部分業務場景的風險；第二輪通過多用例重複執行，通過對比發現異常情況。測試結果如下：
由內存佔用圖片很明顯可以看到某個功能存在內存泄漏的風險，經過分析查看，發現該LQ業務存在內存泄漏。另外由CPU佔用可以看到單單返和任務中心CPU佔用依然偏高。
在第二輪測試過程中發現領券中心存在內存泄漏的風險。本次測試專門針對LQ業務進行多次反覆測試（100次）。
如圖所示，當執行到15次時，APP崩潰，內存佔用直線下跌，內存恢復正常。
本次測試確定LQ業務存在內存泄漏問題。需要進一步進行排查崩潰原因。
針對白條還款、取現、借錢功能進行反覆驗證測試發現，白條取現、白條借錢功能在操作過程中CPU和內存偏高，操作前後內存增幅達到35-50%，CPU最高增幅是平均CPU的6倍，但在操作後基本恢復到正常值。
2.3.3 BH業務問題排查
通過分析對比，BH業務內存和cpu佔用均比其支付相關業務要高，爲此對BH業務進一步分析排查。
爲了方便排查對比，部分抓包和數據分析數據通過pc頁面抓包。由以下抓包數據可以看到， bundle.js業務一次請求時間爲1163ms，請求時間站到整個業務請求時間的95%以上，手機端數據流量是429KB,站到流量數據的95%以上。
第二次請求同一個頁面（PC），發現bundle.js頁面請求時間變短，請求流量1.1MB，說明數據緩存沒有起作用。
通過對bundle.js頁面代碼分析，發現有7張圖片佔用比較大。
2.3.4 BQ業務問題排查
在測試時BQ業務內存一直較高，通過對抓包分析發現
BQ業務大概有25次請求，另外發現有部分js代碼沒有壓縮，比如example.js等，還有部分host地址不一樣，但內容一樣的js比如wl.dev.js。另外有幾個log.png圖片請求。
BQ業務功能在操作時內存偏高，通過簡單數據抓包不能定位和確定問題所在，但暴露出來一些問題。比如請求次數過多，需要進一步梳理業務，另外從代碼規範上需要進一步加強。
下圖分別是支付寶和京東金融流量累計圖
選取支付寶和京東金融部分基礎公共業務進行對比測試（因業務敏感性，此處省略若干）。
由流量累計圖對比可知，相似功能京東金融流量消耗14M,支付寶流量消耗1M，京東金融流量消耗是支付寶的14倍。
3 測試結果分析
從目前的測試來看，主要有以下問題及風險。
（1）LQ業務存在內存泄漏問題，需要修改，通過和開發進一步排查，發現RN框架中的其他RN框架相關的功能都存在問題。初步定位到RN框架問題。
（2）DD業務、RW業務、BQ業務、BH業務等功能在操作時cpu和內存增幅偏高，雖然目前對APP功能使用沒有影響，但打開速度慢會影響用戶體驗。需要優化。
（3）在和支付寶對標測試中，涉及8個測試場景，支付寶大部分場景是原生功能；而京東金融基本都是H5。所以在流量消耗上京東金融流量消耗是支付寶的14倍。需要產品及其相關人員重點關注。
（4）SS功能加載慢。通過分析競品支付寶、招商銀行網上生活、京東商城，發現SS業務入口基本和首頁一起加載出來，京東金融掃一掃功能延遲約1.68s後加載出來（不同手機取平均值）
4 優化建議
在本次測試過程中對對存在內存、cpu操作是佔用過高問題持續分析，提出以下建議。
BH功能：
在測試分析中發現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功能：
在BQ功能中，通過初步分析主要原因是請求次數過多。建議優化
（1）建議重新梳理業務，減少請求次數，減少無用信息；合併js、css等代碼。
（2）Js腳本進行壓縮，比如example.js。
（3）確定引入的js腳本是否都有必要，剔除沒必要的js腳本引入。
（4）確定應答的json是否需要壓縮處理。
（5）建立三方接入規範，形成初步代碼准入機制和代碼規範框架。