app性能测试
1 app性能測試
提到APP的性能測試這個概念比較籠統，因為APP的性能測試分為服務端的性能和手機端的性能測試
1.1 app服務端性能測試
app服務端的性能測試，利用jmeter等工具模擬并發，壓測服務器系統，服務端性能測試，一般可以通過接口來測，關注的指標主要包括以下幾個:
平均響應時間
錯誤率
吞吐量
CPU/內存占用率
網絡/硬盤的讀寫速度
1.2 app客戶端性能測試
app客戶端的性能測試，主要是指app運行操作過程當中，監測當前手機系統的一些性能指標，以此來確定app的性能是否會影響到用戶的體驗。app的性能指標主要包括以下幾個：
啟動速度
CPU占用率
內存占用率
電量消耗
流量消耗
流暢度
2 測試方案及工具選擇
2.1 perfdog
官網：https://perfdog.qq.com/
介紹：騰訊出品的移動全平臺iOS/Android性能測試、分析工具平臺。
特點
2.2 測試方案
2.2.1 啟動時間
手機APP的啟動時長是一個很容易被用戶感知的性能指標，啟動時長過長會讓用戶極不愿意繼續等待。因此啟動時長是一項比較靠前的性能指標。APP的啟時長分為兩種情況，一種是冷啟動時間，另一種是熱啟動。
冷啟動：應用序首次啟動，進程首次創建并加載資源的過程
熱啟動：指app沒有被后臺殺死，仍然在后臺運行，通常我們再次去打開這個app，這種啟動方式叫熱啟動
1）場景設計
冷啟動
場景設計：清除后臺所有應用，等待數秒 ，啟動軟件
熱啟動
場景設計：切換到桌面，等待數秒 ，重新切換回應用
2）測試方法
-
使用adb命令進行測試
-
冷啟動：應用進程首次啟動
- adb shell am start -W 包名/界面名
-
熱啟動：切換到主頁后再啟動應用
- adb shell input keyevent 3
- adb shell am start -W 包名/界面名
-
3）結果分析：
通過adb命令可獲取的時間如下：
ThisTime ：該界面 ( activity ) 啟動耗時（毫秒）
TotalTime ：應用自身啟動耗時 = ThisTime + 應用 application 等資源啟動時間（毫秒）
WaitTime ：系統啟動應用耗時 = TotalTime + 系統資源啟動時間（毫秒）
如何確定啟動時間是否符合標準？
根據用戶體驗
和以往版本進行對比
橫向對比，和同類產品一起測試，不超過同類產品的1倍
2.2.2 流暢度(FPS)
FPS是圖像領域中的定義，是指畫面每秒傳輸幀數，通俗來講就是指動畫或視頻的畫面數。FPS是測量用于保存、顯示動態視頻的信息數量。每秒鐘幀數愈多，所顯示的動作就會愈流暢。
FPS（1s內游戲畫面或者應用界面真實平均刷新次數，俗稱幀率/FPS）
- AVG(FPS)：平均幀率（一段時間內的平均FPS）
- Var(FPS)：幀率方差（一段時間內FPS方差）
- Drop(FPS)：降幀次數（平均每小時相鄰的個FPS點下降大于8幀的次數）
Jank（1s內卡頓次數）
- BigJank：1s內嚴重卡頓次數
- Jank(/10分鐘)：平均每十分鐘卡頓次數
- BigJank(/10分鐘)：平均每十分鐘嚴重卡頓次數
FTime（上下兩幀畫面顯示時間間隔，即認定為幀耗時）
- AVG(FTime)：平均幀耗時
- Delta(FTime)：增量耗時（平均每小時兩幀之間時間差>100ms的次數）
PerfDog-Stutter(卡頓率)
PerfDog Stutter 定義：測試過程中，卡頓時長的占比。即Stutter(卡頓率)=卡頓時長/總時長
1）場景設計
打開被測軟件的每一個頁面進行測試
2）測試方法
在app上進行操作，使用perfdog工具采集數據
3）結果分析：
游戲方面
? 游戲流暢度是最影響用戶體驗的，所以需要重點關注FPS、Jank及卡頓率。
APP方面
APP也需要關注FPS、Jank及卡頓率。只是需要區分使用場景，具體的數據對比可以和以往版本進行對比，也可和競品橫向對比。
? 1) 靜態頁面窗
? 只需關注FPS，理論FPS應該為0，否則，說明有冗余刷新，容易引起手機發熱及耗電。
? 2) 有滾動動畫頁面窗口
? 只需關注FPS，FPS處于合適值即可，無需高頻刷新。
? 3) 快速滑動頁面窗口
? 需要關注FPS、Jank及卡頓率。一般滑動狀態下，幀率越高越好，Jank越小越好。
? 4) 播放視頻頁面窗口
? 需要關注FPS、Jank及卡頓率，視頻卡頓直接影響用戶。視頻一般幀率18-24幀，Jank=0。比如微信播放視頻、視頻播放器等。
2.2.3 CPU利用率
某些場景下我們去使用App，可能會碰到手機會出現發熱發燙的現象。這是因為CPU使用率過高、CPU過于繁忙，會使得整個系統無法響應用戶，整體性能降低，用戶體驗變得相當差，主要關注的是cpu的占用率
-
CPU Usage：傳統cpu利用率，也叫未規范化cpu利用率
- 計算方法：當前時刻cpu頻率下，CPU Usage = CPU執行時間/CPU總時間，一般adb等獲取的都是未規范化的cpu利用率
-
CPU Usage(Normalized)：規范化cpu利用率
-
由于移動設備CPU頻率時刻變化，用傳統CPU利用率計算方法，假定在低頻率時刻計算出CPU利用率=30%，和在CPU高頻時刻計算出CPU利用率=30%。同樣都是30%但性能消耗是完全不樣的，明顯高頻消耗更高。傳統CPU利用率已無法真實反映性能消耗。
所以我們需要一種規范化(可量化)的統計方式。將頻率因素考慮進去。
CPU Usage(Normalized)= (CPU執行時間/CPU總時間) * (當前時刻所有CPU頻率之和/所有CPU頻率最大值之和)。
-
1）CPU 測試場景設計
-
測試點：
-
空閑時間(切換至后臺)的消耗，基本沒大應用使用cpu
-
在運行一些應用的情況下，cpu已占50%的情況下，觀察應用程序占用cpu的情況
-
在高負荷的情況下看CPU的表現（cpu占用應是在80%以上）
-
具體場景：
- 應用空閑狀態運行監測CPU占用率，空閑狀態：應用按Home鍵退到后臺，不再占用系統的狀態（通常是滅屏半分鐘后），CPU占用率=0%
- 應用中等規格運行監測CPU占用率，中等規格：模擬用戶最常見的使用場景，CPU占用率≤30%
- 應用滿規格長時間正常運行監測CPU占用率，CPU占用率≤30%
- 應用正常運行期間監測CPU占用率峰值，應用正常運行：打開應用進行基本操作，CPU占用率≤50%
2）測試方法
使用perfdog采集不同場景數據
結果分析：
- 和自身app的上個版本對比
- 和競品對比
- 自身app各個界面對比
2.2.4 內存
在Android系統中，每個APP進程除了同其他進程共享內存(shared dirty)外，還獨用私有內存(private dirty)，通常我們使用PSS(私有內存+比例分配共享內存)來衡量一個APP的內存開銷
app內存有以下幾個：
VSS- Virtual Set Size 虛擬耗用內存（包含共享庫占用的內存）
RSS- Resident Set Size 實際使用物理內存（包含共享庫占用的內存）
PSS- Proportional Set Size 實際使用的物理內存（比例分配共享庫占用的內存）
USS- Unique Set Size 進程獨自占用的物理內存（不包含共享庫占用的內存）
一般來說內存占用大小有如下規律：VSS >= RSS >= PSS >= USS。
而perfdog的Memory也就是Android PSS Memory，也是我們通常用作代表內存的數據，是實際使用內存的物理內存大小
1）內存測試場景設計
空閑狀態：切換至后臺或者啟動后不做任何操作，消耗內存最少
中強度狀態：時間偏長的操作應用
強度狀態：高強度使用應用，可以跑monkey來測試（通常用來測內存泄漏）
內存泄漏：指應用里的內存一直沒有釋放，內存一直增加 ,系統內存一直減少
2) 測試方法
使用perfdog采集不同場景數據
3) 結果分析：
退出某個頁面后，內存是否有回落
進行某個操作后，內存是否增長過快
舊版本和新版本比較
新版本和競品比較
2.2.5 流量
目前的網絡類型包含2G\3G\4G\wifi，其中還有不同運營商的區分，我們在APP的使用中經常遇到大資源，重復請求，調用響應慢，調用失敗等各種情況。在不同的網絡類型之下，我們不僅要控制流量使用，還需要加快請求的響應。
1）流量測試場景設計
2）測試方法
使用 perfdog 測試工具采集流量數據
注意！ perfdog流量測試僅支持wifi連接狀態
3）測試結果與分析
舊版本和新版本比較
新版本和競品比較
| 打開登錄頁面，輸入用戶名與密碼進行登錄，點擊簽到并簽到成功 | xxx KB | 是/否 |
| 打開商品搜索頁，搜索xxx，直到第一頁搜索的內容全部展示出來 | xxx MB | 是/否 |
| … | … | … |
2.2.6 電量
對于PC來說，移動設備的電池電量是非常有限的，保持持久的續航能力尤為重要。我們必須要慎重檢查APP的電量使用，以免導致用戶手機耗電發熱，帶來不良體驗
1）耗電量測試場景設計
- 場景設計：打開xx導航軟件，開啟GPS定位，保持在導航頁面中運行十分鐘后，關閉GPS定位
- 原因：開啟GPS定位會使用到手機的傳感器，所以需要測試開啟該功能后的電量消耗
- 場景設計：手機亮度設置為100%的亮度，打開xx軟件運行十分鐘后退出軟件，關閉后臺
- 原因：測試不同屏幕亮度時軟件的耗電量
- 場景設計：打開xx視頻軟件，觀看視頻十分鐘后退出軟件，關閉后臺
- 原因：使用網絡時會調用到手機的信號接收、發送模塊，這個情況下如果程序沒有進行合理的調用，會導致這些模塊一直在被使用，導致電量消耗大
- 場景設計：打開xx炒股軟件的股票走勢頁面，停留十分鐘后退出軟件，關閉后臺；
- 原因：在需要動態加載圖表的頁面時會使用到CPU進行運算繪制，如果程序中出現冗余的循環邏輯時會使CPU進行不必要的負載，導致耗電量劇增
- 場景設計：打開xx電商軟件商品瀏覽頁，向下瀏覽頁面五分鐘后退出軟件，關閉后臺
- 原因：該場景需要大量加載圖像，頻繁調用運行內存，如果每次都需要重新加載的話會大量消耗運行內存，導致電量消耗大，所以需要測試電量消耗
- 場景設計：打開xx軟件，連續使用一個小時
- 原因：長時間連續使用過程中電量消耗應該處于一個較為平緩正常的耗電，而不應該在使用一段時間以后出現耗電量劇增的情況；同時軟件在后臺運行(不進行聯網操作、GPS定位等功能)時，電量消耗應該極低
2）測試方法
使用 perfdog 采集手機耗電量
測的是整機，不是單個APP，測試時要盡量減少系統本身和其他app的干擾，同時無法得知app具體哪方面的耗電量高。
注意！ perfdog電量測試僅支持wifi連接狀態
3）結果分析
| 使用GPS功能 | 導航頁面 | 10min | xxx% |
| 置于后臺使用GPS功能 | 導航頁面 | 10min | xxx% |
| … | … | … | … |
根據測試后拿取的結果，與同類產品進行對比，或者與本產品的其他頁面進行對比，分析是否有異常耗電的情況。
3 參考資料
3.1 VSS、RSS、PSS、USS內存
VSS：Virtual Set Size，虛擬耗用內存。它是一個進程能訪問的所有內存空間地址的大小。這個大小包含了
一些沒有駐留在RAM中的內存，就像mallocs已經被分配，但還沒有寫入。VSS很少用來測量程序的實際使
用內存。
RSS：Resident Set Size，實際使用物理內存。RSS是一個進程在RAM中實際持有的內存大小。RSS可能會
產生誤導，因為它包含了所有該進程使用的共享庫所占用的內存，一個被加載到內存中的共享庫可能有很
多進程會使用它。RSS不是單個進程使用內存量的精確表示。
PSS：Proportional Set Size，實際使用的物理內存，它與RSS不同，它會按比例分配共享庫所占用的內存。
例如，如果有三個進程共享一個占30頁內存控件的共享庫，每個進程在計算PSS的時候，只會計算10頁。
PSS是一個非常有用的數值，如果系統中所有的進程的PSS相加，所得和即為系統占用內存的總和。當一個
進程被殺死后，它所占用的共享庫內存將會被其他仍然使用該共享庫的進程所分擔。在這種方式下，PSS
也會帶來誤導，因為當一個進程被殺后，PSS并不代表系統回收的內存大小。
USS：Unique Set Size，進程獨自占用的物理內存。這部分內存完全是該進程獨享的。USS是一個非常有用
的數值，因為它表明了運行一個特定進程所需的真正內存成本。當一個進程被殺死，USS就是所有系統回
收的內存。USS是用來檢查進程中是否有內存泄露的最好選擇。
[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-YNNCJp1M-1621393708995)(app性能測試.assets/image-20210515165014128.png)][外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-Ye8YlW89-1621393708999)(app性能測試.assets/image-20210515165025343.png)]
共享庫，每個進程在計算PSS的時候，只會計算10頁。
PSS是一個非常有用的數值，如果系統中所有的進程的PSS相加，所得和即為系統占用內存的總和。當一個
進程被殺死后，它所占用的共享庫內存將會被其他仍然使用該共享庫的進程所分擔。在這種方式下，PSS
也會帶來誤導，因為當一個進程被殺后，PSS并不代表系統回收的內存大小。
USS：Unique Set Size，進程獨自占用的物理內存。這部分內存完全是該進程獨享的。USS是一個非常有用
的數值，因為它表明了運行一個特定進程所需的真正內存成本。當一個進程被殺死，USS就是所有系統回
收的內存。USS是用來檢查進程中是否有內存泄露的最好選擇。
總結
