做移動互連網App，你的測試案例足夠嗎？

    我在面試測試工程師時，經常問到的一個問題是“給出Word另存新檔這個功能的測試案例”。除開基本的測試案例外，考慮到各種異常情況，例如記憶體已滿、硬碟空間不足是非常重要的。但是針對移動互連網App來說，情況還要複雜的多。

    一個重要原則是：測試你最終要發布給使用者的App版本。

    可能每日構建、每日測試的理念已經深入人心，我們很多時候測試的只是App的開發和Debug版本，而不是最終的Release版本。在打包最終的Release版本時，我們一般還要加上數位簽章，或者再加上代碼混淆。那麼最終的發布版本和Debug版本肯定有不一致的地方。我們iPhone的App曾經使用過一個第三方開源庫，在Debug版本時完全工作正常，但是正式上線後才發現必定會導致崩潰。這個代價和經驗非常寶貴（其實這個開源庫的論壇上已經討論並警告過這個問題）。我們後來花了許多力氣來修正和彌補這個問題。如果在一開始就針對Release版本進行了測試，這樣的問題是不會出現的。

Debug& Release

 

    測試網路相關的App，有三個非常重要的最佳實務。

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

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

    一個有經驗的Team Dev會在內網搭建測試環境來進行開發時的測試，在上線時將配置切換到線上的生產環境。這個切換應該是在發布流程中需要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，這樣你的資料解析必然會出現錯誤，拋出異常。如果你對異常沒有進行正確的處理可能會導致程式不能正常工作。以下用虛擬碼解釋一下邏輯：

try {<br />if(request() == success) {<br />callSuccess();<br />} else {<br />callFail();<br />}<br />hidePopup();<br />} catch(e) {<br />// do nothing, just wait….now popup window will show forever on the screen!!!<br />// if it is a iOS app, the popup window will lock the screen<br />}

    而針對不同的手機系統也有需要注意的地方。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的審核以嚴厲和時間長著稱