一、 App 性能指標(biāo)

App 性能問題如 app 使用時(shí)卡頓嚴(yán)重或者加載頁面慢，cpu 占用率高，app 閃退等，在測(cè)試過程中，則需特別關(guān)注性能方面的體驗(yàn)，app 性能差，通常會(huì)導(dǎo)致用戶對(duì) app 的使用率下降，卸載率上升。

性能專項(xiàng)測(cè)試用戶維度

性能專項(xiàng)測(cè)試技術(shù)維度

響應(yīng)
軟件的響應(yīng)時(shí)間和響應(yīng)速度直接影響到用戶的體驗(yàn)度，如果一個(gè)軟件，遲遲加載不出來，會(huì)直接影響到軟件的日活、留存。因此對(duì)于一個(gè)軟件，對(duì)響應(yīng)速度測(cè)試是必不可少的。
優(yōu)秀：0～400ms，標(biāo)準(zhǔn)：400ms～2000ms，輕微隱患：2000ms～5000ms，嚴(yán)重隱患：5000ms 以上。
內(nèi)存
在 Android 系統(tǒng)中，每個(gè) APP 進(jìn)程除了同其他進(jìn)程共享內(nèi)存(shared dirty)外，還獨(dú)用私有內(nèi)存(private dirty)，通常我們使用 PSS(私有內(nèi)存+比例分配共享內(nèi)存)來衡量一個(gè) APP 的內(nèi)存開銷。由于一個(gè)移動(dòng)設(shè)備的內(nèi)存是固定的，如果內(nèi)存消耗過大就會(huì)造成應(yīng)用卡頓或者閃退，需要對(duì)內(nèi)存進(jìn)行測(cè)試。正常情況下，應(yīng)用不應(yīng)占用過多的內(nèi)存資源，且能夠及時(shí)釋放內(nèi)存，保證整個(gè)應(yīng)用內(nèi)的穩(wěn)定性和流暢性。
CPU
主要關(guān)注的 CPU 的占用率。玩手機(jī)時(shí)，會(huì)出現(xiàn)發(fā)熱發(fā)燙，那是因?yàn)?CPU 使用率過高，CPU 過于繁忙，會(huì)使整個(gè)手機(jī)無法響應(yīng)用戶，整體性能降低，用戶體驗(yàn)就會(huì)很差，也容易引起 ANR（application not responding，應(yīng)用程序無響應(yīng)，主線程(UI線程)如果在規(guī)定時(shí)內(nèi)沒有處理完相應(yīng)工作，就會(huì)出現(xiàn) ANR）等等一系列問題。
FPS
應(yīng)用的使用流暢度，F(xiàn)PS 是圖像領(lǐng)域中的定義，是指畫面每秒傳輸幀數(shù)，通俗來講就是指動(dòng)畫或視頻的畫面數(shù)。FPS 是測(cè)量用于保存、顯示動(dòng)態(tài)視頻的信息數(shù)量。每秒鐘幀數(shù)愈多，所顯示的動(dòng)作就會(huì)愈流暢。
一般，Android 設(shè)備的屏幕刷新率為 60 幀/s，要保持畫面流暢不卡頓，要求每一幀的時(shí)間不超過 1000/60=16.6ms，這就是 16ms 的黃金準(zhǔn)則，如果中間的某些幀的渲染時(shí)間超過 16ms，就會(huì)導(dǎo)致這段時(shí)間的畫面發(fā)生了跳幀，因此原本流暢的畫面變發(fā)生了卡頓。
GPU 過度渲染
GPU 渲染是指在一個(gè)像素點(diǎn)上繪制多次（超過一次）：顯示一個(gè)什么都沒有做的activity 界面算作畫了 1 層，給 activity 加一個(gè)背景是第 2 層，在上面放了一個(gè) TextView（有背景的 Text View）是第 3 層，Text View 顯示文本就是第 4 層，僅僅只是為了顯示一個(gè)文本，卻在同一個(gè)像素點(diǎn)繪制了四次，這一定要優(yōu)化的。過度繪制對(duì)動(dòng)畫性能的影響是極其嚴(yán)重的，如果你想要流暢的動(dòng)畫效果，那么一定不能忽視過度繪制。
耗電量
測(cè)試應(yīng)用對(duì)電量的消耗前需要對(duì)手機(jī)本身的電量消耗有個(gè)大概了解，測(cè)試前先看規(guī)定時(shí)間內(nèi)手機(jī)正常待機(jī)下（重啟后待機(jī)）電量消耗為多少，然后再啟動(dòng)待測(cè)試 APP看看消耗的電量增加了多少取差值。

測(cè)試點(diǎn)：
?測(cè)試手機(jī)安裝目標(biāo) APK 前后待機(jī)功耗無明顯差異；
?常見使用場景中能夠正常進(jìn)入待機(jī)，待機(jī)電流在正常范圍內(nèi)；
?長時(shí)間連續(xù)使用應(yīng)用無異常耗電現(xiàn)象。
流量測(cè)試
目前的網(wǎng)絡(luò)類型包含 2G3G4Gwifi，其中還有不同運(yùn)營商的區(qū)分，我們?cè)?APP 的使用中經(jīng)常遇到大資源，重復(fù)請(qǐng)求，調(diào)用響應(yīng)慢，調(diào)用失敗等各種情況。在不同的網(wǎng)絡(luò)類型之下，我們不僅加快請(qǐng)求的響應(yīng)，還要控制流量使用。
每秒鐘平均流量，建議值<5.12kb，每 10 分鐘平均流量，建議值<3MB,不存在 app偷跑流量等行為。

二、 使用 adb 進(jìn)行測(cè)試

1.App 響應(yīng)時(shí)間和響應(yīng)速度測(cè)試

1.1 主要測(cè)試點(diǎn)
冷啟動(dòng)：首次啟動(dòng) app 的時(shí)間間隔（只是啟動(dòng)時(shí)間，不包括頁面加載）
熱啟動(dòng)：非首次啟動(dòng) app 的時(shí)間間隔（只是啟動(dòng)時(shí)間，不包括頁面加載）
Activity的啟動(dòng)流程

1.2 測(cè)試方法
冷啟動(dòng)
adb shell am start -W com.tencent.mm/.ui.LauncherUI（啟動(dòng)App)
adb shell am force -stop 包名（停止APP）
?絕對(duì)路徑，首個(gè) Activity
? am 是 shell 中集成的一個(gè)命令，ActivityManager 的簡寫。
? -W 是指啟動(dòng)完成之后，返回啟動(dòng)耗時(shí)。
?可能存在 app 緩存（提示 Warning: Activity not started, intent has beendelivered to currently running top-most instance），建議重新打開模擬器后，直接運(yùn)行命令

含義
? ThisTime: 該 Activity 的啟動(dòng)耗時(shí)，單位 ms；
? TotalTime: 應(yīng)用自身啟動(dòng)耗時(shí), ThisTime+應(yīng)用application等資源啟動(dòng)時(shí)間；
? WaitTime: 系統(tǒng)啟動(dòng)應(yīng)用耗時(shí), TotalTime+系統(tǒng)資源啟動(dòng)時(shí)間。
如果只關(guān)心某個(gè)應(yīng)用自身啟動(dòng)耗時(shí)，參考 TotalTime；如果關(guān)心系統(tǒng)啟動(dòng)應(yīng)用耗時(shí)，參考 WaitTime；如果關(guān)心應(yīng)用所有界面 Activity 啟動(dòng)耗時(shí)，參考 ThisTime。
熱啟動(dòng)

按返回按鍵（adb shell input keyevent 3）后再啟動(dòng) adb 命令
測(cè)試標(biāo)準(zhǔn)：冷啟動(dòng)時(shí)間不超過 1.5s，熱啟動(dòng)不超過 1s。
注意：此種方法不包含頁面渲染時(shí)間。
可以通過錄屏逐幀的方式獲取到首屏渲染時(shí)間。
andriod錄屏方式：
adb shell screenrecord --time-limit 10 /sdcard/video.mp4（--time-limit 10：限制錄制時(shí)間10s,不做限制默認(rèn)為180s）
adb pull/sdcard/video.mp4 /user/desktop/video
錄屏逐幀
通過ffmpeg分幀（ffepeg的配置參考：https://blog.csdn.net/chy466071353/article/details/54949221）
ffmpeg -i d:/test/video.mp4 -r 10 -threads 2 d:/test/Android-Capture-%05d.png (-r 10 表示1s分成10幀,即1幀為0.1s)
視頻內(nèi)容包含：桌面 → 被測(cè) App 圖標(biāo)變黑 → 展示知乎開屏 → 展示主體框架 → 首頁內(nèi)容加載完成。
由于首頁內(nèi)容加載完成是異步實(shí)現(xiàn)的，因此我們選取分析的關(guān)鍵節(jié)點(diǎn)，是「被測(cè) App 圖標(biāo)變黑」和「展示主體框架」這兩個(gè)點(diǎn)。
通過 FFmpeg 將視頻轉(zhuǎn)換成分幀后的圖像，用[展示主體框架]圖片的后綴減去[被測(cè)圖片APP變黑]的后綴*0.1s。

(49-11)*0.1=3.8s

1.3ios啟動(dòng)時(shí)長的獲取
參考https://zhuanlan.zhihu.com/p/48218035，主要方式也是錄屏。

常見的 iOS 啟動(dòng)時(shí)長測(cè)試方法，主要有以下幾種

Xcode Developer Tool： 使用 Instruments 的 Time Profiler 插件，可以檢測(cè) App CPU 的使用情況。能看到 App 的啟動(dòng)時(shí)間和各個(gè)方法消耗的時(shí)間；
客戶端計(jì)算統(tǒng)計(jì)： 通過 hook 關(guān)鍵函數(shù)的調(diào)用，計(jì)算獲得性能數(shù)據(jù)。目前知乎 App 性能監(jiān)控已有啟動(dòng)時(shí)長數(shù)據(jù)，類似的還有一些第三方的性能測(cè)試工具；
錄屏：使用截屏、錄屏、高速攝像機(jī)錄像等方法，記錄移動(dòng)設(shè)備屏幕上的變化，分析啟動(dòng)的起止點(diǎn)，獲取 app 啟動(dòng)的耗時(shí)。

方法 1 可以精確獲取各個(gè)方法調(diào)用的耗時(shí)，需要 App 是 developer 證書簽名，否則無法執(zhí)行測(cè)試；

方法 2 可以精確獲取各個(gè)啟動(dòng)項(xiàng)耗時(shí)，但和實(shí)際用戶體驗(yàn)感受有一定出入，且需要拿到客戶端源碼，將工具嵌入客戶端中；

方法 3 和用戶直觀感受一致，但分析截屏、視頻較麻煩，且發(fā)現(xiàn)問題時(shí)，無法定位到具體的啟動(dòng)耗時(shí)項(xiàng)。

目前對(duì)于競品啟動(dòng)時(shí)長的對(duì)比測(cè)試，由于源碼和簽名的限制，方法 1 和 2 都不太合適。

注意：有時(shí)會(huì)存在啟動(dòng)頁面廣告，而各 App 在展示開屏廣告的過程中，可能會(huì)有其他啟動(dòng)項(xiàng)在執(zhí)行。所以需要分兩個(gè)場景進(jìn)行測(cè)試，有廣告和無廣告。

2 .內(nèi)存占用測(cè)試

2.1 主要測(cè)試點(diǎn)

空閑狀態(tài)
　　切換至后臺(tái)或者啟動(dòng)后不做任何操作，消耗內(nèi)存最少。
中強(qiáng)度狀態(tài)
　　時(shí)間偏長的操作應(yīng)用。
高強(qiáng)度狀態(tài)
　　高強(qiáng)度使用應(yīng)用，可以跑 monkey 來測(cè)試（通常用來測(cè)試內(nèi)存泄漏）。
　　內(nèi)存泄漏(OOM）:指使用 malloc 或 new 申請(qǐng)了一塊內(nèi)存，但是沒有通過 free 或 delete 將內(nèi)存釋放，導(dǎo)致這塊內(nèi)存一直處于占用狀態(tài)。

2.2 測(cè)試方法

使用 adb 命令
adb shell dumpsys meminfo com.tencent.mm
主要指標(biāo)
Native heap allocNative：代碼分配的內(nèi)存，虛擬機(jī)和Android框架分配內(nèi)存。
Dalvik heap alloc：Java對(duì)象分配的占據(jù)內(nèi)存

若這兩個(gè)值一直增長，說明可能出現(xiàn)內(nèi)存泄漏
PSS：App 實(shí)際占用的內(nèi)存大小。

主要關(guān)注
?退出某個(gè)頁面后，內(nèi)存是否有回落。
如果沒有及時(shí)回落，且程序自動(dòng) GC（Garbage Collection，垃圾回收）或者手動(dòng) GC，那便可確認(rèn)有問題。
?進(jìn)行某個(gè)操作后，內(nèi)存是否增長過快。
如果增長過快，也有可能存在風(fēng)險(xiǎn)，需重復(fù)操作確認(rèn)

android內(nèi)存主要有四種形式：VSS 、RSS 、PSS 、 USS

一般來說內(nèi)存占用大小有如下規(guī)律：VSS >= RSS >= PSS >= USS

VSS：Virtual Set Size，虛擬耗用內(nèi)存。它是一個(gè)進(jìn)程能訪問的所有內(nèi)存空間地址的大小。這個(gè)大小包含了
一些沒有駐留在RAM中的內(nèi)存，就像mallocs已經(jīng)被分配，但還沒有寫入。VSS很少用來測(cè)量程序的實(shí)際使
用內(nèi)存。

RSS：Resident Set Size，實(shí)際使用物理內(nèi)存。RSS是一個(gè)進(jìn)程在RAM中實(shí)際持有的內(nèi)存大小。RSS可能會(huì)
產(chǎn)生誤導(dǎo)，因?yàn)樗怂性撨M(jìn)程使用的共享庫所占用的內(nèi)存，一個(gè)被加載到內(nèi)存中的共享庫可能有很
多進(jìn)程會(huì)使用它。RSS不是單個(gè)進(jìn)程使用內(nèi)存量的精確表示。

PSS：Proportional Set Size，實(shí)際使用的物理內(nèi)存，它與RSS不同，它會(huì)按比例分配共享庫所占用的內(nèi)存。
例如，如果有三個(gè)進(jìn)程共享一個(gè)占30頁內(nèi)存控件的共享庫，每個(gè)進(jìn)程在計(jì)算PSS的時(shí)候，只會(huì)計(jì)算10頁。
PSS是一個(gè)非常有用的數(shù)值，如果系統(tǒng)中所有的進(jìn)程的PSS相加，所得和即為系統(tǒng)占用內(nèi)存的總和。當(dāng)一個(gè)
進(jìn)程被殺死后，它所占用的共享庫內(nèi)存將會(huì)被其他仍然使用該共享庫的進(jìn)程所分擔(dān)。在這種方式下，PSS
也會(huì)帶來誤導(dǎo)，因?yàn)楫?dāng)一個(gè)進(jìn)程被殺后，PSS并不代表系統(tǒng)回收的內(nèi)存大小。

USS：Unique Set Size，進(jìn)程獨(dú)自占用的物理內(nèi)存。這部分內(nèi)存完全是該進(jìn)程獨(dú)享的。USS是一個(gè)非常有用
的數(shù)值，因?yàn)樗砻髁诉\(yùn)行一個(gè)特定進(jìn)程所需的真正內(nèi)存成本。當(dāng)一個(gè)進(jìn)程被殺死，USS就是所有系統(tǒng)回
收的內(nèi)存。USS是用來檢查進(jìn)程中是否有內(nèi)存泄露的最好選擇。

內(nèi)存

JAVA是在JVM所虛擬出的內(nèi)存環(huán)境中運(yùn)行的，JVM的內(nèi)存可以分成三個(gè)區(qū)，堆（heap）、棧（stack）和方法區(qū)（method）。

棧（stack）

是最簡單的數(shù)據(jù)結(jié)構(gòu)，但在計(jì)算機(jī)中使用廣泛。棧最顯著的特征是：LIFO(后進(jìn)先出），棧中只存放基本類型和對(duì)象的引用（不是對(duì)象）

堆（heap）

堆內(nèi)存用于存放由new創(chuàng)建的對(duì)象和數(shù)組。在堆中分配的內(nèi)存，由java虛擬機(jī)自動(dòng)垃圾回收器來管理。JVM只有一個(gè)堆區(qū)被所有線程共享，堆中不存放基本類型和對(duì)象引用，只存放對(duì)象本身。

方法區(qū)（method）

又叫靜態(tài)區(qū)，跟堆一樣，所有的線程共享。方法區(qū)包含所有的static變量。

內(nèi)存泄露

程序在向系統(tǒng)申請(qǐng)分配內(nèi)存空間后（new）,在使用完畢后未釋放。結(jié)果導(dǎo)致一直占用該內(nèi)存單元，我們和程序都無法再使用該內(nèi)存單元，直到程序結(jié)束。

內(nèi)存溢出

程序向系統(tǒng)申請(qǐng)的內(nèi)存空間超出了系統(tǒng)能給的，比如一車最多坐5個(gè)人，你確非要塞下10個(gè)，車就擠爆了。

大量的內(nèi)存泄露會(huì)導(dǎo)致內(nèi)存溢出（OOM）

內(nèi)存泄露對(duì)應(yīng)用的影響

內(nèi)存泄露對(duì)于APP沒有直接危害，即使有發(fā)現(xiàn)內(nèi)存泄露的情況，也不一定會(huì)引起APP崩潰

內(nèi)存得不到釋放，慢慢的會(huì)造成app內(nèi)存溢出，導(dǎo)致崩潰

內(nèi)存泄露同時(shí)會(huì)觸發(fā)系統(tǒng)頻繁GC,發(fā)生內(nèi)存抖動(dòng)，會(huì)導(dǎo)致性能問題（卡頓不流暢）

3.CPU 繁忙測(cè)試

3.1 主要測(cè)試點(diǎn)

?在空閑時(shí)間(切換至后臺(tái))的消耗，基本沒大應(yīng)用使用 CPU
?在運(yùn)行一些應(yīng)用的情況下，CPU 已占 50%的情況下，觀察應(yīng)用程序占用 CPU 的情況
?在高負(fù)荷的情況下看 CPU 的表現(xiàn)（CPU 占用應(yīng)是在 80%以上）

3.2 具體場景

?應(yīng)用空閑狀態(tài)運(yùn)行監(jiān)測(cè) CPU 占用率
應(yīng)用按 Home 鍵退到后臺(tái)，不再占用系統(tǒng)的狀態(tài)（通常是滅屏半分鐘后）
CPU 占用率=0%
?應(yīng)用中等規(guī)格運(yùn)行監(jiān)測(cè) CPU 占用率
模擬用戶最常見的使用場景
CPU 占用率≤30%
?應(yīng)用滿規(guī)格長時(shí)間正常運(yùn)行監(jiān)測(cè) CPU 占用率
應(yīng)用正常運(yùn)行，打開應(yīng)用進(jìn)行基本操作
CPU 占用率≤50%

3.3 測(cè)試方法

adb shell dumpsys cpuinfo apk 包名

adb shell top -m -s | findstr packageName
? -m 數(shù)字
顯示指定數(shù)目的最大值，一般后面不再接 findstr
使用-m 會(huì)導(dǎo)致隱藏列名
? -s 數(shù)字
按指定列號(hào)進(jìn)行倒序排列
從 1 開始，最大 11
9 代表 CPU，10 代表內(nèi)存
?-n 數(shù)字
刷新幾次后退出
? -d 秒數(shù)
刷新間隔
? q 回車
退出

4.FPS 應(yīng)用流暢度測(cè)試

幀率(Frame Rate)：代表GPU在一秒內(nèi)繪制操作的幀數(shù)，例如：30fps，60fps

刷新頻率(Refresh Rate):代表屏幕在一秒內(nèi)刷新屏幕的次數(shù)，這取決于硬件的固定參數(shù)，如60HZ.

(1)開啟 Profile GPU renderingSettings→System→Advanced→Developer options→查找 profile→找到并單擊 ProfileGPU rendering→In adb shell dumpsys gfxinfo
(2)打開要測(cè)試的 app

adb shell dumpsys gfxinfo 包名

? Graphics info for pid 1331 [com.tencent.mm]：表明當(dāng)前 dump 的為 com.tencent.mm的幀信息，pid 為 1331。
? Total frames rendered: 2218：本次 dump 搜集了 2218 幀的信息。
? Janky frames: 26 (1.17%)：幀中有 26 幀的耗時(shí)超過了 16ms，卡頓概率為 1.17%。
? Number Missed Vsync: 3：垂直同步失敗的幀
? Number High input latency:2213：處理 input 時(shí)間超時(shí)的幀
? Number Slow UI thread: 1：因?yàn)?ui 線程導(dǎo)致 slow 的幀
? Number Slow bitmap uploads: 0：因?yàn)?bitmap 加載 slow 的幀
? Number Slow issue draw commands: 3：因?yàn)槔L制導(dǎo)致 slow 的幀

? Draw: 表示在 Java 中創(chuàng)建顯示列表部分中的 OnDraw()方法占用的時(shí)間。
? Prepare：表示渲染引擎準(zhǔn)備時(shí)間。
? Process：表示渲染引擎執(zhí)行顯示列表所花的時(shí)間，view 越多，時(shí)間就越長。
? Execute：表示把一幀數(shù)據(jù)發(fā)送到屏幕上排版顯示實(shí)際花費(fèi)的時(shí)間。其實(shí)是實(shí)際顯示幀數(shù)據(jù)的后臺(tái)緩沖區(qū)與前臺(tái)緩沖區(qū)交換后，將前臺(tái)緩沖區(qū)的內(nèi)容顯示到屏幕上的時(shí)間。
? Draw + Perpare+Process + Execute = 完整顯示一幀 ，這個(gè)時(shí)間要小于 16ms 才能保存每秒60 幀。
?通過 execl 進(jìn)行表格處理可以直觀的查看軟件的流暢度
只保留 Process、Draw、Execute,將三列加和繪制線圖;16ms 以上的卡頓，需要優(yōu)化

? Settings→System→Advanced→Developer options→查找 profile→on screen as bars結(jié)果以圖形形式顯示在設(shè)備中
開啟此功能后，隨著屏幕刷新，界面上會(huì)滾動(dòng)顯示垂直的柱狀圖來表示每幀畫面所需要渲染的時(shí)間，柱狀圖越高表示花費(fèi)的渲染時(shí)間越長。
每個(gè)直方條代表一幀，每個(gè)直方條的高度表示該幀渲染所用的時(shí)間（以毫秒為單位）
界面中間一根綠色水平線代表 16ms，每一幀的柱狀線都在這條綠線以下，才能避免出現(xiàn)由丟幀引起的卡頓。

?顏色含義（Android 6.0 及更高版本中的豎條區(qū)段）

5.GPU 過度渲染測(cè)試

開啟 GPU 過度渲染

?設(shè)置→開發(fā)者選項(xiàng)→單擊 Debug GPU overdraw→選擇 show overdraw areas

? GPU 過渡渲染不同的顏色代表不同的繪制程度
原色：無過渡繪制
藍(lán)色：繪制一次 （理想狀態(tài)）
綠色：繪制二次
淺紅：繪制三次 （可以優(yōu)化）
深紅：繪制四次 （必須優(yōu)化）

測(cè)試指標(biāo)
?控制過渡繪制為 2x
?不允許存在 4x 過渡繪制
?不允許存在面積超過屏幕 1/4 的 3x 過渡繪制

6、流量數(shù)據(jù)獲取

先獲取進(jìn)程命令 adb shell ps | grep 包名
獲取流量：adb shell cat /proc/進(jìn)程名/net/dev
receive表示收包（下行）
Transmit表示收包（上行）
bytes表示收發(fā)的字節(jié)數(shù)
packets表示收發(fā)正確的包量
errs:表示收發(fā)錯(cuò)誤的包量
drop表示收發(fā)丟棄的包量

7、電量數(shù)據(jù)獲取

adb shell dumpsys battery set status 1（設(shè)置手機(jī)進(jìn)入非充電狀態(tài) 2為充電狀態(tài)）
db shell dumpsys battery（獲取電量） level表示電量

8、如何開展性能專項(xiàng)測(cè)試

1）什么時(shí)間點(diǎn)開展？

一般情況只有大版本迭代或者重點(diǎn)性能優(yōu)化才進(jìn)行

2）基于什么基礎(chǔ)上測(cè)試？

歷史版本&競品

3）什么時(shí)間點(diǎn)開展？

一般在第一輪測(cè)試結(jié)束無需大修改

4）要哪些場景？

App核心場景，需要優(yōu)化場景

5）要測(cè)什么包？

一般測(cè)正式包，反應(yīng)真是用戶體感

6）要測(cè)幾輪？

一般正式測(cè)試一輪，剩余看開發(fā)優(yōu)化

9、性能專項(xiàng)測(cè)試流程

1）跟進(jìn)版本確定這個(gè)版本性能測(cè)試需求

2）跟開發(fā)確定測(cè)試場景和側(cè)重點(diǎn)，并且確定基線數(shù)據(jù)和測(cè)試手段

基線數(shù)據(jù)：前三個(gè)版本的最優(yōu)數(shù)據(jù)和競品數(shù)據(jù)

3）執(zhí)行性能測(cè)試采集數(shù)據(jù)

4）編寫性能測(cè)試報(bào)告

10、性能專項(xiàng)測(cè)試報(bào)告

1）基本信息：版本/測(cè)試機(jī)型/測(cè)試場景/基線場景

2）問題概述：具體問題列表

3）具體性能專項(xiàng)數(shù)據(jù)列表

4）修復(fù)建議/風(fēng)險(xiǎn)

實(shí)例：

總結(jié)

以上是生活随笔為你收集整理的移动APP性能测试的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。