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