手機上的app分為基於HTML5的app（類似於pc上的b/S應用）和本地app（類似於C/S結構）。 所以測試上我們也可以充分吸收web的b/s和c/s測試經驗。但是不同於pc上的應用測試，手機上的測試有其獨特性 測試前的思考：我們這個產品主要是做什麼的？為什麼我要做這個產品?市場上有那些同類型的產品？ 測試前的準備：1.使用同類型的產品，不僅僅是使用，應該是測試同類型的產品。2.熟悉我們產品的spec文件，積極和pm交流。3，寫測試用例，沒有時間至少要有一個checklist。
1.功能 a.基本功能，主要指app是否完成了設計的所有功能。分清模組，寫一份checklist，避免漏測。考慮橫豎屏切換，不過很多app現在只支援豎屏。 b.系統互動:電話簡訊干擾，低電量提醒，push提醒，usb資料線插拔提醒，充電提醒等， 2.效能:穩定性，兼用型（android碎片化是個難題，bug也多，ios相對bug少），app執行的記憶體消耗和cpu消耗，app後臺長時間執行的耗流量，耗電量。 推薦testin這個第三方平臺，對android兼用性測試比較有幫助。還有個百度移動雲平臺 3.易用性：面是否吸引人、容易理解。介面整潔、簡單。無錯別字。點選範圍確定等。這部分測試中，如果測試認為有不合理的地方通常會提交需求bug。
4.外場：網路切換，網路訊號強，弱下的app執行情況。 對自動化的一些看法： 目前我們可以接觸到手機方面的自動化工具：robotium，monkey，monkeyrunner，androidjunit。但是由於ui變化快，自動化測試往往不方便維護。前三個不需要原始碼支援，但是功能有限，androidjunit很強大，對程式碼能力要求高，同時需要原始碼支援。app的開發週期一般都很短，ui變化大，用自動化要考慮投入成本，大多數的公司估計都不適用。不過測介面之類的通過自動化是個不錯的選擇。 轉，說得多有道理的。

1.移動網際網路開發節奏很快，版本快速迭代，如何讓測試敏捷起來？
Monkey：我建議放棄完全得Test Case。全部用feature list或者測試思維導圖或者功能點劃分表來進行引導得測試。主要目的不會漏掉功能點以及防止regression得bug。其次要敏捷必須要有自動化得支援。關於這點就是根據不同得app進行定義了。首先UT無論如何就要做起來。其次是api和regression test得自動化要做起來。當然CI也一定要搭建的。


2.移動應用測試，如何更全面的保證產品質量？如何讓使用者參與到測試中來？
Monkey：更全面得保證產品質量。如果要說到全面，那麼必須就是功能，壓力，效能，安全，使用者體驗面面具到了。其實還是和我第一個問題說得一樣。將app結合os得特性分層進行逐個得測試或者自動化測試。關於讓使用者參與到測試中來的話。我建議可以將不同的使用者集合起來，qq或者weixin保持聯絡。然後android可以定期釋出內測版本，ios可以釋出testflight版本。


3.使用者反饋問題建議非常多，如何做好有效管理、分析和反饋？
Monkey：這個我相信無論哪家公司都會碰見。使用者的反饋不一定都是有效的。管理的話，我建議還是需要安排一個專門的人進行記錄。將反饋全部作為bug的一種，隨後填入bug系統方便跟蹤。其次關於crash或者無法重現的問題。就需要自己在軟體中增加自動反饋crash log的機制。包括用第三方的友盟等也可以。隨後再定期的進行log的分析。這些其實都不難，主要就是需要堅持，一直去做。


4.競爭產品很多，測試如何做競品分析？
Monkey：這個其實我並不是很在行。不過我覺得分析的話。主要有幾點。其一，核心功能的體驗。也就是說核心功能路徑長短。比如A用了3步完成B用了4步完成的功能，那麼A明顯有優勢。其二，核心功能的互動，包括使用者的學習成本。其三，場景分析，比如我們可以設計N個場景，在這N個場景中我們自己的產品和競爭對手的產品，使用者會做什麼選擇。其實往往我們一設計之後就發現，有些功能使用者根本無法理解，或者根本不用去做。自然也就沒有意義。當然分析還有很多，包括下載量，點選數，評論等等。都可以觀察。 app的測試方式我在我自己的書中會有寫。這裡我簡單介紹以下。不過首先需要肯定是不是拿到手就可以測的。更多的是需要了解
a。產品功能feature list需要熟悉
b。需要產品所在的系統的架構
c。需要熟悉產品本身的結構，本身的邏輯，包括cs結構，生命週期，api等
d。根據abc來設計測試點，測試點可以是思維導圖或者別的。但是並不需要去編寫很詳細的測試用例。