App性能測試中的幾個重要概念總結(jié)

今天就來從我們軟件測試人員的角度，App驗收測試過程中需要關(guān)注到一些指標(biāo)項目：內(nèi)存占用、CPU 占用、流量耗用、電量耗用、啟動時間。下面針對每一個方面的一些重要知識點進行了整理。

一. 內(nèi)存

1. 內(nèi)存泄漏

說到內(nèi)存方面，最經(jīng)典的內(nèi)存問題當(dāng)數(shù)內(nèi)存泄漏。百度上對內(nèi)存泄漏的定義是這樣的：內(nèi)存泄漏（Memory Leak）是指程序中己動態(tài)分配的堆內(nèi)存由于某種原因程序未釋放或無法釋放，造成系統(tǒng)內(nèi)存的浪費，導(dǎo)致程序運行速度減慢甚至系統(tǒng)崩潰等嚴重后果。通俗點講，在大部分應(yīng)用中，會有一類功能是需要加載附加資源的，比如顯示從網(wǎng)絡(luò)下載的文本或圖片。這類功能往往需要在內(nèi)存中存放要使用的資源對象，退出該功能后，就需要將這些資源對象清空。如果忘了清理，或者是代碼原因造成的清理無效，就會形成內(nèi)存泄漏。

2. 垃圾回收

說到了內(nèi)存泄漏，又不得不提到垃圾回收，內(nèi)存中的垃圾，主要指的是內(nèi)存中已無效但又無法自動釋放的空間，除非是重啟系統(tǒng)不然永遠也不會還給操作系統(tǒng)。這樣以來，時間久了當(dāng)程序運行的時候就會產(chǎn)生很多垃圾，一方面浪費了不少內(nèi)存空間，另一方面如果同一個內(nèi)存地址被刪除兩次的話，程序就會不穩(wěn)定，甚至奔潰。

在 Java 程序運行過程中，一個垃圾回收器會不定時地被喚起檢查是否有不再被使用的對象，并釋放它們占用的內(nèi)存空間。但垃圾回收器的回收是隨機的，可能在程序的運行的過程中，一次也沒有啟動，也可能啟動很多次，它并不會因為程序一產(chǎn)生垃圾，就馬上被喚起而自動回收垃圾。所以垃圾回收也并不能完全避免內(nèi)存泄漏的問題。

另一方面，垃圾回收也會給系統(tǒng)資源帶來額外的負擔(dān)和時空開銷。它被啟動的幾率越小，帶來的負擔(dān)的幾率就越小。

3. 內(nèi)存指標(biāo)

內(nèi)存指標(biāo)有 VSS、RSS、PSS、USS，他們的含義分別是：

VSS：Virtual Set Size 虛擬耗用內(nèi)存（包含共享庫占用的內(nèi)存）

RSS：Resident Set Size 實際使用物理內(nèi)存（包含共享庫占用的內(nèi)存）

PSS：Proportional Set Size 實際使用的物理內(nèi)存（按比例分配共享庫占用的內(nèi)存）

USS：Unique Set Size 進程獨自占用的物理內(nèi)存（不包含共享庫占用的內(nèi)存）

一般來說內(nèi)存占用大小有如下規(guī)律：VSS >= RSS >= PSS >= USS，一般測試中關(guān)注的比較多的是 PSS 這個指標(biāo)。

二. CPU

1. 時間片

時間片即 CPU 分配給各個程序的時間，每個線程被分配一個時間段，稱作它的時間片，即該進程允許運行的時間，使各個程序從表面上看是同時進行的。

2. Jiffies

Jiffies的概念

HZ：Linux 核心每隔固定周期會發(fā)出 timer interrupt (IRQ 0)，HZ 是用來定義每一秒有幾次 timer interrupts。例如 HZ 為 1000，就代表每秒有 1000 次 timer interrupts。

Tick：HZ 的倒數(shù)，Tick = 1/HZ，即 timer interrupt 每發(fā)生一次中斷的時間。如 HZ 為 250 時，tick 為 4 毫秒（millisecond）。

而 Jiffies 為 Linux 核心變量，是一個 unsigned long 類型的變量，被用來記錄系統(tǒng)自開機以來，已經(jīng)過了多少 tick。每發(fā)生一次 timer interrupt，Jiffies 變數(shù)會被加 1。

3. CPU 使用率

在 Linux 系統(tǒng)下，CPU 利用率分為用戶態(tài)、系統(tǒng)態(tài)和空閑態(tài)，他們分別代表的含義為：用戶態(tài)表示 CPU 處于用戶態(tài)執(zhí)行的時間，系統(tǒng)態(tài)表示系統(tǒng)內(nèi)核執(zhí)行的時間，空閑態(tài)表示空閑系統(tǒng)進程執(zhí)行的時間。

而一個 App 的 CPU 使用率 = CPU 執(zhí)行非系統(tǒng)空閑進程時間 / CPU 總的執(zhí)行時間，也可以表示為 App 用戶態(tài) Jiffies + App 系統(tǒng)態(tài) Jiffies / 手機總 Jiffies。

4. CPU 過高會帶來的影響

可能會使整個手機無法響應(yīng)，整體性能降低，引起 ANR，導(dǎo)致手機更耗電，降低用戶體驗等。

三. 流量

1. 定義

我們的手機通過運營商的網(wǎng)絡(luò)訪問 Internet，運營商替我們的手機轉(zhuǎn)發(fā)數(shù)據(jù)報文，數(shù)據(jù)報文的總大?。ㄗ止?jié)數(shù)）即流量，數(shù)據(jù)報文是包含手機上下行的報文。

2 統(tǒng)計測試法

讀取 linux 流量統(tǒng)計文件

利用 Android 自身提供的 TCP 收發(fā)長度的統(tǒng)計功能，獲取 App 的 tcp_snd 和 tcp_rcv 的值，測試一段時間后再分別統(tǒng)計一次，用 tcp_snd

兩者的差值得到發(fā)送流量，用 tcp_rcv 兩者的差值得到接受流量。

利用 Android 流量統(tǒng)計 API

TrafficStats

Android 2.2 版本開始加入 android.net.TrafficStats 類來實現(xiàn)對流量統(tǒng)計的操作。

部分方法如下：

static long getMobileRxBytes() //獲取通過移動數(shù)據(jù)網(wǎng)絡(luò)收到的字節(jié)總數(shù)

static long getMobileTxBytes() //通過移動數(shù)據(jù)網(wǎng)發(fā)送的總字節(jié)數(shù)

static long getTotalRxBytes() //獲取設(shè)備總的接收字節(jié)數(shù)

static long getTotalTxBytes() //獲取設(shè)備總的發(fā)送字節(jié)數(shù)

static long getUidRxBytes(int uid) //獲取指定uid的接收字節(jié)數(shù)

static long getUidTxBytes(int uid) //獲取指定uid的發(fā)送字節(jié)數(shù)

NetworkStatsManager

Android 6.0 版本開始，為了打破了原本 TrafficStats 類的查詢限制，官方又提供了 NetworkStatsManager 類，可以獲取更精準(zhǔn)的網(wǎng)絡(luò)歷史數(shù)據(jù)，也不再是設(shè)備重啟以來的數(shù)據(jù)。部分方法如下：

NetworkStats.Bucket querySummaryForDevice(int networkType, String subscriberId, long startTime, long endTime) // 查詢指定網(wǎng)絡(luò)類型在某時間間隔內(nèi)的總的流量統(tǒng)計信息

NetworkStats queryDetailsForUid(int networkType, String subscriberId, long startTime, long endTime, int uid) // 查詢某uid在指定網(wǎng)絡(luò)類型和時間間隔內(nèi)的流量統(tǒng)計信息

NetworkStats queryDetails(int networkType, String subscriberId, long startTime, long endTime) // 查詢指定網(wǎng)絡(luò)類型在某時間間隔內(nèi)的詳細的流量統(tǒng)計信息（包括每個uid）

四. 電量

1.耗電場景

定位，尤其是調(diào)用 GPS 定位。

網(wǎng)絡(luò)傳輸，尤其是非 Wifi 環(huán)境。

屏幕亮度

CPU 頻率

內(nèi)存調(diào)度頻度

wake_locker 時間和次數(shù)

其他傳感器

優(yōu)化方法

CPU 時間片：當(dāng)應(yīng)用退到后臺運行時，盡量減少應(yīng)用的主動運行，當(dāng)檢測到 CPU 時間片消耗異常時，深入線程進行分析。

wake lock：前臺運行時不要注冊 wake lock。后臺運行時，在保證業(yè)務(wù)需要的前提下，應(yīng)盡量減少注冊 wake lock。

降低對系統(tǒng)的喚醒頻率， 使用 partial wake lock 代替 wake lock。

傳感器：合理設(shè)置 GPS 的使用時長和使用頻率。

云省電策略：考慮到用戶使用場景的多樣性，導(dǎo)致很難定位用戶異常耗電的根源，所以為了更深一層弄清楚這些問題，可以考慮定期上報灰度用戶手機電量數(shù)據(jù)的方式來分析問題。

五. 啟動時間

可使用命令 adb shell am start -W packagename/activity 查看 App 啟動耗時，查看了一下我們自己的 App Android 版本的啟動耗時如下：

注釋：

WaitTime：總的耗時，包括前一個應(yīng)用 Activity pause 的時間和新應(yīng)用啟動的時間

ThisTime：一連串啟動 Activity 的最后一個 Activity 的啟動耗時

TotalTime：新應(yīng)用啟動的耗時，包括新進程的啟動和 Activity 的啟動，但不包括前一個應(yīng)用 Activity pause 的耗時

最后，App性能問題會直接影響產(chǎn)品體驗：耗流量、掉電快、卡頓、崩潰等現(xiàn)象會給用戶造成不良的體驗和印象，不利于產(chǎn)品的活躍及用戶留存。許多經(jīng)驗豐富的程序員也會經(jīng)常忽視這些不起眼的性能問題，因此作為測試人員，在版本發(fā)布前及早關(guān)注并發(fā)現(xiàn)上述性能問題就顯得尤其重要。但真正做起App性能測試才發(fā)現(xiàn)這條路并不容易走，抓取內(nèi)存、CPU 等一些項目的指標(biāo)容易，但對一些數(shù)據(jù)的敏感度和處理方式都是要靠經(jīng)驗的慢慢積累。

推薦閱讀：

如何進行H5前端頁面測試？H5前端頁面需要注意的測試點

APP的UI測試點及接口測試點總結(jié)

Android客戶端性能測試常見指標(biāo)及關(guān)注點

測試iOS APP時需要注意什么？iOS APP需要關(guān)注的測試點

移動測試之H5頁面性能測試點總結(jié)

APP軟件常見的性能測試都包含了哪些方面？

移動端自動化測試工具都有哪些？