移動App專項測試

移動App測試實戰—專項測試

轉自：http://www.51testing.com/html/58/n-3713758.html

　　咱們在進行了手工的 功能測試以後，也開發了一些 自動化測試用例，而且作了 性能測試以後，測試 工做看似比較完整了。可是當咱們的App在大量的用戶那裏被安裝和使用的時候，仍是會有不少咱們以前沒有預料的問題被反饋回來，好比：

　　· Crash的問題

　　· 設備兼容性的問題

　　· 流量使用過多的問題

　　· App致使用戶 手機電量消耗過快的問題

　　· 在不一樣的網絡狀況下不穩定，好比卡死和白屏的問題

　　這些問題都是上面的測試方法難以找出的，因此這裏引入了一個專項的測試方法，包括：兼容性測試、流量測試、電量測試、弱網絡測試、穩定性測試、 安全測試和環境相關測試。

　 　第一：兼容性測試

　　針對App一般會考慮這些方面：

　　1） 操做系統版本

　　包括Andoird版本，iOS版本

　　2）屏幕分辨率

　　3）不一樣廠家的ROM

　　4) 網絡類型

　　好比Wifi、3G、4G下的功能狀況

　　 第二：流量測試

　　在 移動產品的測試中，頗有必要對App使用的流量進行度量，大體來講，流量能夠從用戶使用的的相關性角度分爲：一類是用戶的操做直接致使的流量消耗；另外一類是後臺，即在用戶沒有直接使用狀況下的流量消耗。

　　 第三：電量測試

　　在木器電池 技術沒有取得巨大突破前提下，這方面始終會存在一些瓶頸，若是一些App架構設計的很差，或者代碼偶缺陷，就可能致使電量消耗比較高，因此電量測試也是很重要的。

　 　第四：弱網絡測試

　　 移動互聯網產品相比PC互聯網產品，有一個特色是前者使用的網絡比較多樣，除了Wif以外，不少時候是在移動網絡下使用的，移動網絡遇到的狀況又比較複雜，好比地鐵、隧道、體育場等。因此網絡不穩定的狀況是比較容易發生的，不少狀況下App的一些問題是在複雜的網絡狀況下才會暴露，與其讓用戶發現和投訴這些問題，不如咱們在測試階段儘可能模擬這樣的網絡狀況，及早發現和修復這些問題。

　　 第五：穩定性測試

　　在保證基本功能正確基礎之上，App的穩定性就顯得很是重要，若是一個App常常出現閃退或者卡死，那麼用戶體驗就會受到很大傷害，在有其餘競爭產品的狀況下很容易形成用戶的流失。

　　 第六：安全測試

　　包括安裝包的安全測試（可否反編譯代碼、安裝包是否簽名等）、敏感信息測試、軟鍵盤劫持、帳戶安全、數據通訊安全等。服務器端的 SQL注入測試、XSS跨站腳本攻擊等。

　　 第七：環境相關的測試

　　在實際項目中，有一些缺陷我發現是和App所處的運行環境相關的，因此設計測試的時候，要多考慮這些場景，好比：

　 　1）干擾測試

　　收到 電話、收到 短信、收到通知欄消息、無電提示框彈出、第三方安全軟件告警彈出。

　　2）權限測試

　　一些用戶在實際使用App的時候回有意識阻止某些功能。例若有的用戶感受讓某個App訪問電話本或者相冊可能泄漏隱私，就在手機中設置了禁止了該App訪問相冊的權限。

　　3）邊界測試

　　手機環境自己也有其邊界狀況須要在測試中覆蓋。常見的場景有：

　　可用存儲空間過少、沒有SD卡/雙SD卡、飛行模式、系統時間有誤（晚於和早於標準時間）、第三方依賴（好比咱們的App依賴第三方App，可是如今第三方App沒有安裝或者版本太低的測試狀況）。

 

-------------------------------------------------華麗的分割線-----------------------------------------------------------------

Android APP性能及專項測試

 

• Android性能測試分爲兩類： 
  一、一類爲rom版本（系統）的性能測試 
  二、一類爲應用app的性能測試

• Android的app性能測試包括的測試項好比： 
  一、資源消耗 
  二、內存泄露 
  三、電量功耗 
  四、耗時 
  五、網絡流量消耗 
  六、移動終端相關資源利用率 
  七、幀率 
  八、渲染等等....

• 工具： 
  （工具的原理都是基於調用android底層的一些api來獲取到測試所用到的值）GT等

• 測試方法： 
  一、設計場景 ：手工或自動化場景 
  二、獲取數據：可獲取的數據包括：內存、cpu、電量功耗、hprof（內存泄露分析文件）、響應時間等等。。。。配合手工或自動化場景來獲取數據（最好多取幾回並且每次配合不一樣的設備看平均值）做爲最後的對比分析 
  三、結果分析 ：拿到數據後分析哪些模塊的數據異常再去Check code定位問題的緣由

• Android系統的幾種場景狀態： 
  一、空閒狀態： 指打開應用後，點擊home鍵讓應用後臺運行，此時應用處於的狀態叫作空閒 
  二、中等規格和滿規格狀態：中等規格和滿規格指的是對應用的操做時間的間隔長短不一，中等規格時間較長，滿規格時間較短

1.1 內存篇

背景知識： 
C/C++申請的內存空間在native heap中，而java申請的內存空間則在dalvik heap中。這個是由於Android系統對dalvik的vmheapsize做了硬性限制，當java進程申請的java空間超過閾值時，就會拋出OOM異常（這個閾值能夠是48M、24M、16M等，視機型而定），能夠經過adb shell getprop | grep dalvik.vm.heapgrowthlimit查看此值。也就是說，程序發生OMM並不表示RAM不足，而是由於程序申請的java heap對象超過了dalvik vmheapgrowthlimit。也就是說，在RAM充足的狀況下，也可能發生OOM。

這樣的設計彷佛有些不合理，可是Google爲何這樣作呢？這樣設計的目的是爲了讓Android系統能同時讓比較多的進程常駐內存，這樣程序啓動時就不用每次都從新加載到內存，可以給用戶更快的響應。迫使每一個應用程序使用較小的內存，移動設備很是有限的RAM就能使比較多的app常駐其中。可是有一些大型應用程序是沒法忍受vmheapgrowthlimit的限制的

實際上dalvik.vm.heapgrowthlimit和dalvik.vm.heapsize都是java虛擬機的最大內存限制，應用若是不想在dalvikheap達到heapgrowthlimit限制的時候出現OOM，須要在Manifest中的application標籤中聲明android：largeHeap=「true」，聲明後應用dalvik heap達到heapsize的時候纔會出現OOM

1. 內存測試中的測試子項： 
   1）空閒狀態下的應用內存消耗狀況 
   2）中等規格狀態下的應用內存消耗狀況 
   3）滿規格狀態下的應用內存消耗狀況 
   4）應用內存峯值狀況 
   5）應用內存泄露狀況 
   6）應用是否常駐內存 
   7）壓力測試後的內存使用狀況

2. 內存問題現象： 
   1）內存抖動 
   2）大內存對象被分配 
   3）內存不斷增加 
   4）頻繁GC

3. 內存數據獲取： 
   一、各類linux命令（top、free、meminfo…） 
   二、經過dumpsys 
   adb shell dumpsys meminfo [pakagename | pid] 
   三、經過/system/xbin/procrank工具 
   adb shell procrank 
   說明： 
   VSS – Virtual Set Size 虛擬耗用內存（包含共享庫佔用的內存） 
   RSS – Resident Set Size 實際使用物理內存（包含共享庫佔用的內存） 
   PSS – Proportional Set Size 實際使用的物理內存（比例分配共享庫佔用的內存） 
   USS – Unique Set Size 進程獨自佔用的物理內存（不包含共享庫佔用的內存） USS 是針對某個進程開始有可疑內存泄露的狀況，是一個程序啓動了會產生的虛擬內存，一旦這個程序進程殺掉就會釋放。不過USS須要經過root的手機。通常沒有root的手機咱們能夠獲取PSS。而PSS經過以下命令來獲取：adb shell dumpsys meminfo <Package Name>|grep TOTAL 
   四、經過android提供的procrank 
   1）首先去google獲取procrank、procmem、libpagemap.so三個文件 
   2）而後push文件，執行 adb push procrank /system/xbin adb push procmem 
   /system/xbin adb push libpagemap.so /system/lib 
   3）賦權 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 
   五、經過android提供的ActivityManager的getMemoryInfo(ActivityManager.MemoryInfo outInfo)（這個方法是寫一個簡單的app去監控的時候用到的，輕便簡單）

1. privatevoidGetMemory()
2. {
3. finalActivityManager activityManager =(ActivityManager) getSystemService(ACTIVITY_SERVICE);
4. ActivityManager.MemoryInfo info =newActivityManager.MemoryInfo();
5. activityManager.getMemoryInfo(info);
6. Log.i(tag,"系統剩餘內存:"+(info.availMem >>10)+"k");
7. Log.i(tag,"系統是否處於低內存運行："+info.lowMemory);
8. Log.i(tag,"當系統剩餘內存低於"+info.threshold+"時就當作低內存運行");
9. }

六、Memory  Monitor （android studio的插件）  【makedown？？？】

4. /proc/meminfo文件裏列出的字段解釋： 

MemTotal: 全部可用RAM大小。 MemFree: LowFree與HighFree的總和，被系統留着未使用的內存。 
Buffers: 用來給文件作緩衝大小。 Cached: 被高速緩衝存儲器（cache memory）用的內存的大小（等於diskcache 
minus SwapCache）。 SwapCached:被高速緩衝存儲器（cache 
memory）用的交換空間的大小。已經被交換出來的內存，仍然被存放在swapfile中，用來在須要的時候很快的被替換而不須要再次打開I/O端口。 
Active: 在活躍使用中的緩衝或高速緩衝存儲器頁面文件的大小，除非很是必要，不然不會被移做他用。 Inactive: 
在不常用中的緩衝或高速緩衝存儲器頁面文件的大小，可能被用於其餘途徑。 SwapTotal: 交換空間的總大小。 SwapFree: 
未被使用交換空間的大小。 Dirty: 等待被寫回到磁盤的內存大小。 Writeback: 正在被寫回到磁盤的內存大小。 
AnonPages：未映射頁的內存大小。 Mapped: 設備和文件等映射的大小。 Slab: 
內核數據結構緩存的大小，能夠減小申請和釋放內存帶來的消耗。 SReclaimable:可收回Slab的大小。 
SUnreclaim：不可收回Slab的大小（SUnreclaim+SReclaimable＝Slab）。 
PageTables：管理內存分頁頁面的索引表的大小。 NFS_Unstable:不穩定頁表的大小。

5. android檢查內存泄露步驟： 

一、運行Monkey進行壓力測試： 
adb shell monkey -p cn.microinvestment.weitou --pct-touch 100 --ingore-crashes --throttle 1000 -s 100 -v -v 50
二、監控內存值，若是出現過大等遞增異常則保存HPROF文件（hprof文件是Java 虛擬機的Heap快照）用於分析查看應用內存的命令： 
adb shell dumpsys meminfo cn.microinvestment.weitou(進程名) 
若是發現內存過大，則保存HPROF文件：adb shell am dumpheap <進程名> <保存路徑> 
三、分析hprof文件 
用工具MAT來查看，首先還要這個HPROF文件轉換成MAT可讀的文件 
在Android SDK tool裏面有個hprof-conv命令： 
hprof-conv <原HPROF文件路徑> <轉換後的HPROF路徑> 
hprof-conv a.hprof b.hprof 
四、用MAT工具打開轉換後的HPROF文件 
通常選擇Leak Suspects Report（經過SQL語句來查詢對象有沒有被釋放掉，若是有多個相同的對象，則會存在內存泄露的問題）

1.2 CPU篇

1. CPU測試中的測試子項： 
   1）空閒狀態下的應用CPU消耗狀況 
   2）中等規格狀態下的應用CPU消耗狀況 
   3）滿規格狀態下的應用CPU消耗狀況 
   4）應用CPU峯值狀況

2. CPU數據獲取： 
   1）adb shell dumpsys cpuinfo | grep packagename 
   2)top命令 
   adb shell top -m 10 -s cpu #查看佔用cpu最高的前10個程序（-t 顯示進程名稱，-s 按指定行排序，-n 在退出前刷新幾回，-d 刷新間隔，-m 顯示最大數量） 
   adb shell top | grep PackageName > /address/cpu.txt

1.3 流量篇

1. 概念： 
   中等負荷：應用正常操做 
   高負荷：應用極限操做

2. 流量測試中的測試子項： 
   一、應用首次啓動流量值 
   二、應用後臺連續運行 2 小時的流量值 
   三、應用高負荷運行的流量峯值 
   四、應用中等負荷運行時的流量均值

3. 獲取流量數據： 
   一、tcpdump＋wireshark 
   二、/proc/net/目錄下相關文件 
   cat /proc/net/dev 獲取系統的流量信息 
   三、查詢應用的pid： adb shell ps | grep tataufo #如：31002 
   經過PID獲取該應用的流量數據： adb shell cat /proc/31002/net/dev 
   （wlan0表明wifi上傳下載量標識, 單位是字節能夠/1024換算成KB, 打開手機飛行模式再關掉就能夠將wlan0中的值初始化0） 
   四、查詢應用的pid： adb shell ps | grep tataufo #如：31002 
   經過PID獲取UID：adb shell cat /proc//status 
   經過UID獲取：adb shell cat /proc/net/xt_qtaguid/stats | grep 31002 
   五、經過adb shell dumpsys package來獲取應用的uid信息，而後在未操做應用以前，經過查看 ： 
   adb shell cat /proc/uid_stat/uid/tcp_rcv 
   adb shell cat /proc/uid_stat/uid/tcp_snd 
   獲取到應用的起始的接收及發送的流量，而後咱們再操做應用，再次經過上述2條命令能夠獲取到應用的結束的接收及發送的流量，經過相減及獲得應用的總體流量消耗 
   六、Android代碼：Android的TrafficStats類

1.4 功耗篇

1. 功耗測試中的測試子項： 
   一、手機安裝目標APK先後待機功耗無明顯差別 
   二、常見使用場景中可以正常進入待機，待機電流在正常範圍內 
   三、長時間連續使用應用無異常耗電現象

2. 功耗測試方法： 
   方法一：軟件 
   一、採用市場上提供的第三方工具，如金山電池管家之類的。 
   二、就是自寫工具進行，這裏通常會使用3種方法： 
   1）基於android提供的PowerManager.WakeLock來進行 
   2）比較複雜一點，功耗的計算=CPU消耗+Wake lock消耗+數據傳輸消耗+GPS消耗+Wi-Fi鏈接消耗 
   3）經過 adb shell dumpsys battery來獲取 
   三、battery-historian（google開源工具） 
   方法二：硬件 
   通常使用萬用表或者功耗儀安捷倫進行測試，使用功耗儀測試的時候，須要製做假電池來進行的，有些不能拔插電池的手機還須要焊接才能進行功耗測試

1.5 GPU篇（FPS）

1. 概念： 
   過分繪製： 界面顯示的activity套接了多層而致使 
   幀率：屏幕滑動幀速率 
   幀方差： 屏幕滑動平滑度 
   **FPS：**Frames Per Second 每秒顯示的幀數 根據人眼的生理結構，幀率高於24時就被認爲是連貫的。對於遊戲畫面30fps是最低能接受的，60fps逼真感，若是幀率高於屏幕刷新頻率就是浪費。要達到30fps，每幀所佔用的時間要小於33毫秒

2. GPU測試中的測試子項： 
   一、界面過分繪製 
   二、屏幕滑動幀速率 
   三、屏幕滑動平滑度

3. 過分繪製測試：（人工進行測試） 
   打開開發者選項中的顯示GPU過分繪製（Debug GPU overdraw） 
   驗收的標準: 
   一、不容許出現黑色像素 
   二、不容許存在4x過分繪製 
   三、不容許存在面積超過屏幕1/4區域的3x過分繪製（淡紅色區域）

4. 屏幕滑動幀速率測試： 
   方法一： 
   1.手機端打開開發者選項中的啓用跟蹤後勾選Graphics和View 
   2.啓動SDK工具Systrace，勾選被測應用，點擊Systrace，在彈出的對話框中設置持續抓取時間，在trace taps下面勾選gfx及view選項 
   3.手工滑動界面能夠經過節拍來進行滑動或者掃動，幀率數據會保存到默認路徑下，默認名稱爲trace.html 
   4.將trace.html文件拷貝到linux系統下經過命令進行轉換，生成trace.csv文件 
   grep 'postFramebuffer' trace.html | sed -e 's/.]\W//g' -e 's/:.*$//g' -e 's/.//g' > trace.csv 
   5.用excel打開文件計算獲得幀率 
   方法二： 
   硬件的方法，打開高速相機，開啓攝像模式，錄製手工滑動或者掃動被測應用的視頻，再經過人工或者程序數幀的方法對結果進行計算獲得幀率

5. 屏幕滑動平滑度的測試： 
   方法如同幀率測試，惟一的差別就是最後的結果計算公式的差別

6. 捕獲app幀率（android流暢度FPS測試）： 
   一、打開手機開發者選項，勾選GPU顯示配置文件（系統會記錄保留每一個界面最後128幀圖像繪製的相關時間信息） 
   二、adb shell dumpsys gfxinfo com.xxx.xxx > zinfo.txt 
   三、結果數據分析 
   Profile data in ms部分： 
   Draw： 建立顯示列表的時間（DisplayList），全部View對象OnDraw方法佔用的時間 
   Process： Android 2D渲染引擎執行顯示列表所花的時間，View越多時間越長 
   Execute：將一幀圖像交給合成器（compsitor）的時間，較小

7. 其餘工具： 
   GameBench 測試android app的FPS工具 
   Gfxinfo 查看app繪製性能工具

1.6 響應時間篇

1. 理解： 
   1）從單擊事件觸發到容器啓動NativeAPP消耗的時間（埋點） 
   2）NativeAPP完整啓動消耗的時間（能夠經過system.log獲取） 
   3）Native調用RPC請求方法的延遲時間（埋點） 
   4）RPC請求發出去過程當中的具體數據（req_size req_header req_time等，經過埋點獲取） 
   5）RPC請求返回的具體數據（res_size res_header res_time等，經過埋點獲取） 
   6）本地解析返回數據所消耗的時間（埋點或者TraceView工具可獲取） 
   7）界面渲染的時間（能夠經過慢速攝像機或者埋點獲取）

2. android app啓動時間測試 
   （安卓Activity啓動過程性能剖視: http://www.rudy-yuan.net/archives/59/）

3. 應用的啓動時間的測試，分爲三類： 
   1）首次啓動 --應用首次啓動所花費的時間 
   2）非首次啓動 --應用非首次啓動所花費的時間 
   3）應用界面切換--應用界面內切換所花費的時間

4. 應用啓動時間數據獲取： 
   一、adb logcat > /address/logcat.txt #全部activity打印的日誌 
   find 「Displayed」 /address/logcat.txt > /newaddress/fl.txt #經過日誌過濾關鍵字Displayed來過濾 
   find 「ActivityName」 /newaddress/fl.txt > /newaddress/last.txt #經過activity名來過濾獲取所測應用 
   經過計算activity最後剩餘的時間之和便可 
   二、硬件測試， 使用高速相機或者手機採用錄像的方法把應用啓動過程給錄製下來，而後經過人工數幀或者程序數幀的方式計算啓動時間

2 弱網測試

1. 測試方法： 
   一、使用真實的SIM卡、運營商網絡來進行測試（移動無線測試中存在一些特別的BUG必須在特定的真實的運營商網絡下才會發現） 
   二、經過代理的方式模擬弱網環境進行測試（charles 硬延遲） 
   三、鏈接模擬弱網的熱點進行測試

2. 熱點模擬方法： 
   1）經過設置iPhone的開發者模式以後共享熱點（硬延遲） 
   2）FaceBook開源的ATC（可以使用樹莓派來搭建ACT環境）

3. 用戶體驗須要作的： 
   1）在應用中統一弱網加載的界面樣式、動畫效果、菊花icon等 
   2）統一網絡錯誤、服務端錯誤、超時等展示給用戶的界面和提示語句 
   3）定義清楚在每一箇中間過程是的用戶交互行爲

4. 轉自：https://www.zybuluo.com/defias/note/592309