關於IOS測試

前言：

最近跟不少同行討論過，如今也想和你們聊聊，我這裏還有一些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提供有價值的信息。而找到那些關鍵問題的最好方法就是：提問！