移動APP的測試與傳統的軟件測試稍微有些區別。
閱讀目錄
- 移動App比PC上的程序測試要復雜
- 移動App測試中如何設計Test Case
- 讓自己成為真實的用戶
- 關注用戶體驗測試
- 少做UI自動化，多做后台接口的自動化
- 測試你最終要發布給用戶的APP版本
- HTTP，HTTPS都要覆蓋
- 進行網絡異常，服務器宕機或出現404，502情況下的測試
- AppStore 冗長的審核機制
移動App比PC 上的程序測試要復雜
各種兼容性，多種分辨率， 多種異常情況。 會讓移動APP上的測試更復雜。
移動APP測試中如何設計Test Case
移動互聯網開發節奏很快，而且版本快速迭代， 建議完全放棄傳統的Tese Case, 不需要寫詳細的測試用例。 而采用feature list.
比如使用思維導圖工具+功能點 的方法。 這樣能節省大量的時間。 而且思維導圖比較直觀，不容易漏掉功能。
讓自己成為真實的用戶
大部分移動APP都是面向普通用戶的，而不是企業用戶。 要讓自己成為APP的真實用戶， 這樣徹底了解業務邏輯，
關注用戶體驗測試
用戶體驗式APP成功的關鍵， 在這么小的屏幕上，用戶體驗關系着用戶對APP的滿意度
少做UI自動化，多做后台接口的自動化
UI自動化大部分的時候，都沒什么意義，投入大，收入少。 應該多關注后台借口的自動化測試
重要的原則： 測試你最終要發布給用戶的APP版本
每日構建，每日測試的理念已經深入人心， 很多時候我們測試的是App的開發和Debug版本。 而不是最終的Release版本， 在打包最終的Release版本時。 我們一般還要加上數字簽名，或者再加上代碼混淆。那么最終的發布版本和Debug的版本肯定有不一致的地方。 很可能最終的版本會有問題。 比如Debug版本是完全工作正常，但是上線后才發現會導致奔潰
HTTP，HTTPS都要覆蓋
許多App和后台服務都是通過HTTP來交互的，正常情況下都一切正常，為什么需要測試HTTPS環境？ 一些免費上網的環境中，比如，麥當勞，萬達商城，他們的網絡環境都需要輸入用戶名和密碼，通過SSL認證來訪問網絡。 如果你使用HTTP Client 的Library對這種異常沒有做捕獲處理，那么你的APP，肯定要奔潰。
進行網絡異常，服務器宕機或出現404，502情況下的測試。
后台服務的穩定性是你有時候很難去控制的，尤其是牽扯到DNS，空間服務商的情況下。 如果出現DNS解析故障，碰到這種情況，你對后台API的請求很可能就會出現404錯誤， 而你和API交互的數據應該是某種固定格式例如JSON和XML，這樣你的數據解析比如會出現錯誤，拋出異常。如果你對異常沒有進行正確的處理可能會導致程序不能正常工作。
2G,3G,4G wifi 都要覆蓋
這四者之間不僅僅是網絡速度的差別， 它們代表了不同的網絡環境。 經常會有些APP能在3G網絡下運行，但是不能在wifi下運行。所以在需要check在不同的網絡環境。
AppStore 冗長的審核機制
一旦你的應用出現嚴重系統錯誤， 你修復版本基本不可能在很短時間內在App Store上架。 那么你的用戶就會離去。