作者：TMQ melodyliu

轉(zhuǎn)載自 ：https://testerhome.com/topics/5546

APP要做性能測試，什么樣的數(shù)據(jù)能反應(yīng)應(yīng)用的性能情況，如何評估應(yīng)用的性能狀態(tài)？ 不知道該如何入手？一起來分析下如何給APP做性能測試。

性能測試三要素：性能指標(biāo)、測試場景、測試工具。

首先要思考選哪些指標(biāo)來評估性能：內(nèi)存、cpu、電量還是什么？接著，選擇你需要測試的場景，測試場景描述了你需要在何種場景下取性能數(shù)據(jù)，要測試APP何種功能等等。最后，根據(jù)你的指標(biāo)和場景選擇適合你的測試工具。

下面就從這三方面來具體分析。

性能指標(biāo)

常見的性能指標(biāo)有：內(nèi)存、CPU、電量、流量、速度/耗時。這里從2個角度分析：

1）為什么選這個指標(biāo)？

2）指標(biāo)常用單位有哪些？

著重講下關(guān)注最多的：內(nèi)存、CPU。

1. 內(nèi)存

為什么要選內(nèi)存呢？需要知道Android的OOM和Low Memory Killer。

OOM：Out Of Memory，顧名思義是說內(nèi)存不夠用或者耗盡了，進程會被強制終止。安卓框架限制了每個應(yīng)用進程所占用的最大內(nèi)存值。關(guān)注內(nèi)存的一個目的就是避免內(nèi)存使用過大，出現(xiàn)OOM。主要關(guān)注內(nèi)存使用較多時的場景，例如游戲app正在游戲中。

Low Memory Killer：Low Memory Killer在用戶空間中指定了一組內(nèi)存臨界值，當(dāng)其中的某個值與進程描述中的oom_adj值在同一范圍時，該進程將被Kill掉。如果你的APP某個進程需要一直保存存活，你需要保持你的進程優(yōu)先級足夠高，并且占用比較小，因為Low Memory Killer在工作時，同一優(yōu)先級的進程會先kill那個占用最大的。性能測試時主要關(guān)注待機時的內(nèi)存是不是夠小。

這里再補充一點：Low Memory Killer的工作可能致系統(tǒng)變卡。為什么呢？因為它kill了一些進程，然而現(xiàn)在市面的很多APP為了?；疃紩詥?，剛剛被kill，立刻又起來。啟動占用大量內(nèi)存（還有CPU），又觸發(fā)Low Memory Killer。頻繁的被kill和啟動形成了惡性循環(huán)，so…系統(tǒng)變的很卡。

內(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。

測試中比較常見的的選擇是PSS total，這種算法共享庫內(nèi)存按比例分配，對APP來說比較公平。依據(jù)APP關(guān)注點，也可選擇其他指標(biāo)例如USS，或者將其他指標(biāo)也一起統(tǒng)計，用于分析。

例如用dumpsys meminfo命令看到，手機管家進程的pss total = 16708 kb。

2. CPU

為什么要關(guān)注CPU？

（1）CPU使用率

想必你肯定有這樣的經(jīng)歷：玩某個游戲或者APP的時候，手機發(fā)熱發(fā)燙。是的，CPU的頻繁使用，會讓你的手機發(fā)燙，讓你的手機變卡（CPU資源不足）。如果讓用戶發(fā)現(xiàn)你的APP用起來發(fā)燙，那就等著他的吐槽和卸載吧。

也就是說CPU性能，我們需要關(guān)注APP使用中CPU消耗情況，通常會使用CPU使用率這個指標(biāo)。

（2）CPU jiffies

如果APP在退出界面后還有進程長期運行，那你需要關(guān)注下待機場景的CPU。待機場景下CPU的消耗一般不會很大，例如手機管家，可能消耗經(jīng)常是0%，1%，長時間平均下，可能只有0.1%、0.2%，看看競品，也是差不多，好像沒有太大區(qū)別。

那么CPU消耗這么少是不是就不用管CPU了呢，然而即使是平均值很小，但是長時間待機，例如安全類工具，CPU的消耗還是不容忽視。那么這種情況如何評估CPU呢，這里引入一個更精確的指標(biāo)：CPU時間片： jiffies！

Jiffies：為Linux核心變數(shù)(unsigned long)，它被用來記錄系統(tǒng)自開機以來，已經(jīng)過了多少tick。一定時間占用的jiffies可以反映出此進程的CPU消耗。

Android系統(tǒng)可以獲取到APP進程當(dāng)前的CPU jiffies（這個數(shù)值不斷累加）。我們測試時常用的單位有：消耗XX jiffies/分鐘；半/1小時共增加XX jiffies。

Tips :Jiffies與變頻

Linux 內(nèi)核中提供了 performance 、powersave 、userspace、conservative 和 ondemand 五種變頻模式供用戶選擇使用，它們在選擇 CPU 合適的運行頻率時使用的是各自不同的標(biāo)準(zhǔn)并分別適用于不同的應(yīng)用場景。那么，測試CPU jiffies的時候是否需要固定CPU頻率呢？理論來講，固定CPU 頻率肯定是可以的，那么不固定會怎樣呢？

經(jīng)測試數(shù)據(jù)驗證，保持手機同環(huán)境情況下，不固定CPU頻率對于測試無太大影響。

這組測試數(shù)據(jù)是沒有固定CPU頻率情況下測試了5次的jiffies數(shù)據(jù)（每次30min），可以看出，標(biāo)準(zhǔn)差為1.56，波動并不大，基本可以排除變頻的影響。

3. 電量

手機電池資源有限，電量的重要性就不必說了?，F(xiàn)在很多手機都有電量排行，如果你的APP總是排在前面，小心被卸載哦。電量通常的單位是：mAs或者mAh。

4. 流量

手機的一個特點就是有移動網(wǎng)絡(luò)。移動網(wǎng)絡(luò)下的流量消耗需要特別關(guān)注，wifi下的流量優(yōu)先級略低。流量單位：kb，M。

5. 速度/耗時

可用性原則里面有個2秒原則：一個松散的原則，即用戶沒有必要對某些系統(tǒng)響應(yīng)等待2秒以上的時間，比如應(yīng)用程序轉(zhuǎn)換和開始的響應(yīng)時間。對于啟動APP，進入某頁面，這些操作時間都應(yīng)不超過2秒，且越短用戶體驗越好。

當(dāng)然，2秒并不是絕對的，對于一些用戶感知明顯的功能，例如垃圾掃描，病毒查殺，可能需要更多的時間，但是操作進行期間，需要給用戶適當(dāng)?shù)母兄皖A(yù)期，避免用戶因等待過久而離開。當(dāng)然，用戶是期望能夠又準(zhǔn)又快。

測試場景

性能要測哪些場景呢？用戶實際使用中，場景是多種多樣的。拿手機管家來說，有的用戶每天喜歡拉拉小火箭；有的用戶經(jīng)常安裝卸載app；有的用戶喜歡用它清理垃圾；又有的用戶有很多騷擾電話和短信；還有用戶喜歡用它連免費wifi；另一些用戶安裝后不怎么使用。用戶多種多樣，功能多種多樣，場景多種多樣。要測試性能，這么多場景全部覆蓋是不太可能的，要選擇什么場景比較合適呢？

選擇性能測試場景前，我們可以先將上述說的這些場景來分分類。

從用戶使用APP時APP的activity是否在最前端，可將APP的使用場景分為：前臺、后臺。

在后臺時根據(jù)APP只是保持心跳等最基礎(chǔ)功能，還是一些場景觸發(fā)了相關(guān)功能，可分為：后臺待機和后臺使用場景。

于是我們有了下面三個層次的場景：后臺待機、后臺使用、前臺使用，場景模型如下：

1. 場景與性能指標(biāo)

先說說這些場景要關(guān)注些哪些性能指標(biāo)。

（1）后臺待機

指標(biāo)：重點關(guān)注待機內(nèi)存和待機耗電情況。流量有需要則關(guān)注。

內(nèi)存和耗電可取實際測試值作為數(shù)據(jù)。例如待機內(nèi)存19M；24h待機電量3mAh。如果你的APP的耗電模塊主要是CPU，你可以考慮使用CPU 時間片（jiffies）來評估。

測試時長：這個場景的耗電和CPU消耗會比較小，測試時需要考慮較長時間的測試數(shù)據(jù)以便反應(yīng)APP的性能情況。

（2）后臺使用

指標(biāo)：重點關(guān)注一個場景觸發(fā)APP功能時的內(nèi)存、CPU使用率或電量。

內(nèi)存通常會取增量，即：觸發(fā)功能后的內(nèi)存-觸發(fā)前的待機內(nèi)存，作為某功能消耗的內(nèi)存。

（3）前臺使用

常關(guān)注使用時的內(nèi)存、CPU使用率、流量。如果是某個操作需要一些時間，需要關(guān)注速度和耗時。

2. 場景與用戶感知

（1）后臺待機

這個場景下用戶的感知是：我沒有使用這個APP，因此這種場景如果有性能消耗的情況下，一定是非常小的，否則用戶會認(rèn)為：我沒用都占這么大內(nèi)存！耗這么多電！讓用戶有這種感受是非常危險的。

例如：手機管家只在通知欄有個小圖標(biāo)，用戶沒有感覺自己在使用。

（2）后臺使用

這個場景下APP確實進行了一些工作，但是用戶對于自己使用了APP并不會有特別明顯的感知。例如來電話時手機管家會進行電話的識別以判斷是不是騷擾電話等，用戶看到的是一個來去電懸浮窗，但是用戶并沒有主動使用，因此這種情況下性能消耗也不可以過高。

（3）前臺使用

這個場景是用戶打開了APP進行使用，此時的性能消耗也是比較大的，但是用戶的容忍度也會相對比較大。但是OOM導(dǎo)致閃退、手機發(fā)燙這些現(xiàn)象是絕對不允許的。性能消耗當(dāng)然是越小用戶越喜歡。

3. 場景與測試優(yōu)先級

場景分層圖中，三個層次場景成金字塔形狀，他們的占用面積同時反映了他們在用戶側(cè)使用時占用的時長。

這么多場景，時間有限，哪個場景更重要，我應(yīng)該先測哪個呢？下面說說如何評估這些場景的重要程度和優(yōu)先級。

原則：用戶在該場景停留越久，該場景越重要；場景被用戶使用到的頻率越高，該場景優(yōu)先級越高。評估方法有：

（1）運營數(shù)據(jù)評估

對于后臺待機場景，我們使用時長來評估優(yōu)先級。重要程度=時長（數(shù)值越高越重要）。從運營數(shù)據(jù)中我們可以得到場景1、2、3在用戶側(cè)使用的時長T1、T2、T3。例如用戶平均每天亮屏5小時，滅屏19小時，那么滅屏待機場景重要程度=19，高于亮屏的5。

對于后臺使用和前臺使用場景，我們用使用頻率來評估，優(yōu)先級=N，N=幾天1次（數(shù)值越小優(yōu)先級越高）。例如：收短信場景，這個場景每個用戶每天都會遇到；而安裝/卸載APP這個場景，用戶可能平均5天操作一次。那么收短信場景的優(yōu)先級=1，安裝卸載app場景優(yōu)先級=5。

（2）ACC測試建模

當(dāng)我們沒有獲得運營數(shù)據(jù)時，可以考慮使用ACC建模思路來幫助區(qū)分性能場景優(yōu)先級：分析產(chǎn)品的核心價值；分析產(chǎn)品的主要模塊、系統(tǒng)；FENIX每個系統(tǒng)提供何種能力實現(xiàn)產(chǎn)品價值；區(qū)分優(yōu)先級。

測試工具

測試工具的本質(zhì)是獲取性能數(shù)據(jù)，當(dāng)然一些工具在使用和觀察數(shù)據(jù)上有差別。工具分2類：現(xiàn)有工具，其他獲取方案。這里列舉下目前我們常用的工具共選擇和參考：

手工和自動化測試

如果是新手或者只需測試幾次，可考慮手工進行性能測試，建議選擇方便直觀易用的工具。測試內(nèi)存和CPU使用率，推薦使用APT（http://code.tencent.com/apt.htmleclipse插件，可實時監(jiān)控Android手機上多個應(yīng)用的CPU、內(nèi)存數(shù)據(jù)曲線，直觀方便。），它最為

如果是需要長期測試的內(nèi)容，需要考慮自動化測試。自動化測試方案我們常用UIAutomator來實現(xiàn)，其中獲取性能數(shù)據(jù)的方案，可查看上表。

這里需要特別提下，在獲取CPU 時間片（jiffies）數(shù)據(jù)時需要注意，測試工具應(yīng)該做盡量少的事情（不要同時用dumpsys meminfo獲取內(nèi)存會增加該進程的CPU消耗），減少對被測app性能的影響，選擇性能消耗小的方式。建議：工具獲取方式從系統(tǒng)文件/proc/(pid)/stat讀取CPU jiffies，不做其他測試內(nèi)存等等事情。

性能測試構(gòu)建

到這里為止，對于APP性能測試的指標(biāo)選擇，場景選擇，用什么工具有了一定了解。我們可以構(gòu)建性能測試了。

例如，手機管家需要長期關(guān)注一些重點性能指標(biāo)，指標(biāo)則選取了：內(nèi)存和耗電，啟動速度。由于用戶在使用管家過程中，大部分時間都是處于“后臺待機”場景，故我們選擇測試的場景是：滅屏待機，亮屏待機。

內(nèi)存使用PSS total，耗電由于主要耗電模塊是CPU，因此我們選擇使用CPU來評估耗電，待機CPU消耗小，故使用了CPU時間片 jiffies。

基礎(chǔ)指標(biāo)性能測試構(gòu)建如下：

當(dāng)然，除了這些基礎(chǔ)指標(biāo)，我們還需要測試其他場景，但可能不是每個版本都測。對于手機管家，三個層次的場景測試頻率如下：

具體每個場景的分析，測試頻率參考：

最后，測試數(shù)據(jù)如果是單次、單個是沒意義的，我們通常用兩種方法做對比：歷史版本對比、競品對比。

當(dāng)你要著手給APP做性能測試時，記得分析APP性能測試的三要素：性能指標(biāo)、測試場景、測試工具，體系化構(gòu)建你的性能測試任務(wù)，讓APP性能保持優(yōu)秀，運行更順暢。

本章完~

原文連接：http://tmq.qq.com/2016/07/triangle-explaining-app-performance/

TMQ（騰訊移動品質(zhì)中心）是騰訊最早專注在移動APP測試的團隊

我們專注于移動測試技術(shù)精華，飽含騰訊多款億級APP的品質(zhì)秘密，文章皆獨家原創(chuàng)，我們不談虛的，只談干貨！