Android應用功能測試策略

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

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

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

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

1運行

1）App安裝完成後的試運行，可正常打開軟件。

2）App打開測試，是否有加載狀態進度提示。

3）App打開速度測試，速度是否可觀。

4）App頁面間的切換是否流暢，邏輯是否正確

2註冊

-- 同表單編輯頁面
-- 用戶名密碼長度
-- 註冊後的提示頁面
-- 前臺註冊頁面和後臺的管理頁面數據是否一致
-- 註冊後，在後臺管理中頁面提示

3登陸

-- 使用合法的用戶登陸系統。
-- 系統是否容許屢次非法的登錄，是否有次數限制。
-- 使用已經登錄的帳號登錄系統是否正確處理。
-- 使用禁用的帳號登錄系統是否正確處理。
-- 用戶名、口令（密碼）錯誤或漏填時可否登錄。
-- 刪除或修改後的用戶，原用戶登錄。
-- 不輸入用戶口令和用戶、重複點（肯定或取消按鈕）是否容許登錄。
-- 登錄後，頁面中登錄信息。
-- 頁面中有註銷按鈕。
-- 登錄超時的處理。

4註銷

-- 註銷原模塊，新的模塊系統可否正確處理。
-- 終止註銷可否返回原模塊，原用戶。
-- 註銷原用戶，新用戶系統可否正確處理。
-- 使用錯誤的帳號、口令、無權限的被禁用的帳號進行註銷

5應用的先後臺切換

1) APP 切換到後臺，再回到 app ，檢查是否停留在上一次操做界面。

2) APP 切換到後臺，再回到 app ，檢查功能及應用狀態是否正常， IOS4 和 IOS5 的版本的處理機制有的不同。

3) app 切換到後臺，再回到前臺時，注意程序是否崩潰，功能狀態是否正常，尤爲是對於從後臺切換回前臺數據有自動更新的時候。

4) 手機鎖屏解屏後進入 app 注意是否會崩潰，功能狀態是否正常，尤爲是對於從後臺切換回前臺數據有自動更新的時候。

5) 當 App 使用過程當中有電話進來中斷後再切換到 app ，功能狀態是否正常

6) 當殺掉 app 進程後，再開啓 app ， app 可否正常啓動。

7) 出現必須處理的提示框後，切換到後臺，再切換回來，檢查提示框是否還存在，有時候會出現應用自動跳過提示框的缺陷。

8) 對於有數據交換的頁面，每一個頁面都必須要進行先後臺切換、鎖屏的測試，這種頁面最容易出現崩潰。

6數據更新

根據應用的業務規則，以及數據更新量的狀況，來肯定最優的數據更新方案。

1) 須要肯定哪些地方須要提供手動刷新，哪些地方須要自動刷新，哪些地方須要手動 + 自動刷新。

2) 肯定哪些地方從後臺切換回前臺時須要進行數據更新。

3) 根據業務、速度及流量的合理分配，肯定哪些內容須要實時更新，哪些須要定時更新。

4) 肯定數據展現部分的處理邏輯，是每次從服務端請求，仍是有緩存到本地，這樣纔能有針對性的進行相應測試。

5) 檢查有數據交換的地方，均有相應的異常處理。

7 App更新

1) 當客戶端有新版本時，有更新提示。

2) 當版本爲非強制升級版時，用戶能夠取消更新，老版本能正常使用。用戶在下次啓動 app 時，仍能出現更新提示。

3) 當版本爲強制升級版時，當給出強制更新後用戶沒有作更新時，退出客戶端。下次啓動 app 時，仍出現強制升級提示。

4) 當客戶端有新版本時，在本地不刪除客戶端的狀況下，直接更新檢查是否能正常更新。

5) 當客戶端有新版本時，在本地不刪除客戶端的狀況下，檢查更新後的客戶端功能是不是新版本。

6) 當客戶端有新版本時，在本地不刪除客戶端的狀況下，檢查資源同名文件如圖片是否能正常更新成最新版本。若是以上沒法更新成功的，也都屬於缺陷。

TestBird