摘要：由于測試環境中的數據為模擬數據，測試時必須預先考慮到正式環境中可能出現的數據類型。并在之后的測試報告中予以體現。只有在回歸測試通過之后，才對產品進行提交。測試工具歸納是蘋果自帶的工具，肯定比較好用。

最近跟很多同行討論過，現在也想和大家聊聊，我這里還有一些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提供有價值的信息。而找到那些關鍵問題的最好方法就是：提問！