|
移動測試 Android測試 APP測試
Android篇1. 性能測試Android性能測試分為兩類：
1、一類為rom版本（系統(tǒng)）的性能測試
2、一類為應用app的性能測試 Android的app性能測試包括的測試項比如：
1、資源消耗
2、內(nèi)存泄露
3、電量功耗
4、耗時
5、網(wǎng)絡流量消耗
6、移動終端相關(guān)資源利用率
7、幀率
8、渲染等等.... 工具：
（工具的原理都是基于調(diào)用android底層的一些api來獲取到測試所用到的值）GT等 測試方法：
1、設(shè)計場景 ：手工或自動化場景
2、獲取數(shù)據(jù)：可獲取的數(shù)據(jù)包括：內(nèi)存、cpu、電量功耗、hprof（內(nèi)存泄露分析文件）、響應時間等等。。。。配合手工或自動化場景來獲取數(shù)據(jù)（最好多取幾次而且每次配合不同的設(shè)備看平均值）作為最后的對比分析
3、結(jié)果分析 ：拿到數(shù)據(jù)后分析哪些模塊的數(shù)據(jù)異常再去Check code定位問題的原因 Android系統(tǒng)的幾種場景狀態(tài)：
1、空閑狀態(tài)： 指打開應用后，點擊home鍵讓應用后臺運行，此時應用處于的狀態(tài)叫做空閑
2、中等規(guī)格和滿規(guī)格狀態(tài)：中等規(guī)格和滿規(guī)格指的是對應用的操作時間的間隔長短不一，中等規(guī)格時間較長，滿規(guī)格時間較短
1.1 內(nèi)存篇背景知識：
C/C++申請的內(nèi)存空間在native heap中，而java申請的內(nèi)存空間則在dalvik heap中。這個是因為Android系統(tǒng)對dalvik的vmheapsize作了硬性限制，當java進程申請的java空間超過閾值時，就會拋出OOM異常（這個閾值可以是48M、24M、16M等，視機型而定），可以通過adb shell getprop | grep dalvik.vm.heapgrowthlimit查看此值。也就是說，程序發(fā)生OMM并不表示RAM不足，而是因為程序申請的java heap對象超過了dalvik vmheapgrowthlimit。也就是說，在RAM充足的情況下，也可能發(fā)生OOM。 這樣的設(shè)計似乎有些不合理，但是Google為什么這樣做呢？這樣設(shè)計的目的是為了讓Android系統(tǒng)能同時讓比較多的進程常駐內(nèi)存，這樣程序啟動時就不用每次都重新加載到內(nèi)存，能夠給用戶更快的響應。迫使每個應用程序使用較小的內(nèi)存，移動設(shè)備非常有限的RAM就能使比較多的app常駐其中。但是有一些大型應用程序是無法忍受vmheapgrowthlimit的限制的 實際上dalvik.vm.heapgrowthlimit和dalvik.vm.heapsize都是java虛擬機的最大內(nèi)存限制，應用如果不想在dalvikheap達到heapgrowthlimit限制的時候出現(xiàn)OOM，需要在Manifest中的application標簽中聲明android：largeHeap=“true”，聲明后應用dalvik heap達到heapsize的時候才會出現(xiàn)OOM
內(nèi)存測試中的測試子項：
1）空閑狀態(tài)下的應用內(nèi)存消耗情況
2）中等規(guī)格狀態(tài)下的應用內(nèi)存消耗情況
3）滿規(guī)格狀態(tài)下的應用內(nèi)存消耗情況
4）應用內(nèi)存峰值情況
5）應用內(nèi)存泄露情況
6）應用是否常駐內(nèi)存
7）壓力測試后的內(nèi)存使用情況 內(nèi)存問題現(xiàn)象：
1）內(nèi)存抖動
2）大內(nèi)存對象被分配
3）內(nèi)存不斷增長
4）頻繁GC 內(nèi)存數(shù)據(jù)獲?。?
1、各種linux命令（top、free、meminfo…）
2、通過dumpsys
adb shell dumpsys meminfo [pakagename | pid]
3、通過/system/xbin/procrank工具
adb shell procrank
說明：
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)存） USS 是針對某個進程開始有可疑內(nèi)存泄露的情況，是一個程序啟動了會產(chǎn)生的虛擬內(nèi)存，一旦這個程序進程殺掉就會釋放。不過USS需要通過root的手機。一般沒有root的手機我們可以獲取PSS。而PSS通過如下命令來獲?。?code>adb shell dumpsys meminfo <Package Name>|grep TOTAL
4、通過android提供的procrank
1）首先去google獲取procrank、procmem、libpagemap.so三個文件
2）然后push文件，執(zhí)行 adb push procrank /system/xbin adb push procmem
/system/xbin adb push libpagemap.so /system/lib
3）賦權(quán) adb shell chmod 6755 /system/xbin/procrank adb shell chmod 6755 /system/xbin/procmem adb shell chmod 6755 /system/lib/libpagemap.so ,
4）在開啟工具記錄 adb shell procrank |grep packagename >/address/procrank.txt
5、通過android提供的ActivityManager的getMemoryInfo(ActivityManager.MemoryInfo outInfo)（這個方法是寫一個簡單的app去監(jiān)控的時候用到的，輕便簡單）
private void GetMemory() { final ActivityManager activityManager = (ActivityManager) getSystemService(ACTIVITY_SERVICE); ActivityManager.MemoryInfo info = new ActivityManager.MemoryInfo(); activityManager.getMemoryInfo(info); Log.i(tag,"系統(tǒng)剩余內(nèi)存:"+(info.availMem >> 10)+"k"); Log.i(tag,"系統(tǒng)是否處于低內(nèi)存運行："+info.lowMemory); Log.i(tag,"當系統(tǒng)剩余內(nèi)存低于"+info.threshold+"時就看成低內(nèi)存運行");}6、Memory Monitor （android studio的插件） 【makedown？？？】
4. /proc/meminfo文件里列出的字段解釋： MemTotal: 所有可用RAM大小。 MemFree: LowFree與HighFree的總和，被系統(tǒng)留著未使用的內(nèi)存。
Buffers: 用來給文件做緩沖大小。 Cached: 被高速緩沖存儲器（cache memory）用的內(nèi)存的大?。ǖ扔赿iskcache
minus SwapCache）。 SwapCached:被高速緩沖存儲器（cache
memory）用的交換空間的大小。已經(jīng)被交換出來的內(nèi)存，仍然被存放在swapfile中，用來在需要的時候很快的被替換而不需要再次打開I/O端口。
Active: 在活躍使用中的緩沖或高速緩沖存儲器頁面文件的大小，除非非常必要，否則不會被移作他用。 Inactive:
在不經(jīng)常使用中的緩沖或高速緩沖存儲器頁面文件的大小，可能被用于其他途徑。 SwapTotal: 交換空間的總大小。 SwapFree:
未被使用交換空間的大小。 Dirty: 等待被寫回到磁盤的內(nèi)存大小。 Writeback: 正在被寫回到磁盤的內(nèi)存大小。
AnonPages：未映射頁的內(nèi)存大小。 Mapped: 設(shè)備和文件等映射的大小。 Slab:
內(nèi)核數(shù)據(jù)結(jié)構(gòu)緩存的大小，可以減少申請和釋放內(nèi)存帶來的消耗。 SReclaimable:可收回Slab的大小。
SUnreclaim：不可收回Slab的大?。⊿Unreclaim+SReclaimable＝Slab）。
PageTables：管理內(nèi)存分頁頁面的索引表的大小。 NFS_Unstable:不穩(wěn)定頁表的大小。
5. android檢查內(nèi)存泄露步驟： 1、運行Monkey進行壓力測試：
adb shell monkey -p cn.microinvestment.weitou --pct-touch 100 --ingore-crashes --throttle 1000 -s 100 -v -v 50
2、監(jiān)控內(nèi)存值，如果出現(xiàn)過大等遞增異常則保存HPROF文件（hprof文件是Java 虛擬機的Heap快照）用于分析查看應用內(nèi)存的命令：
adb shell dumpsys meminfo cn.microinvestment.weitou(進程名)
如果發(fā)現(xiàn)內(nèi)存過大，則保存HPROF文件：adb shell am dumpheap <進程名> <保存路徑>
3、分析hprof文件
用工具MAT來查看，首先還要這個HPROF文件轉(zhuǎn)換成MAT可讀的文件
在Android SDK tool里面有個hprof-conv命令：
hprof-conv <原HPROF文件路徑> <轉(zhuǎn)換后的HPROF路徑>
hprof-conv a.hprof b.hprof
4、用MAT工具打開轉(zhuǎn)換后的HPROF文件
一般選擇Leak Suspects Report（通過SQL語句來查詢對象有沒有被釋放掉，如果有多個相同的對象，則會存在內(nèi)存泄露的問題） 1.2 CPU篇CPU測試中的測試子項：
1）空閑狀態(tài)下的應用CPU消耗情況
2）中等規(guī)格狀態(tài)下的應用CPU消耗情況
3）滿規(guī)格狀態(tài)下的應用CPU消耗情況
4）應用CPU峰值情況 CPU數(shù)據(jù)獲?。?
1）adb shell dumpsys cpuinfo | grep packagename
2)top命令
adb shell top -m 10 -s cpu #查看占用cpu最高的前10個程序（-t 顯示進程名稱，-s 按指定行排序，-n 在退出前刷新幾次，-d 刷新間隔，-m 顯示最大數(shù)量）
adb shell top | grep PackageName > /address/cpu.txt
1.3 流量篇概念：
中等負荷：應用正常操作
高負荷：應用極限操作 流量測試中的測試子項：
1、應用首次啟動流量值
2、應用后臺連續(xù)運行 2 小時的流量值
3、應用高負荷運行的流量峰值
4、應用中等負荷運行時的流量均值 獲取流量數(shù)據(jù)：
1、tcpdump＋wireshark
2、/proc/net/目錄下相關(guān)文件
cat /proc/net/dev 獲取系統(tǒng)的流量信息
3、查詢應用的pid： adb shell ps | grep tataufo #如：31002
通過PID獲取該應用的流量數(shù)據(jù)： adb shell cat /proc/31002/net/dev
（wlan0代表wifi上傳下載量標識, 單位是字節(jié)可以/1024換算成KB, 打開手機飛行模式再關(guān)掉就可以將wlan0中的值初始化0）
4、查詢應用的pid： adb shell ps | grep tataufo #如：31002
通過PID獲取UID：adb shell cat /proc//status
通過UID獲?。篴db shell cat /proc/net/xt_qtaguid/stats | grep 31002
5、通過adb shell dumpsys package來獲取應用的uid信息，然后在未操作應用之前，通過查看 ：
adb shell cat /proc/uid_stat/uid/tcp_rcv
adb shell cat /proc/uid_stat/uid/tcp_snd
獲取到應用的起始的接收及發(fā)送的流量，然后我們再操作應用，再次通過上述2條命令可以獲取到應用的結(jié)束的接收及發(fā)送的流量，通過相減及得到應用的整體流量消耗
6、Android代碼：Android的TrafficStats類
1.4 功耗篇功耗測試中的測試子項：
1、手機安裝目標APK前后待機功耗無明顯差異
2、常見使用場景中能夠正常進入待機，待機電流在正常范圍內(nèi)
3、長時間連續(xù)使用應用無異常耗電現(xiàn)象 功耗測試方法：
方法一：軟件
1、采用市場上提供的第三方工具，如金山電池管家之類的。
2、就是自寫工具進行，這里一般會使用3種方法：
1）基于android提供的PowerManager.WakeLock來進行
2）比較復雜一點，功耗的計算=CPU消耗+Wake lock消耗+數(shù)據(jù)傳輸消耗+GPS消耗+Wi-Fi連接消耗
3）通過 adb shell dumpsys battery來獲取
3、battery-historian（google開源工具）
方法二：硬件
一般使用萬用表或者功耗儀安捷倫進行測試，使用功耗儀測試的時候，需要制作假電池來進行的，有些不能拔插電池的手機還需要焊接才能進行功耗測試
1.5 GPU篇（FPS）概念：
過度繪制： 界面顯示的activity套接了多層而導致
幀率：屏幕滑動幀速率
幀方差： 屏幕滑動平滑度
**FPS：**Frames Per Second 每秒顯示的幀數(shù) 根據(jù)人眼的生理結(jié)構(gòu)，幀率高于24時就被認為是連貫的。對于游戲畫面30fps是最低能接受的，60fps逼真感，如果幀率高于屏幕刷新頻率就是浪費。要達到30fps，每幀所占用的時間要小于33毫秒 GPU測試中的測試子項：
1、界面過度繪制
2、屏幕滑動幀速率
3、屏幕滑動平滑度 過度繪制測試：（人工進行測試）
打開開發(fā)者選項中的顯示GPU過度繪制（Debug GPU overdraw）
驗收的標準:
1、不允許出現(xiàn)黑色像素
2、不允許存在4x過度繪制
3、不允許存在面積超過屏幕1/4區(qū)域的3x過度繪制（淡紅色區(qū)域） 屏幕滑動幀速率測試：
方法一：
1.手機端打開開發(fā)者選項中的啟用跟蹤后勾選Graphics和View
2.啟動SDK工具Systrace，勾選被測應用，點擊Systrace，在彈出的對話框中設(shè)置持續(xù)抓取時間，在trace taps下面勾選gfx及view選項
3.手工滑動界面可以通過節(jié)拍來進行滑動或者掃動，幀率數(shù)據(jù)會保存到默認路徑下，默認名稱為trace.html
4.將trace.html文件拷貝到linux系統(tǒng)下通過命令進行轉(zhuǎn)換，生成trace.csv文件
grep 'postFramebuffer' trace.html | sed -e 's/.]\W//g' -e 's/:.*$//g' -e 's/.//g' > trace.csv
5.用excel打開文件計算得到幀率
方法二：
硬件的方法，打開高速相機，開啟攝像模式，錄制手工滑動或者掃動被測應用的視頻，再通過人工或者程序數(shù)幀的方法對結(jié)果進行計算得到幀率 屏幕滑動平滑度的測試：
方法如同幀率測試，唯一的差異就是最后的結(jié)果計算公式的差異 捕獲app幀率（android流暢度FPS測試）：
1、打開手機開發(fā)者選項，勾選GPU顯示配置文件（系統(tǒng)會記錄保留每個界面最后128幀圖像繪制的相關(guān)時間信息）
2、adb shell dumpsys gfxinfo com.xxx.xxx > zinfo.txt
3、結(jié)果數(shù)據(jù)分析
Profile data in ms部分：
Draw： 創(chuàng)建顯示列表的時間（DisplayList），所有View對象OnDraw方法占用的時間
Process： Android 2D渲染引擎執(zhí)行顯示列表所花的時間，View越多時間越長
Execute：將一幀圖像交給合成器（compsitor）的時間，較小 其他工具：
GameBench 測試android app的FPS工具
Gfxinfo 查看app繪制性能工具
1.6 響應時間篇理解：
1）從單擊事件觸發(fā)到容器啟動NativeAPP消耗的時間（埋點）
2）NativeAPP完整啟動消耗的時間（可以通過system.log獲?。?
3）Native調(diào)用RPC請求方法的延遲時間（埋點）
4）RPC請求發(fā)出去過程中的具體數(shù)據(jù)（req_size req_header req_time等，通過埋點獲?。?
5）RPC請求返回的具體數(shù)據(jù)（res_size res_header res_time等，通過埋點獲?。?
6）本地解析返回數(shù)據(jù)所消耗的時間（埋點或者TraceView工具可獲取）
7）界面渲染的時間（可以通過慢速攝像機或者埋點獲?。?/p> android app啟動時間測試
（安卓Activity啟動過程性能剖視: http://www./archives/59/） 應用的啟動時間的測試，分為三類：
1）首次啟動 --應用首次啟動所花費的時間
2）非首次啟動 --應用非首次啟動所花費的時間
3）應用界面切換--應用界面內(nèi)切換所花費的時間 應用啟動時間數(shù)據(jù)獲?。?
1、adb logcat > /address/logcat.txt #所有activity打印的日志
find “Displayed” /address/logcat.txt > /newaddress/fl.txt #通過日志過濾關(guān)鍵字Displayed來過濾
find “ActivityName” /newaddress/fl.txt > /newaddress/last.txt #通過activity名來過濾獲取所測應用
通過計算activity最后剩余的時間之和即可
2、硬件測試， 使用高速相機或者手機采用錄像的方法把應用啟動過程給錄制下來，然后通過人工數(shù)幀或者程序數(shù)幀的方式計算啟動時間
2 弱網(wǎng)測試測試方法：
1、使用真實的SIM卡、運營商網(wǎng)絡來進行測試（移動無線測試中存在一些特別的BUG必須在特定的真實的運營商網(wǎng)絡下才會發(fā)現(xiàn)）
2、通過代理的方式模擬弱網(wǎng)環(huán)境進行測試（charles 硬延遲）
3、連接模擬弱網(wǎng)的熱點進行測試 熱點模擬方法：
1）通過設(shè)置iPhone的開發(fā)者模式之后共享熱點（硬延遲）
2）FaceBook開源的ATC（可使用樹莓派來搭建ACT環(huán)境） 用戶體驗需要做的：
1）在應用中統(tǒng)一弱網(wǎng)加載的界面樣式、動畫效果、菊花icon等
2）統(tǒng)一網(wǎng)絡錯誤、服務端錯誤、超時等展現(xiàn)給用戶的界面和提示語句
3）定義清楚在每個中間過程是的用戶交互行為
|
