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.網路測試

①4G wifi 情況下功能正常
②無網測試，各頁面功能是否受影響。快取檔案是否能正常顯示，載入不出的頁面是否有提示
③網路切換，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。

15.外網與場景測試
主要是模擬客戶使用網路環境，檢驗客戶端程式在實際網路環境中使用情況及進行業務操作。外網測試主要覆蓋到wifi\3G\4G、net\wap、電信\移動\聯通，所有可能的組合進行測試。
原則：a.儘可能全面覆蓋使用者的使用場景，測試用例中需要包含不同網路排列組合的各種可能； b.模擬訊號被遮蔽時候，客戶端的影響等； c.做外部場景測試，在高山、丘陵、火車上等特殊環境下進行全面測試。

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埋點監控測試：如友盟