移動APP測試方法

1.業務邏輯測試

業務邏輯測試：主要測試客戶端業務可否正常完成
功能點測試：主要測試客戶端功能點是否正常使用
關聯性測試：主要測試客戶端與PC端的交互，客戶端處理完後，PC端與客戶端數據一致

2.兼容性測試

針對App一般會考慮這些方面： ①操做系統版本 包括Andoird版本，安卓系統， 手機：華爲、小米、oppo、魅族等主流手機，各系統須要兼容到的版本，4-5.0以上，以產品的須要適配的版本爲主。 iOS版本 ，ios系統 手機：6，6s，6p，7，7P，8，8P，X 版本：ios9-11 ②屏幕分辨率 android 800*480, 960*640,1280*720(720p),1920*1080(1080p),2560*1440(2k). 對於iOS,考慮最近幾代機型對應的分辨率便可.

解決方案：
a.自行購買或者使用借來設備來實際驗證。耗費資金，購買幾臺。
b.第三方雲測試的解決方法。
c.整理不兼容的地方，而後去分析app總可能不兼容的代碼。對技術能力的要求比較高，前期也須要花費很多的時間。
d.利用友盟等第三方統計平臺得到應用對應的TOP N 的記性重點進行測試。

 

  3.流量測試和電量測試

    手機的電量及流量測試主要是爲了站在用戶角度思考，畢竟電量、流量消耗比較大，會影響客戶的使用感覺。手機端量使用是和CPU使用率成正比的。因爲這個沒有比較詳細的規定，只能出一個通用範圍。CPU使用率不能超過10%以上，流量不要超過10M以上。通常經過android手機端一些監控軟件獲取數據。固然也能夠經過代碼打點獲取。
 若是一些app架構設計的很差，或者代碼有缺陷，就可能致使電量消耗比較高。

 流量：一類是用戶的操做直接致使的流量消耗；另外一類是app在後臺運行時的流量消耗 （一）流量的測試方法 手機抓包或者wifi代理（Fiddler， Charles）。 （二）常見的流量節省方法 ①數據壓縮。壓縮包含接口文本數據的壓縮，js文件的壓縮及圖片的壓縮。 ②不一樣數據格式的採用。例如採用JSON格式做爲接口數據返回格式一般比XML格式要小。 ③只獲取必要的數據。有時候APP一頁的內容很是多，而用戶可能只會看一部分，過多的從後臺拉去數據就是浪費，因此能夠採用分屏加載或者懶加載的方式來減小流量消耗。 ④緩存。可將圖片，js等數據暫存起來，但因爲手機存儲空間有限，也須要控制整個緩存大小，並給用戶提供清理緩存的選項。

 

    手機電量測試
a.利用硬件設備：好比耗電量測試儀
b.第三方軟件來檢測：手機自帶電量監控、360助手、GT等
c.命令方式（5.0以上版本）
    //初始化batterystats數據
    adb shell dumpsys batterystats --reset
    //獲得整個設備的電量消耗信息
    adb shell dumpsys batterys > /storage/sdcard0/Download/b1.txt
    //獲得指定app相關的電量消耗信息
    adb shell dumpsys batterystats 包名 > /storage/sdcard0/Download/b1.txt
    
    測試流量
流量分兩種：a.操做app b.不操做app
測試方法：
a.各種雲測平臺、DDMS的Network
b.命令（模擬器不支持，某些真機不支持）
    ps | grep com.android.browser 獲取pid
    cat /proc/pid/status 獲取uid
    cat /proc/uid_stat/uid/tcp_snd 發送的流量byte
    cat /proc/uid_stat/uid/tcp_rcv 接受的流量byte
c.android自帶api
    long uidrx=TrafficStats.getUidRxBytes(10053); //10053表示uid
d.抓包（最好用root真機練習）
    經過tcpdump抓包，再經過wireshark直接讀取報信息來獲取流量

   4.弱網絡測試【fiddler工具】

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

 

（一）工具：
fiddler工具，原理：經過延遲發送數據或接收的數據的時間來限制網絡的下載速度和上傳速度，從而達到限速的效果。
方法：Rules > Performances > Simulate Modem Speeds 
 
也許Fiddler的低速已經超出你的忍耐程度了，那麼，可使用腳本從新定義一下低速網絡
1. 打開腳本編輯器：Rules > Customize Rules
2. 搜索m_SimulateModem，
3. 而後根據本身的須要修改以下語句 oSession[「request-trickle-delay」 ] = 「300」；（每上傳1KB延遲300ms）
oSession[「response-trickle-delay」 ] = 「150」；（每下載1KB延遲150ms）
點擊Save Script後，以前勾選的Simulate Modem Speeds會被取消勾選，須要從新再勾選回來。
（二）弱網測試關注的測試點：
①響應時間，5s或者更長時間未響應時報錯信息。用戶能忍受的最佳響應時間是2s，對不一樣的網絡機制是否設置不一樣的響應時間
②加載圖標。頁面一致處於loading狀態，仍是有進度條告訴用戶目前正在加載狀態
③異常的反饋   超時時提示

5.網絡測試

①要是模擬客戶使用網絡環境，檢驗客戶端程序在實際網絡環境中使用狀況及進行業務操做。外網測試主要覆蓋到wifi\3G\4G、net\wap、電信\移動\聯通，全部可能的組合進行測試，功能是否正常
②無網測試，各頁面功能是否受影響。緩存文件是否能正常顯示，加載不出的頁面是否有提示 
③網絡切換，app是否功能正常，是否有閃退卡死的狀況

6.穩定性測試

App常常出現閃退或者卡死，影響用戶體驗，形成用戶流失

7.安全測試

①包括安裝包的安全測試（可否反編譯代碼、安裝包是否簽名，完整性校驗，權限設置檢查等）
②敏感信息測試（數據庫，日誌，配置文件），接入風控，敏感字敏感圖片攔截。
③軟鍵盤劫持（金融類APP登陸頁面的用戶名密碼輸入框）、
帳戶安全（密碼是否明文，密碼傳輸是否加密，帳戶輸入錯誤次數過多鎖定，同時會話提醒， 註銷機制）數據通訊安全（關鍵數據是否散列或加密，關鍵鏈接是否使用安全通訊，是否對數字證書合法性進行驗證，是否校驗數據合法性。
④組件安全測試。
⑤服務器端接口測試（SQL注入測試、XSS跨站腳本攻擊， CSRF跨站請求僞造，越權訪問等）。

8.環境相關的測試

①干擾測試。收到電話、收到短信、收到通知欄消息、無電提示框彈出、第三方安全軟件告警彈出。
②權限測試。一些用戶在實際使用App的時候回有意識阻止某些功能。例若有的用戶感受讓某個App訪問電話本或者相冊可能泄漏隱私，就在手機中設置了禁止了該App訪問相冊的權限。
③邊界測試
手機環境自己也有其邊界狀況須要在測試中覆蓋。常見的場景有：
可用存儲空間過少、沒有SD卡/雙SD卡、飛行模式、系統時間有誤（晚於和早於標準時間）、第三方依賴（好比咱們的App依賴第三方App，可是如今第三方App沒有安裝或者版本太低的測試狀況）。
④Android定位測試。用白盒方式模擬
⑤斷網、斷電、服務器異常等狀況下，客戶端可否正常處理，保證數據正常性。

9.升級測試

（一）正常的下載升級過程
①考慮iOS和安卓的下載渠道不一樣。iOS的下載來自於AppStore，Android的升級來自於官網下載或者是各個渠道。
②考慮網絡的影響。2G/3G/4Gwifi下是否都能正常升級或者可以基於流量的影響進行智能下載
③考慮中斷下載和升級過程後是否會繼續或者從新下載和升級。手動中斷後能夠繼續進行相關操做
④考慮斷電和內存不足的問題。可以繼續進行相關升級，對於內存有友好的提示
⑤考慮應用權限問題。若是新版本對於應用權限有了擴展，須要進行權限確認
⑥考慮不一樣機型。升級測試須要對各類機型進行覆蓋測試
（二）升級後舊版本的兼容性
①新舊版本並行時後臺接口的兼容性。
②在進行舊版本功能兼容性驗證時，能夠進行主要流程的測試和變動的接口影響到的功能詳細驗證，這樣能夠縮小測試範圍
（三）覆蓋升級後新版本的使用狀況
①除了新版本自身的新功能驗證以外，要進行主要業務流程的驗證。
②在覆蓋升級前，須要模擬使用舊版本的用戶進行緩存數據的建立，而後進行升級，確認緩存數據升級後能夠正常顯示，相關功能工做正常。

在線升級測試
測試點：a.驗證數字簽名 b.升級後能夠正常使用 c.在線跨版本升級 

10.安裝和卸載測試

主要針對編譯後源程序生成的APK安裝文件。
主要測試點：a.生成的APK文件在真機上能夠安裝及卸載；
b.Android手機端的通用安裝工具，如：豌豆莢及91助手等工具能夠正常安裝及卸載程序。

11.交互性測試

客戶端做爲手機特性測試，包含被打擾的狀況13種，來電，來短信，低電量測試等，還要注意手機端硬件上，如：待機，插拔數據線，耳機等操做不會影響客戶端。

12.易用性測試

界面與交互性測試：符合android交互規範，符合用戶使用習慣，操做方便簡單，具備一致性。
可用性測試：用戶體驗好，用戶操做方便，用戶使用錯誤率低。

13.客戶端側性能測試 偏重客戶端側CPU、MEM、流量、電量以及客戶端在不一樣網絡環境下響應速度等等。 大數據的測試：主要在特定環境下，客戶端一次性更新大量的數據，客戶端可否正常處理，分爲三種狀況： a.客戶端第一次使用，更新大量數據 b.客戶端在平時更新中，更新大量的數據 c.客戶端已經在手機本地下載不少數據後，再次更新大量數據。 14.內存泄漏測試 OutOfMemory。 16.APP性能測試分類 客戶端：     a.應用測試（關注CPU、MEM、流量、GPU等）     b.ROM測試     c.其餘（web頁面，如今APP大多都是web頁面） 服務器端：性能測試方法和WEB差很少 tips：客戶端的測試其實比較推薦專用的硬件設備來，這樣測出的數據更加準確，好比高速相機、功耗儀等 17.APP自動化測試分類 UI(robotium、Appium等) 接口 單元（junit、Robolectric等） 持續集成 tips：一句話，對編程要求高，邏輯性思惟要求高 18.測試啓動時間 a.代碼裏插入時間並打印Log.e b.命令方式     adb shell     am start -W -n 包名/activity名     -W是指啓動完成以後，返回啓動耗時 c.秒錶、高速相機 d.adb logcat     adb logcat >d:\log.txt     啓動應用，待加載完成後ctrl+c中止     find "Displayed" d:\log.txt>d:\log1.txt     find "包名" d:\log1.txt>d:]log2.txt 19.代碼靜態掃描 代碼掃描工具Lint，它能很是容易得幫米找出代碼上的結構問題 具體的檢察規則能夠自定義（局部，全局） lint --list 得到檢查項id和簡要說明 lint --show xxx 得到詳細說明 jenkins：持續版本構建，與lint搭配使用 lint:檢查已有規則規範 findbugs：針對java平臺代碼的檢查 20.traceview 手機root，代碼中埋點，加SD卡讀寫權限。經過monitor.bat打卡.trace文件。 Debug.startMethodTracing("路徑"); //在oncreate方法中，開始埋點
Debug.stopMethodTracing(); //ondestroy中，結束
21.GPU 經過開發者模式-》顯示GPU過分繪製 22.CPU a.第三方工具、各種雲測平臺 b.dumpsys命令     adb shell dumpsys cpuinfo | grep com.android.browser > /storage/sdcard0/Download/cpu.txt c.top命令     adb shell top | grep com.android.browser > /storage/sdcard0/Download/cpu.txt tips：關注活動狀態和靜默狀態下的狀況 23.線上監控的方法 a.第三方的標準化的開源、商業產品，如Nagios、zabbix、Ganglia、百度統計等 b.自主研發的監控手機平臺 c.APM，好比聽雲 d.用戶反饋 app埋點監控測試：如友盟