我在面試測試工程師時，經常問到的一個問題是“給出Word另存為這個功能的測試用例”。除開基本的測試用例外，考慮到各種異常情況，例如內存已滿、硬盤空間不足是非常重要的。但是針對移動互聯網App來說，情況還要復雜的多。
一個重要原則是：測試你最終要發布給用戶的App版本。
可能每日構建、每日測試的理念已經深入人心，我們很多時候測試的只是App的開發和Debug版本，而不是最終的Release版本。在打包最終的Release版本時，我們一般還要加上數字簽名，或者再加上代碼混淆。那么最終的發布版本和Debug版本肯定有不一致的地方。我們iPhone的App曾經使用過一個第三方開源庫，在Debug版本時完全工作正常，但是正式上線后才發現必定會導致崩潰。這個代價和經驗非常寶貴（其實這個開源庫的論壇上已經討論並警告過這個問題）。我們后來花了許多力氣來修正和彌補這個問題。如果在一開始就針對Release版本進行了測試，這樣的問題是不會出現的。
Debug& Release
測試網絡相關的App，有三個非常重要的最佳實踐。
1、2G、3G、wifi都要覆蓋
這三者之間不僅僅只是網絡速度的差別，它們代表了三種不同的網絡環境。另外你可能沒有想到一種特殊的情況可以用它們來測出問題：開發環境和生產環境。
一個有經驗的開發團隊會在內網搭建測試環境來進行開發時的測試，在上線時將配置切換到線上的生產環境。這個切換應該是在發布流程中需要Check的一個環節。但是，我們有可能遺漏。
所以這個測試用例可以用來防止這種情況的出現，在wifi下內網環境可以work fine，但是2G和3G就不行，只有真實的環境下2G和3G才能正常工作（想想2G和3G是否可以正常訪問http://192.168.1.xxx這樣的地址就可以了）。
2、HTTP、HTTPS都要覆蓋
許多App和后台服務都是通過HTTP來交互的，正常情況下都一切正常。為什么需要測試HTTPS環境？在一些免費上網的環境中，例如在麥當勞、星巴克里，它們的網絡環境都要輸入用戶名和密碼，通過SSL認證來訪問網絡。如果你使用HTTP Client的library對這種異常沒有做捕獲處理，那么你的App必定會崩潰掉。
3、進行網絡異常、服務器宕機或出現404、502等情況下的測試
后台服務的穩定性是你有時很難去控制的，尤其是牽涉到DNS、空間服務商的情況下。國內某著名DNS服務商經常出現大規模域名解析故障，碰到這種情況，你對后台API的請求很可能就會出現404錯誤。而你和API交互的數據應該是某種固定格式例如JSON和XML，這樣你的數據解析必然會出現錯誤，拋出異常。如果你對異常沒有進行正確的處理可能會導致程序不能正常工作。以下用偽代碼解釋一下邏輯：
而針對不同的手機系統也有需要注意的地方。Android系統固件1.5、1.6和2.0以上版本都是要分別詳細測試的。因為Android 1.5、1.6及以上的SDK有很多實現不一致的地方，兼容性有很大問題。在沒有做特殊處理時，可以在Android 1.6上正常運行的程序基本在1.5上打開就會崩潰（資源文件和API的問題，這個可以單獨寫一篇文章來解釋這個問題）。
Andorid 1.5目前仍有1.0%的保有量
我測試Android1.5的機型：摩托羅拉Backflip
針對iOS系統，除了iOS3、iOS4和iOS5的測試外。我只想說盡可能多，盡可能謹慎，盡可能苛刻的進行測試。受限於App Store冗長的審核周期，一旦你的應用出現嚴重系統錯誤，你的修復版本基本不可能在很短時間內在App Store上架。那么用戶將需要容忍一周左右的時間你的App所帶來的煎熬或者永遠離去。
App Store的審核以嚴厲和時間長著稱