非功能性測試是針對非功能性需求來說的。所謂非功能需求，是指軟件產品爲滿足用戶業務需求而必須具有且除功能需求以外的特性
一、交互類性能
1.響應時間
互聯網上對於用戶響應時間，有一個普遍的標準，2/5/10秒原則。
- 2秒 “非常有吸引力”的用戶體驗
- 5秒 “比較不錯”的用戶體驗
- 10秒 “糟糕”的用戶體驗
1.1 用例設計
我們通常所說的App卡、慢通常就是由於啓動時間或者頁面響應時間過長導致的。我們從這兩個方面，結合實際的用戶場景，給出了幾種常用的測試場景。
測試場景 | 說明 |
App首次啓動時間 | 從App啓動到出現第一個可操作的頁面的時間間隔 |
App非首次啓動的時間 | 同上 |
App啓動到首頁加載出來的時間 | 從App啓動到首頁完全加載出來的時間間隔 |
無網絡請求的頁面響應時間 | 一般指從發起跳轉，到頁面完全加載出來的時間間隔 |
有網絡請求的頁面響應時間 | 同上 |
1.2 測試方法
實際性能測試中是嚴格錄像計時的，按下到首幀響應時間。
ADB命令
說明：此命令適用應用冷啓動時，只需關注TotalTime（單位：ms）
- ThisTime 表示一連串啓動Activity的最後一個 Activity 的啓動耗時，一般和TotalTime時間一樣，除非在應用啓動時開了一個透明的Activity預先處理一些事再顯示出主Activity，這樣將比TotalTime小
- TotalTime應用的啓動時間，包括創建進程+Application初始化+Activity初始化到界面顯示
- WaitTime 一般比TotalTime大點，包括系統影響的耗時
屏幕錄製
1） 安裝被測應用到測試機，保證手機網絡暢通
2） 通過相機對準手機屏幕進行錄像
3） 用手點擊APP，待用戶期待界面完全展示後，停止錄像
4） 通過VirtualDub（或其他視頻解幀）工具打開錄好的視頻，分別找出用戶點擊屏幕的時間點和完全展示的時間點，兩者的差值就是APP響應時間
說明：此方法適用任何場景，但測試較爲繁瑣，建議手機無USB連接權限或其他測試條件不滿足時使用
腳本判斷
1）在發送touch事件後記錄起始時間
2）當mFocusedActicity的數據中有指定activity，記錄結束時間
3）兩者做差就是所需時間（單位：ms）。
說明：適用任意場景，已添加在ATT工具中，自動化用例可隨時調用
1.3 判斷依據
1） 冷啓動響應時間不超過2s
2） 安裝完成首次啓動時間不超過5s
3） 其他頁面響應時間不超過5s
2.流暢度
流暢度測試簡單來說就是Android頁面繪製。Android系統每秒60HZ，也就是大約每16ms刷新一次界面。但是我們在使用過程中經常會看到頁面有卡頓（丟幀）的現象，也就是說可能此時兩個頁面繪製的時間差超過0.1s（人眼視覺殘留0.1s）
2.1 用例設計
測試項 | 測試場景 | 說明 |
過渡繪製 | 1. 新增列表頁 2. 舊列表有大的改動 3. 當前加載頁資源較多 4. … | 頁面不能有超過70%的過渡繪製 |
幀率 | 平均FPS>=30，最小FPS>=24 |
2.2 測試方法
系統自帶 – 開發者模式
路徑：設置-開發者模式-GPU呈現模式分析-在屏幕上顯示爲條形圖
判斷依據：只要下方的曲線不超過綠線（16ms的閾值），都可以視之爲流暢
ADB命令
1） adb shell dumpsys gfxinfo com.xdja.actoma > D:\fps.txt
2） 獲取到如下數據，複製到Excel中繪製成堆積柱形圖
3） 表格：
4） Draw + Prepare+Process + Execute = 完整顯示一幀 ，這個時間要小於16ms才能保存每秒60幀。
二、資源類性能
1.CPU
Android性能指標cpu主要關注兩點：
1） cpu總體使用率
2） 應用程序CPU佔用率
1.1 用例設計
測試場景 | 說明 |
空閒狀態下的應用CPU消耗情況 | 被測應用在系統資源非常空閒的情況下的佔用率，比如只開一個被測應用； |
中等規格狀態下的應用CPU消耗情況 | 後臺已經有幾個應用在運行已經並且消耗了系統的一些資源的情況下 |
滿規格狀態下的應用CPU消耗情況 | 從App啓動到首頁完全加載出來的時間間隔 |
1.2 測試方法
1.2.1 Android Studio直接查看
1.2.3 GT/iTest工具
1）選擇待測應用+測試內容
1） 選擇需要保存的數據
2） 查看動態圖
3） 保存數據查看
1.3 判斷依據
1） 前臺進程不超過95%,後臺進程不超過5%, 但是在系統沒有前臺進程時，後臺進程可以超過5%
2） 應用不能持續佔用CPU過高，如段時間內過高需要研發給出解釋
2.內存
2.1 用例設計
測試場景 | 說明 |
內存使用率 | 應用佔用系統的內存佔比 |
內存抖動 | 使用過程中頻繁申請釋放內存 |
內存泄漏 | 內存無法正常釋放 |
2.2 測試方法
2.2.1 內存佔用率（工具:GT/iTest）
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 硬件測試
1） 測試機拆除電源後連接穩壓電源並串聯萬用表
2） 按照萬用表錶盤操作讀取時刻電流mA
3） 測試結束後保存平均電流mA
1.2.2 軟件測試（測試工具：Power Tutor）
1） 打開PowerTutor軟件，選擇待測應用
2） 操作測試場景後，30分鐘後查看平均功率並換算爲mA
1.2.3 adb測試
1） 重置電池信息
adb shell dumpsys batterystats –reset
2） 測試結束後執行，保存電量信息
adb shell dumpsys batterystats > C:\Users\notordinary\Desktop\batterystats.txt
3） 從batterystats.txt篩選所需信息，搜索關鍵字“Estimated Power Use”
4） Computed drain即是段時間內消耗功耗mAh，如上圖功耗值爲：
功耗值 = 6.58mAh/測試時長
1.3 判斷依據
1） 安裝被測應用後，系統總耗電平均電流無明顯增加
2） 被測APP不能有不合理的常駐服務，造成耗電持續偏高
3） ACE待機滅屏耗電6mA – 12mA
4） ACE待機亮屏耗電180 – 230mA