Android 非功能性測試（性能測試）

非功能性測試是針對非功能性需求來說的。所謂非功能需求，是指軟件產品爲滿足用戶業務需求而必須具有且除功能需求以外的特性

一、交互類性能

1.響應時間

       啓動時間和響應時間是APP帶給用戶最直觀的性能體驗。因此，無論何種類型的APP，我們都不能忽視響應時間的測試，在互聯網上對於用戶響應時間，有一個普遍的標準(有網絡交互時)，2/5/10秒原則：

- 2秒 “非常有吸引力”的用戶體驗

- 5秒 “比較不錯”的用戶體驗

- 10秒 “糟糕”的用戶體驗

1.1    用例設計

      我們通常所說的App卡、慢通常就是由於啓動時間或者頁面響應時間過長導致的。我們從這兩個方面，結合實際的用戶場景，給出了幾種常用的測試場景。

測試場景	說明
冷啓動時間	從App啓動到出現第一個可操作的頁面的時間間隔
熱啓動時間	同上
App啓動到首頁加載出來的時間	從App啓動到首頁完全加載出來的時間間隔
無網絡請求的頁面響應時間	一般指從發起跳轉，到頁面完全加載出來的時間間隔
有網絡請求的頁面響應時間	同上

注：冷啓動 – 當應用啓動時，後臺沒有該應用進程，這時系統會重新創建一個新的進程分配給該應用

       熱啓動 – 當應用已經被打開，但是被按下返回鍵、Home鍵等按鍵時回到桌面或者是其他程序的時候，再重新打開該應用

1.2 測試方法

實際性能測試中是嚴格錄像計時的，按下到首幀響應時間。

• ADB命令

說明：此命令適用應用冷啓動時，只需關注TotalTime（單位：ms）

-         ThisTime 表示一連串啓動Activity的最後一個 Activity 的啓動耗時，一般和TotalTime時間一樣，除非在應用啓動時開了一個透明的Activity預先處理一些事再顯示出主Activity，這樣將比TotalTime小

-         TotalTime應用的啓動時間，包括創建進程+Application初始化+Activity初始化到界面顯示

-         WaitTime 一般比TotalTime大點，包括系統影響的耗時

• 屏幕錄製

1）  安裝被測應用到測試機，保證手機網絡暢通；

2）  通過高速相機對準手機屏幕進行錄像，該步驟也可使用adb命令錄製（精確度不如高速相機拍攝）；

3）  用手點擊APP，待用戶期待界面完全展示後，停止錄像；

4）  通過視頻解幀工具打開錄好的視頻，分別找出用戶點擊屏幕的時間點和完全展示的時間點，兩者的差值就是APP響應時間。

注：此方法適用任何場景，但測試較爲繁瑣，建議手機無USB連接權限或其他測試條件不滿足時使用

• 腳本判斷

1）在發送touch事件後記錄起始時間；

2）當mFocusedActicity的數據中有指定activity，記錄結束時間；

3）兩者做差就是所需時間（單位：ms）。

注：該段腳本建議自行理解實踐，切勿複製粘貼

1.3 判斷依據

1）  冷啓動響應時間不超過2s；

2）  安裝完成首次啓動時間不超過5s；

3）  競品數據對比。

2.流暢度

       流暢度測試簡單來說就是Android頁面繪製。Android系統每秒60HZ，也就是大約每16ms刷新一次界面。但是我們在使用過程中經常會看到頁面有卡頓（丟幀）的現象，也就是說可能此時兩個頁面繪製的時間差超過0.1s（人眼視覺殘留0.1s）

2.1 用例設計

測試項	測試場景	說明
過渡繪製	1.     新增列表頁 2.     舊列表有大的改動 3.     當前加載頁資源較多 4.     …	頁面不能有超過70%的過渡繪製
幀率		平均FPS>=30，最小FPS>=24

 

2.2 測試方法

• 過度繪製

1）進入設置，開發者模式-調試GPU過度繪製；

2）打開待測應用，執行用例後查看頁面顯示

• 流暢度

1）進入設置，開發者模式-GPU呈現模式分析-在屏幕上顯示爲條形圖；

2）打開待測應用，執行用例後查看頁面顯示。

 

• ADB命令

1）  adb shell dumpsys gfxinfo com.xdja.actoma > D:\fps.txt

2）  獲取到如下數據，複製到Excel中繪製成堆積柱形圖

3）  表格：

4）  Draw + Prepare+Process + Execute = 完整顯示一幀 ，這個時間要小於16ms才能保存每秒60幀。

3.弱網測試

       用戶在各種場景下都會使用APP，我們需要針對不同場景的弱網環境下，驗證出現丟包、時延軟件的處理機制，極大提升產品印象和用戶體驗，避免因用戶體驗不好造成用戶的流失。

3.1 用例設計

測試場景	測試用例	說明
丟包	丟包率：5%、10%	一個或多個數據數據包（packet）的數據無法透過網上到達目的地
時延	延時：200ms、500ms	信息從發送到接收經過的延遲時間
抖動	抖動延遲：500ms、800ms	指信息從發送到接收經過的最大延遲與最小延遲的時間差
亂序	亂序比例：5%、10%	打亂數據包發送的順序

 

3.2 測試方法

1）下載Network Emulator for Windows Toolkit；

2）打開軟件，創建一個過濾器，可以在菜單中點擊configuration->new filter，也可以點擊快捷按鈕進行創建；

3）彈出的界面中，點擊add按鈕後，點擊close按鈕；

4）接着創建一個新的連接，同樣可以在菜單中點擊configuration->new link，也可以點擊快捷按鈕進行創建；

5）連接圖標處點擊右鍵或雙擊連接圖標；

6）接着就可設置上行和下行的丟包及延時等網絡數據，UpStream Property的設置窗口爲，其中Loss爲設置丟包，Error爲設置錯包，Latency爲設置網絡延遲，BW&Queue爲設置帶寬，BG Traffic爲設置邊界網關流量，Disconnection爲設置斷開連接數；

7）設置完成後點擊應用按鈕後點擊確定按鈕，彈出Downstream Property設置窗口直接點擊確認按鈕，完成後點擊start按鈕。

3.3 判斷依據

合理設置弱網環境下：

1）軟件不報錯，正常運行；

2）軟件超時響應處理；

3）傳輸中斷錯誤處理。

二、資源類性能

1.CPU

Android性能指標cpu主要關注兩點：

1）   cpu總體使用率

2）   應用程序CPU佔用率

1.1    用例設計

測試場景	說明
空閒狀態下的應用CPU消耗情況	被測應用在系統資源非常空閒的情況下的佔用率，比如只開一個被測應用；
中等規格狀態下的應用CPU消耗情況	後臺已經有幾個應用在運行已經並且消耗了系統的一些資源的情況下
滿規格狀態下的應用CPU消耗情況	從App啓動到首頁完全加載出來的時間間隔

 

1.2 測試方法

• 1.2.1 Android Studio直接查看

注:CPU運行狀態圖像化，但是無具體數值參考，可在測試報告中清晰表現，根據項目選擇。

• 1.2.3 GT/iTest工具

1）選擇待測應用+測試內容

 

2）  選擇需要保存的數據

3）  查看動態圖

4）  保存數據查看

1.3 判斷依據

1）   前臺進程不超過95%,後臺進程不超過5%, 但是在系統沒有前臺進程時，後臺進程可以超過5%；

2）   應用不能持續佔用CPU過高，如段時間內過高需要研發給出解釋。

2.內存

2.1 用例設計

測試場景	說明
內存使用率	應用佔用系統的內存佔比，一般僅測試應用啓動時的內存使用率
內存抖動	使用過程中頻繁申請釋放內存，測試用例根據業務場景設計，例如：發送羣聊消息、上傳下載文件等
內存泄漏	內存無法正常釋放，測試用例根據業務場景設計，例如：滑動查看圖片、滑動查看文件列表、下載文件、上傳文件、新建文件夾等

 

2.2 測試方法

2.2.1 內存佔用率（工具:GT/iTest）

注：僅支持Android6.0以下的安卓版本

1） 選擇被測應用

2） 查看內存佔用曲線圖

• 2.2.2 內存抖動（工具：AndroidStudio）

注：內存抖動是常見內存問題，必測項，需截圖體現在報告。

1） 測試機安裝待測應用，連接到AndroidStudio；

2） 操作應用使用場景查看內存抖動情況；

• 2.2.3 內存泄漏

注：內存泄漏爲必測項，需保存每一項內存數據表現，爲開發提供強有力的數據支持。

1） 測試機安裝待測應用，連接到AndroidStudio

2） 在AndroidStudio選擇DDMS工具

3） 選擇被測應用，並操作用例場景後GC，記錄Allocated、Data值

2.3 判斷依據

• 2.3.1 內存抖動判斷

如類似下圖，頻繁申請釋放內存，即爲不通過：

• 2.3.2 內存泄漏判斷

標題2.2.3中Data值一直增長，GC後無下降行爲即爲不通過

3.流量

APP的網絡流量消耗對於用戶來說是較爲敏感的，因爲有可能會和錢掛鉤。若APP開發時在這方面沒有控制好，很有可能會給用戶帶來不好的體驗

3.1 用例設計

測試場景	說明
IM聊天文字/表情/圖片	頻繁使用場景的流量測試
文件傳輸	傳輸過程中的流量消耗
後臺靜置待機	8小時後臺待機流量消耗
Xpush相關業務場景	-
應用首次啓動流量

 

3.2 測試方法（測試工具：GT/iTest）

1） 測試機安裝GT、待測應用

2） 打開GT選擇對應應用，後臺

3） 操作對應測試場景後查看GT統計

3.3 判斷依據

1） 流量消耗不能與發送內容的大小相差太多。如1M文件傳送消耗1.1M流量即爲通過，消耗2M流量即爲不通過

2） 8小時後臺流量待機不能超過1M流量

4.功耗

4.1 用例設計

測試場景	說明
安裝目標APK前後臺待機	前後臺待機包括4G、3G、WIFI、無網絡情況下測試
常見場景待機	執行常見場景後，功耗可恢復到待機狀態
GPS耗電待機	網絡正常連接情況下應用有GPS業務

 

1.2    測試方法

• 1.2.1 硬件測試

注：推薦使用該方法測試功耗，如無法達到測試條件請參考方法3

1）  測試機拆除電源後連接穩壓電源並串聯萬用表；

2）  按照萬用表錶盤操作讀取時刻電流mA；

3）  測試結束後保存平均電流mA。

• 1.2.2 軟件測試（測試工具：Power Tutor）

1）   打開PowerTutor軟件，選擇待測應用

2）   操作測試場景後，30分鐘後查看平均功率並換算爲mA

• 1.2.3 adb測試

1）測試樣機恢復出廠設置，安裝測試應用，保持電量在開測時是100%；

2）測試機連接電腦，重置電池信息；

adb shell dumpsys batterystats –reset

3）測試結束後執行，保存電量信息；

adb shell dumpsys batterystats > C:\Users\notordinary\Desktop\batterystats.txt

4）   從batterystats.txt篩選所需信息，搜索關鍵字“Estimated Power Use”

 

4）   Computed drain即是段時間內消耗功耗mAh，如上圖功耗值爲：

功耗值 = 6.58mAh/測試時長

理解：上圖數據測試時長爲30min，一般功耗值表現爲mA，所以需要有所換算。那麼如何換算mAh呢？

首先，我們需要理解什麼是☛mAh，mAh（毫[安時]）是電量單位，功耗測試需要的是電流單位mA，1Ah=1000mAh，則有如下換算：

➺放電0.5小時，消耗6.58mAh耗電量，一小時消耗約13.16mAh

➺也就是說13.16的電量，如果平均電流是13.16mA話，可供該設備使用1個小時

結論：理解之後那麼就知道，mA是電流的單位，表明電流的大小。 mAh是毫安時，電量的單位，常用來表明電池的容量，意即以多大的電流放電，能夠持續提供多長時間的電流。是不能相互換算，所以使用此方法的小夥伴就直接用mAh做對比吧

 

1.3    判斷依據

1）  安裝被測應用後，系統總耗電平均電流無明顯增加；

2）  被測APP不能有不合理的常駐服務，造成耗電持續偏高；

3）  ACE待機滅屏耗電6mA – 12mA；

4）  ACE待機亮屏耗電180 – 230mA。