轉自：http://www.lxweimin.com/p/a2ee554869ef

1. 權限測試**

1)軟件權限　　-扣費風險：包括發送短信、撥打電話、連接網絡等　　-隱私泄露風險：包括訪問手機信息、訪問聯系人信息等　　-新增風險項

2)開發者官方權限列表信息比對分析

2.下載、安裝、運行、卸載測試**從市場下載app，驗證能否驗證App是否能 正常下載、正確安裝、運行、卸載，以及操作過程和操作前后對系統資源的使用情況，主要包括：

1).檢測軟件是否能正確安裝、運行、卸載；

2).安裝、卸載、更新錯誤報告；

3).其他輔助信息：

-位置和文件夾是否合理；

-組件是否正確注冊或刪除；

-評估操作前后，CPU、Memory（內存占用）、Storage（磁盤占用）等系統資源的使用情況。

3.UI測試

測試用戶界面(如菜單、對話框、窗口和其它可視控件)布局、風格是否滿足客戶要求，文字是否正確，頁面是否美觀，文字，圖片組合是否完美，操作是否友好等。

UI測試的目標是確保用戶界面會通過測試對象的功能來為用戶提供相應的訪問或瀏覽功能。確保用戶界面符合公司或行業的標準。包括用戶友好性、人性化、易操作性測試。

4.功能測試：根據軟件說明或用戶需求驗證App的各個功能實現，采用如下方法實現并評估功能測試過程：

1)采用時間、地點、對象、行為和背景五元素或業務分析等方法分析、提煉App的用戶使用場景，對比說明或需求，整理出內在、外在及非功能直接相關的需求，構建測試點，并明確測試標準（若用戶需求中無明確標準遵循，則需要參考行業或相關國際標準或規則）。

2)根據被測功能點的特性列舉出相應類型的測試用例對其進行覆蓋，如：涉及輸入的地方需要考慮等價、邊界、負面、異常或非法、場景回滾、關聯測試等測試類型對其進行覆蓋。

3)在測試實現的各個階段跟蹤測試實現與需求輸入的覆蓋情況，及時修正業務或需求理解錯誤。

5.性能測試評估App的時間和空間特性

1)極限測試：在各種邊界壓力情況下（如電池、存儲、網速等），驗證App是否能正確響應。

2)響應能力測試：測試App中的各類操作是否滿足用戶響應時間要求

3)壓力測試：反復/長期操作下，系統資源是否占用異常；

4)性能評估：評估典型用戶應用場景下，系統資源的使用情況。

5).基準性能測試：主要通過壓服務器端接口及客戶端在不同網絡環境下響應速度。

6).大數量的測試：主要在特定環境下，客戶端一次性更新大量的數據及人員列表時，客戶端能否正常處理，分為三種情況：

客戶端第一次使用，第一次就更新大量數據及人員列表。

客戶端在平時更新中，更新大量的數據

客戶端已經在手機本地下載很多數據后，再次更新大量

6.異常測試： 　針對智能終端應用的服務等級劃分方式及實時特性所提出的測試方法，如：App在前/后臺運行狀態時與來電、文件下載、音樂收聽等關鍵運用的交互情況測試等。

1).交互異常性測試：客戶端作為手機特性測試，包括被打擾的情況；如來電、來短信、低電量測試等，

還要注意手機端硬件上，如：待機，插拔數據線、耳機等操作不會影響客戶端。

2).異常性測試：主要包含了斷網、斷電、服務器異常等情況下，客戶端能否正常處理，保證數據正確性。

7.兼容測試主要測試內部和外部兼容性

1).與本地及主流App是否兼容；

2).檢驗在各種網絡連接下(WiFi、GSM、GPRS、EDGE、WCDMA、CDMA1x、CDMA2000、HSPDA等)，App的數據和運用是否正確；

3).與各種設備是否兼容（若有跨系統支持則需要檢驗是否在各系統下，各種行為是否一致）。

8.安全測試 ,安全測試顯得尤為重要，粗心、不謹慎的數據存儲或傳輸方式使得非法、惡意目的有可乘之機。

智能終端安全涉及各信息交互、存儲接點，借鑒于網絡傳輸和相關安全測試經驗，

App安全測試大概劃分為以下幾類：

1)從數據的本地存儲到數據的傳輸、處理以及遠程訪問等各個環節，基于相應的安全標準/行業標準評估App的安全特性；

2)借鑒在Web App和網絡安全測試的一些成功經驗在智能終端App測試中進行裁減或適配；

3)檢測App的用戶授權級別，數據泄漏，非法授權訪問等；

4)對App的輸入有效性校驗、認證、授權、敏感數據存儲、數據加密等方面進行檢測,以期發現潛在的安全問題；

5)基于各種通信協議或相應的行業安全標準檢視App是否滿足相應的要求

9.網絡測試, 相關的App，有三個非常重要的最佳實踐。

1)、 2G、3G、wifi都要覆蓋

這三者之間不僅僅只是網絡速度的差別，它們代表了三種不同的網絡環境。另外你可能沒有想到一種特殊的情況可以用它們來測出問題：開發環境和生產環境。

一個有經驗的開發團隊會在內網搭建測試環境來進行開發時的測試，在上線時將配置切換到線上的生產環境。這個切換應該是在發布流程中需要Check的一個環節。但是，我們有可能遺漏。

所以這個測試用例可以用來防止這種情況的出現，在wifi下內網環境可以work fine，但是2G和3G就不行，只有真實的環境下2G和3G才能正常工作（想想2G和3G是否可以正常訪問http://192.168.1.xxx這樣的地址就可以了）。

a.外網測試主要現實模擬客戶使用網絡環境，檢驗客戶單程序在實際網若環境中使用情況及進行業務操作。

b.外網測試主要覆蓋到wifi\2G\3G\4G ,.net\wap 、 電信\移動\聯通、所有可能的組合進行測試。

原則：

1.盡可能全面覆蓋用戶的使用場景，測試用例中需要包含不同網絡排列組合的各種可能。

2.還有模擬信號被屏蔽時候。客戶端的影響 等。還有做外包場景測試，在高山、丘陵、火車上等特殊環境下進行全面測試

2)、HTTP、HTTPS都要覆蓋

許多App和后臺服務都是通過HTTP來交互的，正常情況下都一切正常。為什么需要測試HTTPS環境？在一些免費上網的環境中，例如在麥當勞、星巴 克里，它們的網絡環境都要輸入用戶名和密碼，通過SSL認證來訪問網絡。如果你使用HTTP Client的library對這種異常沒有做捕獲處理，那么你的App必定會崩潰掉。

3)、進行網絡異常、服務器宕機或出現404、502等情況下的測試

后臺服務的穩定性是你有時很難去控制的，尤其是牽涉到DNS、空間服務商的情況下。國內某著名DNS服務商經常出現大規模域名解析故障，碰到這種情 況，你對后臺API的請求很可能就會出現404錯誤。而你和API交互的數據應該是某種固定格式例如JSON和XML，這樣你的數據解析必然會出現錯誤， 拋出異常。如果你對異常沒有進行正確的處理可能會導致程序不能正常工作。

以下用偽代碼解釋一下邏輯：

try {

if(request() == success) {

callSuccess();

} else {

callFail();

}

hidePopup();

} catch(e) {

// do nothing, just wait….now popup window will show forever on the screen!!!

// if it is a iOS app, the popup window will lock the screen

}

10.接口性測試：

1.client端和service端的交互

2.client端的數據更新和service端的數據是否一致

3.client端更新時斷開了。

4.client端更新時service端掛了。

11.業務邏輯測試：

1.業務邏輯測試：主要測試客戶端業務能否正常完成。

2.功能點測試：主要測試客戶端功能點是否正常使用

3.關聯性測試：主要測試客戶端與pc端的交互，客戶端處理完后，pc端與客戶端數據一致

12.移動App崩潰的測試場景

1 驗證在有不同的屏幕分辨率， 操作系統 和運營商的多個設備上的App行為。

2 用新發布的操作系統版本驗證App的行為。

3 驗證在如隧道，電梯等網絡質量突然改變的環境中的App行為。

4 通過手動網絡從蜂窩更改到Wi-Fi ，或反過來，驗證App行為。

5 驗證在沒有網絡的環境中的App行為。

6 驗證來電/短信和設備特定的警報（如警報和通知）時的App行為。

7 通過改變設備的方向，以不同的視圖模式，驗證App行為。

8 驗證設備內存不足時的App行為。

9 通過用測試工具施加載荷驗證App行為。

10 用不同的支持語言驗證App行為。

13.輸入項測試

1.植入的單引號。大多數基于SQL的數據庫系統在用戶存儲包含一個單引號的信息時會出現問題，例如John's car。每一個可以接受文字數字型數據條目的屏幕都要試試輸入包含一個或多個單引號的文本。

，其實不只是單引號，基本上測試人員應該測試所有的特殊字符和空/空格（單純的空格和文本前后的空格）。單引號，逗號，/，<， >（對于web的應用程序）都是很容易引發錯誤的。

2.必需輸入的數據條目。功能說明書上應該清楚的指出屏幕上必須輸入數據條目的字段。測試屏幕上每一個被說明為必須輸入的字段以保證它強制要求你在字段中輸入數據。

對于強制輸入的字段，在屏幕上最好有些標識以說明其為必須輸入的字段。一般在字段前或后用紅色的*號表示。測試時必須要檢查有標識的字段是否和功能說明書或其他參考文檔一致，錯誤信息提示是否正確，強制輸入的字段 是否真的必須輸入。

3.字段類型測試。功能說明書上應該清楚的指出要求特定數據輸入要求（日期字段，數字字段，電話號碼，郵編等等）的字段。測試屏幕上每一個被指出有特定類 型的字段以保證你輸入了基于字段類型的符合正確格式的數據（數字型字段應該不允許字符或特殊字符，日期型的字段應該允許輸入一個正確的日期等等）

其實這里還有一個字段格式和字段內容的測試。有些字段對輸入的格式有要求，這些字段的格式一般在屏幕上也有相應的提示。所以在測試時需要 測試提示的格式是否合理（和功能說明書或其他參考文檔相一致）以及系統是否正確識別輸入的格式。有些字段對字段的內容有限制，如常見的用戶名，不能包含特 殊字符，首字不能未數字等要求。所以在測試時需要測試提示的格式是否合理（和功能說明書或其他參考文檔相一致）還有不符合內容要求的數據輸入時系統是否正 確的處理。

4.字段長度測試。功能說明書上應該清楚的指出可以在字段中輸入的字符數（例如，first name必須是50個或更少的字符）。寫測試用例以保證你只可以輸入特定的字符數。防止用戶輸入比允許范圍更多的字符比因用戶已輸入過多的字符而給出的錯 誤信息更加的文雅些。

一般對于限制長度的字段，現在開發大多采用限制輸入的方法（設置字段的長度）來處理。所以測試時需要測試限制的長度是否合理（和功能說明 書或其他參考文檔相一致），對于沒有限制長度的字段，要測試無窮輸入時是否出錯，有問題報bug時建議開發人員根據需要限制長度。

5.數字型的邊界測試。對于數字型的字段，測試上下邊界是非常重要的。例如，如果你正在計算某個賬戶的利息時，你永遠不會輸入一個負的利息數給應該贏取利 息的賬戶。因此，你應該嘗試用負數測試。同樣，如果功能說明書上要求字段在某一個特定的范圍（如從10～50），你就應該嘗試輸入9或51，它應該給出一 個得體的信息表示失敗。

邊界值的測試同時，最好結合等價類以及一些特殊數字進行開展，如這里面的負數，雖然賬戶利息永遠不會出現負數，但是如果系統中一旦輸入負數，系統就崩潰，那么這樣的系統對于客戶來說也是非常危險的。

6.數字的約束測試。大多數數據庫系統和編程語言允許數字條目被識別為整數或長整數。通常，整數的范圍是從-32,767~32,767，長整數的范圍從 -2,147,483,648~2,147,483,647。對于那些沒有特定邊界限制的數字數據條目，用這些限制測試以確保不會出現數字的溢出錯誤。

小數型的數字字段同樣也需要格外的測試。一般對于未指出數字類型的字段，嘗試輸入負整數，負小數，0，正整數，正小數進行測試。

不管是哪種數據庫系統，對于數字一般都有多種數字類型。所以測試人員一定要測試的全面。

7.日期邊界測試。對于日期型的字段，測試上下邊界是很重要的。例如，如果你正在檢查一個出生日期的字段，很大可能出生日期不能早于150年前。同樣，出生日期應該不是將來的某一天。

一般來說，每種數據庫系統的日期都有個范圍，如SQL Server最小日期是1753年1月1日，所以如果是輸入型的日期字段同樣也應該測試早于1753的日期。

8.日期的有效性。對于日期字段，確保不允許無效的日期是很重要的（04/31/2007是一個無效的日期）。測試用例也應該檢查閏年（每個第4年和第400年是一個閏年）。

9.web會話測試。很多的web應用程序依賴瀏覽器的會話來追蹤已登錄的用戶，應用程序的設置等等。應用程序的大多數屏幕不被設計為沒有首次登錄就可以被運行。應用程序應該確保在打開應用程序的某一頁面之前會話里有一個有效的登錄。

14.app 功耗、流量測試:針對app對手機電量、流量方面損耗情況的測試

1.功耗測試主要測試app使用過程中耗費電量情況的測試，主要依據一些主流app的功耗作為對照參數

2.流量測試：檢測app對流量損耗問題，主要依據一些主流app的流量損耗作為對照參數