前言：
最近跟很多同行討論過，現在也想和大家聊聊，我這裡還有一些APP測試的具體指標,希望通過自己很有限的經驗幫助大家。內容中部分是可以百度到，部分是我自己的一些看法，歡迎大家補充。
2016/1/27
雖然近幾年有大量的測試人員加入到測試這個行業，社會中的各種培訓機構、學習網站、交流社群也越來越多，但是能真正認真做測試的公司仍然不多，這裡說的“認真”並不是一次精準細緻的測試或者說短時間內的測試，而是指對一款APP的生長過程中的無數次測試，隨著環境的改變而做出不同的測試。
我們都知道任何App要想在蘋果的AppStore上架，都需要經過蘋果的稽核員的稽核，不管你是世界五百強的大公司，還是小作坊，都會一視同仁，絕無例外。如果你的App沒有經過良好的測試，被稽核員發現有閃退、崩潰或者其他嚴重質量問題，他們會毫不猶豫地拒絕你的App。而你則需要修改App，重新提交，這往往就意味著再等7~8天的排隊才有機會被稽核。如果你的運氣好，Bug沒有被稽核員發現，或者說，在稽核員稽核的環境下，你的App表現良好，你的App就成功上架了。但是如果它在使用者的iPhone/iPad上面發生閃退、崩潰，等等，其實你會更倒黴。因為憤怒的使用者會迅速讓你收穫大量的1星，即使你好不容易做了一年的好評度，也會一下子跌落谷底。如果你熟悉AppStore的話，就知道這往往意味著你的下載量將一落千丈，你的App也有可能從此無人問津。所以，對iOS開發者強調測試的重要性，我覺得說100遍、1萬遍都不嫌多，都有其現實意義。但是為什麼還有那麼多團隊和個人開發者沒有進行完善的測試呢？懶、僥倖心理、怕麻煩一定是少不了的。還有，我覺得就是一般的入門書、教程，甚至包括蘋果的官方文件，講到的測試部分都太簡單，缺乏可操作性。 我給大家推薦一本專注於iOS測試領域的書，書名為《iOS 測試指南》，作者是羋峮。書中的內容很具體，也很實用，從基本的講到iOS環境再講到iOS的持續整合，使我受益匪淺。
指標：
A.測試周期
測試周期一般為兩週，根據專案情況以及版本質量可適當縮短或延長測試時間。正式測試前先向主管或產品經理確認專案排期。
B.測試資源
測試任務開始前，檢查各項測試資源。
產品功能需求文件
產品原型圖
產品效果圖
行為統計分析定義文件
測試裝置（ios3.1.3-ios5.0.1）
其他（例如有秒殺專題的專案，需要規劃秒殺時間表；有優惠券使用的專案，需要申請新增優惠券資料；支付寶/銀聯支付功能的專案，需要提前申請支付寶/銀聯賬戶等等）
C.測試要點
接收版本
本人覺得，這個過程可以直接略過。非專業測試者，不喜勿拍。
UI測試
-
確保手頭的原型圖與效果圖為當前最新版本。
-
確保產品UI符合產品經理制定的原型圖與效果圖。
-
一切介面問題以效果圖為準，若有使用者體驗方面的建議，必須先以郵件或口頭的形式詢問產品經理。
-
由於測試環境中的資料為模擬資料，測試時必須預先考慮到正式環境中可能出現的資料型別。
功能測試
-
確保手頭的功能需求文件為當前最新版本。
-
確保所有的軟體功能都已實現且邏輯正常。
-
一切功能問題以需求文件為準，若有使用者體驗方面的建議，必須先以郵件或口頭的形式詢問產品經理。個人建議，使用者體驗方面的建議，優先順序放在修復bug之後。
-
若有些功能在技術上難以實現或者由於排期的原因無法在短時間內實現，必須得到產品經理的確認，而不是單單隻聽開發人員的技術解釋。此處確認最好以郵件形式存在。
-
所有的“外部原因”問題，都需要儘早地督促開發人員與客戶服務端人員聯絡協調解決。並在之後的測試報告中予以體現。
-
所有的“設計如此”、“延期處理”問題，都需要和產品經理確認後再進行驗證。並在之後的測試報告中予以體現。
-
測試下單時，註冊的測試賬號必須符合公司規範；收貨地址必須包含“測試”關鍵字，最好每次下單的名稱中含有日期，以便查詢；在正式環境中下單後必須取消該訂單等。
相容測試/效能測試
-
確保軟體在所有相容機型上都能正常使用（ios一般需要相容7或者6, ios5可以不用考慮，使用者使用率已經低於5%以下）
-
對於低端效能相容機上獨有的問題（例如ios5以下），若在技術上難以修改或者由於排期的原因無法在短時間內改進，必須在測試日報中註明，並得到技術平臺主管、產品經理以及運營人員的確認，最好以郵件的形式得到確認。
-
效能測試方面必須滿足硬體壓力條件下的測試需要（例如多執行緒，使用者常用的app都要後臺執行的環境中測試。）
-
網路響應使用者體驗方面的效能測試，需要保證在wifi、3g、2g網路下的切換效果。比如wifi切換到2g，網路響應的速度以及切換介面。
後臺訂單統計測試
-
核對“客戶端相關啟動查詢”項，此項資料就是經常說的“啟用量”，非常重要。測試時必須保證該項中的各資料均正確，且每次啟動軟體都會有相應的統計記錄。
-
核對“訂單查詢”項，測試時必須保證各資料均正確，且每次成功下單後都會有相應的統計記錄。
-
需要注意的是，在成功下單之後，後臺會做判斷將該訂單劃到測試訂單範圍，測試人員必須到“訂單查詢（測試）”模組中核對訂單統計記錄資訊。
使用者行為統計測試
-
確保手頭的行為統計分析定義文件為最新版本，且與開發人員手中的文件一致。
-
確保產品經理在文件中所定義的頁面在該產品中都是存在的。
-
儘可能真實地模擬使用者行為。
-
核對統計日誌，確保各項操作所對應的頁面ID以及操作ID都是正確的。
迴歸測試
-
軟體最終上線前，需對產品進行迴歸測試，測試內容包含之前所有的測試專案
-
迴歸測試不再對細節進行測試，而是類似於對產品進行驗收，從客戶正常使用的角度對產品進行再一輪的整體測試。
-
只有在迴歸測試通過之後，才對產品進行提交。
D.測試日報及產品上線報告
測試人員每天需對所測專案傳送測試日報。
測試日報所包含的內容為：
-
對當前測試版本質量進行分級。
-
對較嚴重的問題進行例舉，提示開發人員優先修改。
-
對版本的整體情況進行評估。
(產品上線前，測試人員傳送產品上線報告)
測試問題歸納：
-
在不應該返回的時候返回了
-
不耐心而且多次敲按鍵；
-
輸入錯誤的資料；
-
不理解該怎麼做；
-
可能沒有按要求進行設定；
-
可能會自以為是地認為自己知道該怎做什麼（比如通常不閱讀說明）。
測試人員遇到這些問題時，也常常發現意料之外的Bug。有時候，這些Bug微不足道，但是更深入的調查就會發現更嚴重的問題。
很多問題是可以被預先確定和測試的。測試移動端App時，以下的問題並不都有關，但是也可以嘗試問問：
-
是否按照所說的來做呢？
-
是按設計完成任務的嗎？
-
不是按設計完成任務的嗎？
-
如果處於一直被使用或者負荷情況下，狀況會怎麼樣？會反應遲鈍嗎？會崩潰嗎？會更新嗎？有反饋嗎？
-
崩潰報告會反饋到App嗎？
-
使用者可能有哪些創造性的、邏輯性的或是消極的導航方式？使用者相信你的品牌嗎？
-
使用者的資料安全如何？
-
有可能被中斷或是被破解嗎？
-
執行到極限時會發生什麼狀況？
-
會要求開啟相關服務嗎(如GPS、Wi-Fi)？如果使用者開啟會怎樣？沒開啟又會怎樣？
-
將使用者重新引向哪兒？去網頁？還是從網頁到App？這會導致問題出現嗎？
-
溝通過程和市場反饋是否符合該App的功能、設計和內容？
-
登入流程是怎樣的？能在App上直接登入還是要去網頁端？
-
登入是否整合了其他服務，比如用Facebook和Twitter帳號登入？
可能的是使用者或者是軟體開發人員在資訊流中確實太容易迷惑了，因為可能會出現很多錯誤，所以基於資料和雲的服務更為重要。
也許你可以嘗試在以下場景中檢查出問題：
-
移動裝置資料已滿；
-
測試人員移除了所有的資料；
-
測試人員刪除了App，那資料怎麼辦？
-
測試人員刪除並重灌了App，資料怎麼辦？
-
過多或者過少的內容導致設計和佈局的改變；
-
在不同的時間段和時區使用；
-
資料不同步；
-
同步被中斷；
-
資料更新影響其他的服務（比如網頁和雲端服務）；
-
快速處理資料或是處理大量的資料；
-
使用無效的資料
這只是無數測試過程中需要測試者需要去解決的很小一部分，大家心裡也都知道很多，篇幅有限就不過多的說了。
測試工具歸納：
-
UIAutomation是蘋果xcode自帶的工具，肯定比較好用。連上手機（簽名的app或者越獄debug包）就可以進行自動化測試了。
-
appium，它原理就是通過selenium的webdriver移植過來的，現在也可以驅動UIAutomation進行自動化測試，優點是可以用任何語言開發，但是工具本身bug多，容易假死。
所以最好這兩個工具都會用。
另外如果你是開發者，沒有完成專業測試的條件，因為這需要極大的硬體與人力成本。在共享經濟與協作開放的時代，開發者可以嘗試從第三方來進行應用測試，繼而發現應用的不足之處，及時完善產品質量，加速上線稽核。讓專業的人做專業的事，別讓莫名其妙的bug拖延你寶貴的上線時間。這方面的話做的人很多，我不過多介紹了，只給大家推薦一個Testbird雲測在測試領域是做得很好的一家。
Testbird雲測 （致力於APP移動應用測試的專家）
最後：
之前看過一篇講測試的文章，其中有一段我認為講的非常好，這裡引用一下
測試不是對錯判斷
我們討論了移動測試的一些方面，但這些前提是：帶著問題，才能發現問題。
通常，測試被認為是完全合乎邏輯的、可計劃的和可預測的，過程包括：測試指令碼和測試計劃、通過和失敗、正確和錯誤的反饋。走完這些測試流程就離真相不遠了。
當然，如果必要，我們可以用上述方法進行測試，但這並不是測試的目的。我們不僅是為了建立測試用例、發現Bug，更重要的是找到關鍵的問題，為專案組決定什麼時候釋出App提供有價值的資訊。而找到那些關鍵問題的最好方法就是：提問！