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

最近跟很多同行討論過，現(xiàn)在也想和大家聊聊，我這里還有一些APP測試的具體指標(biāo),希望通過自己很有限的經(jīng)驗幫助大家。內(nèi)容中部分是可以百度到，部分是我自己的一些看法，歡迎大家補(bǔ)充。
2016/1/27

雖然近幾年有大量的測試人員加入到測試這個行業(yè)，社會中的各種培訓(xùn)機(jī)構(gòu)、學(xué)習(xí)網(wǎng)站、交流社區(qū)也越來越多，但是能真正認(rèn)真做測試的公司仍然不多，這里說的“認(rèn)真”并不是一次精準(zhǔn)細(xì)致的測試或者說短時間內(nèi)的測試，而是指對一款A(yù)PP的生長過程中的無數(shù)次測試，隨著環(huán)境的改變而做出不同的測試。
我們都知道任何App要想在蘋果的AppStore上架，都需要經(jīng)過蘋果的審核員的審核，不管你是世界五百強(qiáng)的大公司，還是小作坊，都會一視同仁，絕無例外。如果你的App沒有經(jīng)過良好的測試，被審核員發(fā)現(xiàn)有閃退、崩潰或者其他嚴(yán)重質(zhì)量問題，他們會毫不猶豫地拒絕你的App。而你則需要修改App，重新提交，這往往就意味著再等7~8天的排隊才有機(jī)會被審核。如果你的運(yùn)氣好，Bug沒有被審核員發(fā)現(xiàn)，或者說，在審核員審核的環(huán)境下，你的App表現(xiàn)良好，你的App就成功上架了。但是如果它在用戶的iPhone/iPad上面發(fā)生閃退、崩潰，等等，其實你會更倒霉。因為憤怒的用戶會迅速讓你收獲大量的1星，即使你好不容易做了一年的好評度，也會一下子跌落谷底。如果你熟悉AppStore的話，就知道這往往意味著你的下載量將一落千丈，你的App也有可能從此無人問津。所以，對iOS開發(fā)者強(qiáng)調(diào)測試的重要性，我覺得說100遍、1萬遍都不嫌多，都有其現(xiàn)實意義。但是為什么還有那么多團(tuán)隊和個人開發(fā)者沒有進(jìn)行完善的測試呢？懶、僥幸心理、怕麻煩一定是少不了的。還有，我覺得就是一般的入門書、教程，甚至包括蘋果的官方文檔，講到的測試部分都太簡單，缺乏可操作性。 我給大家推薦一本專注于iOS測試領(lǐng)域的書，書名為《iOS 測試指南》，作者是羋峮。書中的內(nèi)容很具體，也很實用，從基本的講到iOS環(huán)境再講到iOS的持續(xù)集成，使我受益匪淺。

A.測試周期

測試周期一般為兩周，根據(jù)項目情況以及版本質(zhì)量可適當(dāng)縮短或延長測試時間。正式測試前先向主管或產(chǎn)品經(jīng)理確認(rèn)項目排期。

B.測試資源

測試任務(wù)開始前，檢查各項測試資源。
產(chǎn)品功能需求文檔
產(chǎn)品原型圖
產(chǎn)品效果圖
行為統(tǒng)計分析定義文檔
測試設(shè)備（ios3.1.3-ios5.0.1）
其他（例如有秒殺專題的項目，需要規(guī)劃秒殺時間表；有優(yōu)惠券使用的項目，需要申請?zhí)砑觾?yōu)惠券數(shù)據(jù)；支付寶/銀聯(lián)支付功能的項目，需要提前申請支付寶/銀聯(lián)賬戶等等）

C.測試要點

接收版本
本人覺得，這個過程可以直接略過。非專業(yè)測試者，不喜勿拍。

UI測試

確保手頭的原型圖與效果圖為當(dāng)前最新版本。

確保產(chǎn)品UI符合產(chǎn)品經(jīng)理制定的原型圖與效果圖。

一切界面問題以效果圖為準(zhǔn)，若有用戶體驗方面的建議，必須先以郵件或口頭的形式詢問產(chǎn)品經(jīng)理。

由于測試環(huán)境中的數(shù)據(jù)為模擬數(shù)據(jù)，測試時必須預(yù)先考慮到正式環(huán)境中可能出現(xiàn)的數(shù)據(jù)類型。

功能測試

確保手頭的功能需求文檔為當(dāng)前最新版本。

確保所有的軟件功能都已實現(xiàn)且邏輯正常。

一切功能問題以需求文檔為準(zhǔn)，若有用戶體驗方面的建議，必須先以郵件或口頭的形式詢問產(chǎn)品經(jīng)理。個人建議，用戶體驗方面的建議，優(yōu)先級放在修復(fù)bug之后。

若有些功能在技術(shù)上難以實現(xiàn)或者由于排期的原因無法在短時間內(nèi)實現(xiàn)，必須得到產(chǎn)品經(jīng)理的確認(rèn)，而不是單單只聽開發(fā)人員的技術(shù)解釋。此處確認(rèn)最好以郵件形式存在。

所有的“外部原因”問題，都需要盡早地督促開發(fā)人員與客戶服務(wù)端人員聯(lián)系協(xié)調(diào)解決。并在之后的測試報告中予以體現(xiàn)。

所有的“設(shè)計如此”、“延期處理”問題，都需要和產(chǎn)品經(jīng)理確認(rèn)后再進(jìn)行驗證。并在之后的測試報告中予以體現(xiàn)。

測試下單時，注冊的測試賬號必須符合公司規(guī)范；收貨地址必須包含“測試”關(guān)鍵字，最好每次下單的名稱中含有日期，以便查詢；在正式環(huán)境中下單后必須取消該訂單等。

兼容測試/性能測試

確保軟件在所有兼容機(jī)型上都能正常使用（ios一般需要兼容7或者6, ios5可以不用考慮，用戶使用率已經(jīng)低于5%以下）

對于低端性能兼容機(jī)上獨有的問題（例如ios5以下），若在技術(shù)上難以修改或者由于排期的原因無法在短時間內(nèi)改進(jìn)，必須在測試日報中注明，并得到技術(shù)平臺主管、產(chǎn)品經(jīng)理以及運(yùn)營人員的確認(rèn)，最好以郵件的形式得到確認(rèn)。

性能測試方面必須滿足硬件壓力條件下的測試需要（例如多線程，用戶常用的app都要后臺運(yùn)行的環(huán)境中測試。）

網(wǎng)絡(luò)響應(yīng)用戶體驗方面的性能測試，需要保證在wifi、3g、2g網(wǎng)絡(luò)下的切換效果。比如wifi切換到2g，網(wǎng)絡(luò)響應(yīng)的速度以及切換界面。

后臺訂單統(tǒng)計測試

核對“客戶端相關(guān)啟動查詢”項，此項數(shù)據(jù)就是經(jīng)常說的“激活量”，非常重要。測試時必須保證該項中的各數(shù)據(jù)均正確，且每次啟動軟件都會有相應(yīng)的統(tǒng)計記錄。

核對“訂單查詢”項，測試時必須保證各數(shù)據(jù)均正確，且每次成功下單后都會有相應(yīng)的統(tǒng)計記錄。

需要注意的是，在成功下單之后，后臺會做判斷將該訂單劃到測試訂單范圍，測試人員必須到“訂單查詢（測試）”模塊中核對訂單統(tǒng)計記錄信息。

用戶行為統(tǒng)計測試

確保手頭的行為統(tǒng)計分析定義文檔為最新版本，且與開發(fā)人員手中的文檔一致。

確保產(chǎn)品經(jīng)理在文檔中所定義的頁面在該產(chǎn)品中都是存在的。

盡可能真實地模擬用戶行為。

核對統(tǒng)計日志，確保各項操作所對應(yīng)的頁面ID以及操作ID都是正確的。

回歸測試

軟件最終上線前，需對產(chǎn)品進(jìn)行回歸測試，測試內(nèi)容包含之前所有的測試項目

回歸測試不再對細(xì)節(jié)進(jìn)行測試，而是類似于對產(chǎn)品進(jìn)行驗收，從客戶正常使用的角度對產(chǎn)品進(jìn)行再一輪的整體測試。

只有在回歸測試通過之后，才對產(chǎn)品進(jìn)行提交。

D.測試日報及產(chǎn)品上線報告

測試人員每天需對所測項目發(fā)送測試日報。
測試日報所包含的內(nèi)容為：

對當(dāng)前測試版本質(zhì)量進(jìn)行分級。

對較嚴(yán)重的問題進(jìn)行例舉，提示開發(fā)人員優(yōu)先修改。

對版本的整體情況進(jìn)行評估。
(產(chǎn)品上線前，測試人員發(fā)送產(chǎn)品上線報告)

在不應(yīng)該返回的時候返回了

不耐心而且多次敲按鍵；

輸入錯誤的數(shù)據(jù)；

不理解該怎么做；

可能沒有按要求進(jìn)行設(shè)置；

可能會自以為是地認(rèn)為自己知道該怎做什么（比如通常不閱讀說明）。

測試人員遇到這些問題時，也常常發(fā)現(xiàn)意料之外的Bug。有時候，這些Bug微不足道，但是更深入的調(diào)查就會發(fā)現(xiàn)更嚴(yán)重的問題。
很多問題是可以被預(yù)先確定和測試的。測試移動端App時，以下的問題并不都有關(guān)，但是也可以嘗試問問：

是否按照所說的來做呢？

是按設(shè)計完成任務(wù)的嗎？

不是按設(shè)計完成任務(wù)的嗎？

如果處于一直被使用或者負(fù)荷情況下，狀況會怎么樣？會反應(yīng)遲鈍嗎？會崩潰嗎？會更新嗎？有反饋嗎？

崩潰報告會反饋到App嗎？

用戶可能有哪些創(chuàng)造性的、邏輯性的或是消極的導(dǎo)航方式？用戶相信你的品牌嗎？

用戶的數(shù)據(jù)安全如何？

有可能被中斷或是被破解嗎？

運(yùn)行到極限時會發(fā)生什么狀況？

會要求打開相關(guān)服務(wù)嗎(如GPS、Wi-Fi)？如果用戶打開會怎樣？沒打開又會怎樣？

將用戶重新引向哪兒？去網(wǎng)頁？還是從網(wǎng)頁到App？這會導(dǎo)致問題出現(xiàn)嗎？

溝通過程和市場反饋是否符合該App的功能、設(shè)計和內(nèi)容？

登錄流程是怎樣的？能在App上直接登錄還是要去網(wǎng)頁端？

登錄是否整合了其他服務(wù)，比如用Facebook和Twitter帳號登錄？

可能的是用戶或者是軟件開發(fā)人員在信息流中確實太容易迷惑了，因為可能會出現(xiàn)很多錯誤，所以基于數(shù)據(jù)和云的服務(wù)更為重要。
也許你可以嘗試在以下場景中檢查出問題：

移動設(shè)備數(shù)據(jù)已滿；

測試人員移除了所有的數(shù)據(jù)；

測試人員刪除了App，那數(shù)據(jù)怎么辦？

測試人員刪除并重裝了App，數(shù)據(jù)怎么辦？

過多或者過少的內(nèi)容導(dǎo)致設(shè)計和布局的改變；

在不同的時間段和時區(qū)使用；

數(shù)據(jù)不同步；

同步被中斷；

數(shù)據(jù)更新影響其他的服務(wù)（比如網(wǎng)頁和云端服務(wù)）；

快速處理數(shù)據(jù)或是處理大量的數(shù)據(jù)；

使用無效的數(shù)據(jù)

這只是無數(shù)測試過程中需要測試者需要去解決的很小一部分，大家心里也都知道很多，篇幅有限就不過多的說了。

UIAutomation是蘋果xcode自帶的工具，肯定比較好用。連上手機(jī)（簽名的app或者越獄debug包）就可以進(jìn)行自動化測試了。

appium，它原理就是通過selenium的webdriver移植過來的，現(xiàn)在也可以驅(qū)動UIAutomation進(jìn)行自動化測試，優(yōu)點是可以用任何語言開發(fā)，但是工具本身bug多，容易假死。

所以最好這兩個工具都會用。
另外如果你是開發(fā)者，沒有完成專業(yè)測試的條件，因為這需要極大的硬件與人力成本。在共享經(jīng)濟(jì)與協(xié)作開放的時代，開發(fā)者可以嘗試從第三方來進(jìn)行應(yīng)用測試，繼而發(fā)現(xiàn)應(yīng)用的不足之處，及時完善產(chǎn)品質(zhì)量，加速上線審核。讓專業(yè)的人做專業(yè)的事，別讓莫名其妙的bug拖延你寶貴的上線時間。這方面的話做的人很多，我不過多介紹了，只給大家推薦一個Testbird云測在測試領(lǐng)域是做得很好的一家。

Testbird云測 （致力于APP移動應(yīng)用測試的專家）

之前看過一篇講測試的文章，其中有一段我認(rèn)為講的非常好，這里引用一下

測試不是對錯判斷
我們討論了移動測試的一些方面，但這些前提是：帶著問題，才能發(fā)現(xiàn)問題。
通常，測試被認(rèn)為是完全合乎邏輯的、可計劃的和可預(yù)測的，過程包括：測試腳本和測試計劃、通過和失敗、正確和錯誤的反饋。走完這些測試流程就離真相不遠(yuǎn)了。
當(dāng)然，如果必要，我們可以用上述方法進(jìn)行測試，但這并不是測試的目的。我們不僅是為了創(chuàng)建測試用例、發(fā)現(xiàn)Bug，更重要的是找到關(guān)鍵的問題，為項目組決定什么時候發(fā)布App提供有價值的信息。而找到那些關(guān)鍵問題的最好方法就是：提問！