分析三種主流的移動 App 類型，并給出和普通web測試不同的地方，給出測試的思路，并給出部分場景組合。
移動端測試還是 PC 端測試，業務測試其實都屬于 GUI 測試的范疇，所以基本的測試思路，比如基于頁面對象封裝和基于業務流程封裝的思想是相通的。
三種移動端產品類型介紹
移動端應用的測試其自身特點，和其他傳統測試又有一些獨特的測試方法與思路。
移動端應用又可以進一步細分為三大類：
三類不同移動應用的測試方法
根據它們的特性來總結出它們的測試方法：
唯一需要注意的是， 和 分別屬于兩個不同的上下文（）， 默認的 為“ APP"，而 默認的 為“+ 被測進程名稱”。
所以，當需要操作 中的網頁元素時，需要先切換到 的 下。
Web測試和APP測試的區別
相同點：WEB測試和App測試從流程上來說，沒有區別。都需要經歷測試計劃方案，用例設計，測試執行，缺陷管理，測試報告等相關活動。從技術上來說，WEB測試和APP測試其測試類型也基本相似，都需要進行功能測試、性能測試、安全性測試、GUI測試等測試類型。
不同點：他們的主要區別在于具體測試的細節和方法有區別。
性能測試，在WEB測試只需要測試響應時間這個要素，在App測試中還需要考慮流量測試和耗電量測試。
兼容性測試：在WEB端是兼容瀏覽器，在App端兼容的是手機設備。而且相對應的兼容性測試工具也不相同，WEB因為是測試兼容瀏覽器，所以需要使用不同的瀏覽器進行兼容性測試（常見的是兼容IE6，IE8，，）如果是手機端，那么就需要兼容不同品牌，不同分辨率，不同版本甚至不同操作系統的兼容。（常見的兼容方式是兼容市場占用率前N位的手機即可），有時候也可以使用到兼容性測試工具，但WEB兼容性工具多用等工具，而App兼容性測試會使用這樣的商業工具也可以做測試。
安裝測試：WEB測試基本上沒有客戶端層面的安裝測試，但是App測試是存在客戶端層面的安裝測試，那么就具備相關的測試點。
App測試基于手機設備，還有一些手機設備的專項測試。如交叉事件測試，操作類型測試，網絡測試（弱網測試，網絡切換）交叉事件測試：就是在操作某個軟件的時候，來電話、來短信，電量不足提示等外部事件。操作類型測試：如橫屏測試，手勢測試網絡測試：包含弱網和網絡切換測試。需要測試弱網所造成的用戶體驗，重點要考慮回退和刷新是否會造成二次提交。弱網絡的模擬，據說可以用實現設置。升級測試：升級測試的提醒機制，升級取消是否會影響原有功能的使用，升級后用戶數據是否被清除了。
從系統架構的層面，WEB測試只要更新了服務器端，客戶端就會同步會更新。而且客戶端是可以保證每一個用戶的客戶端完全一致的。但是APP端是不能夠保證完全一致的，除非用戶更新客戶端。如果是APP下修改了服務器端，意味著客戶端用戶所使用的核心版本都需要進行回歸測試一遍。
如此看來，移動端的測試除了使用的測試框架不同以外，測試設計本身和 GUI 測試有異曲同工之妙，對于移動端還應該有其他的不同測試思路和方法。
移動應用專項測試的思路和方法
對于移動應用，順利完成全部業務功能測試往往是不夠的，當移動應用被大量用戶安裝和使用時，就會暴露出很多之前完全沒有預料到的問題，
比如：
1.流量使用過多；
2.耗電量過大；
3.在某些設備終端上出現崩潰或者閃退的現象；
4.多個移動應用相互切換后，行為異常；
5.在某些設備終端上無法順利安裝或卸載；
6.弱網絡環境下，無法正常使用；
7. 環境下，經常出現 ANR( Not )；
…
這樣的問題還有很多，為了避免或減少此類情況的發生，所以移動應用除了進行常規的功能測試外，通常還會進行很多移動應用所特有的專項測試。
1. 交叉事件測試
交叉事件測試也叫中斷測試，是指 App 執行過程中，有其他事件或者應用中斷當前應用執行的測試。
比如，App 在前臺運行過程中，突然有電話打進來，或者收到短信，再或者是系統鬧鐘等等情況。所以，在 App 測試時，就需要把這些常見的中斷情況考慮在內，并進行相關的測試。
此類測試目前基本還都是采用手工測試的方式，并且都是在真機上進行，不會使用模擬器。
首先，采用手工測試的原因是，此類測試往往場景多，而且很多事件很難通過自動化的方式來模擬，比如呼入電話、接收短信等，這些因素都會造成自動化測試的成本過高網絡切換代碼用不了，得不償失，所以工程實踐中，交叉事件測試往往全是基于手工的測試。
其次，之所以采用真機，是因為很多問題只會在真機上才能重現，采用模擬器測試沒有意義。
交叉事件測試，需要覆蓋的場景主要包括：
1.多個 App 同時在后臺運行，并交替切換至前臺是否影響正常功能；
2.要求相同系統資源的多個 App 前后臺交替切換是否影響正常功能，比如兩個 App 都需要播放音樂，那么兩者在交替切換的過程中，播放音樂功能是否正常；
3.App 運行時接聽電話；
4.App 運行時接收信息；
5.App 運行時提示系統升級；
6.App 運行時發生系統鬧鐘事件；
7.App 運行時進入低電量模式；
8.App 運行時第三方安全軟件彈出告警；
9.App 運行時發生網絡切換，比如，由 Wifi 切換到移動 4G 網絡，或者從 4G 網絡切換到 3G
網絡等；
…
其實你可以發現，這些需要覆蓋的場景，也是我們今后測試的測試用例集，每一場景都是一個測試用例的集合。
2. 兼容性測試
兼容性測試顧名思義就是，要確保App在各種終端設備、各種操作系統本、各種屏幕分辨率、各種網絡環境下，功能的正確性。常見的App兼容性測試往往需要覆蓋以下的測試場景：
1.不同操作系統的兼容性，包括主流的 和 iOS 版本；
2.主流的設備分辨率下的兼容性；
3.主流移動終端機型的兼容性；
4.同一操作系統中，不同語言設置時的兼容性；
5.不同網絡連接下的兼容性，比如 Wifi、GPRS、EDGE、 等；
6.在單一設備上，與主流熱門 App 的兼容性，比如微信、抖音、淘寶等；
…
兼容性測試通常都需要在各種真機上執行相同或者類似的測試用例，所以往往采用自動化測試的手段。 同時，由于需要覆蓋大量的真實設備，除了大公司會基于 + +去搭建自己的移動設備私有云平臺外，其他公司一般都會使用第三方的移動設備云測平臺完成兼容性測試。第三方的移動設備云測平臺，國外最知名的是 ，國內主流的是。
3. 流量測試
由于 App 經常需要在移動互聯網環境下運行，而移動互聯網通常按照實際使用流量計費，所以如果你的App耗費的流量過多，第一會導致用戶流量費用增加，第二會會導致功能加載緩慢。
流量測試，通常包含以下幾個方面的內容：
1.App 執行業務操作引起的流量；
2.App 在后臺運行時的消耗流量；
3.App 安裝完成后首次啟動耗費的流量；
4.App 安裝包本身的大小；
5.App 內購買或者升級需要的流量;
…
流量測試，往往借助于 和 iOS 自帶的工具進行流量統計，也可以利用 、 和 等網絡分析工具。
對于 系統，網絡流量信息通常存儲在/proc/net/dev目錄下，也可以直接利用 ADB工具獲取實時的流量信息。的輕量級性能監控小工具，類似于 系統性能監視器，能夠實時顯示App運行過程中CPU、內存和流量等信息。
對于 iOS 系統，可以使用 Xcode 自帶的性能分析工具集中的 ，分析具體的流量使用情況。
但是，流量測試的最終目的，并不是得到 App 的流量數據，而是要想辦法減少 App 產生的流量。減少App消耗的流量不是測試工程師的工作，但了解一些常用的方法，也將有助于你的測試日常工作：
1.啟用數據壓縮，尤其是圖片；
2.使用優化的數據格式，比如同樣信息量的 JSON 文件就要比 XML 文件小；
3.遇到既需要加密又需要壓縮的場景，一定是先壓縮再加密；
4.減少單次 GUI 操作觸發的后臺調用數量；
5.每次回傳數據盡可能只包括必要的數據；
6.啟用客戶端的緩存機制；
…
4. 耗電量測試
耗電量也是一個移動應用能否成功的關鍵因素之一。在目前的生態環境下，能提供類似服務或者功能的 App往往有很多，如果在功能類似的情況下，App特別耗電、讓設備發熱比較嚴重，那么你的用戶一定會卸載你的 App 而改用其他 App。最典型的就是地圖等導航類的應用，對耗電量特別敏感。
耗電量測試通常從三個方面來考量：
耗電量檢測既有基于硬件的方法，也有基于軟件的方法。我所經歷過的項目都是采用軟件的方法， 和 iOS 都有各自自己的方法： 通過 adb 命令“adb shell ”來獲取應用的耗電量信息耗電測試中，推出的 工具很好分析耗電情況；
iOS 通過 Apple 的官方工具 來收集耗電量信息，然后，可以進一步通過 工具鏈中的 進行耗電量分析。
5. 弱網絡測試
與傳統桌面應用不同，移動應用的網絡環境比較多樣，而且經常出現需要在不同網絡之間切換的場景，即使是在同一網絡環境下網絡切換代碼用不了，也會出現網絡連接狀態時好時壞的情況，比如時高時低的延遲、經常丟包、頻繁斷線，在乘坐地鐵、穿越隧道，和地下車庫的場景下經常會發生。
所以，移動應用的測試需要保證在復雜網絡環境下的質量。在測試階段，模擬這些網絡環境，在 App 發布前盡可能多地發現并修復問題。推薦開源移動網絡測試工具： （ATC）。
ATC 最好用的地方在于，它能夠在移動終端設備上通過Web界面隨時切換不同的網絡環境，同時多個移動終端設備可以連接到同一個Wifi，各自模擬不同的網絡環境，相互之間不會有任何影響。也就是說，只要搭建一套ATC就能滿足你所有的網絡模擬需求。
6. 邊界測試
邊界測試是指，移動 App在一些臨界狀態下的行為功能的驗證測試，基本思路是需要找出各種潛在的臨界場景，并對每一類臨界場景做驗證和測試。
主要的場景有：
1)系統內存占用大于 90% 的場景；
2)系統存儲占用大于 95% 的場景；
3)飛行模式來回切換的場景；
4)App不具有某些系統訪問權限的場景，比如App由于隱私設置不能訪問相冊或者通訊錄等；
5)長時間使用 App，系統資源是否有異常，比如內存泄漏、過多的鏈接數等；
6)出現 ANR 的場景；
7)操作系統時間早于或者晚于標準時間的場景；
8)時區切換的場景；
…
耗電量測試，流量測試，以及app性能測試，如何界定數據是否正常？例如流量消耗是到哪個值覺得有優化空間，內存CPU到哪個值不正常需要優化
其實并沒有明確的標準，主要基于一些歷史統計數據，主要的做法是和現有版本，以及同類app做比較。
結合實際情況測試點組合場景
結合一些實際情況測試點簡單組合下場景場景：
比如：
出現崩潰：
1)設備碎片化：由于設備極具多樣性，App在不同的設備上可能有表現不同;
2)帶寬限制：帶寬不佳的網絡對App所需的快速響應時間可能不夠;
3)網絡的變化：不同網絡間的切換可能會影響App的穩定性;
4)內存管理：可用內存過低，或非授權的內存位置的使用可能會導致App失敗;
5)用戶過多：連接數量過多可能會導致App崩潰;
6)代碼錯誤：沒有經過測試的新功能，可能會導致App在生產環境中失敗;
7)第三方服務：廣告或彈出屏幕可能會導致App崩潰;
App的安裝與卸載
就是其他web里邊沒有的場景，最基本的藥考慮不同操作系統，考慮不同的操作系統版本，考慮不同手機廠商再操作系統版本修改上的不同，等等
安裝過程中：
1)各個選項是否符合概要設計說明;
2)安裝向導的ui測試;
3)是否支持取消，以及取消后的操作流程（是否有殘留);
4)意外情況處理（司機、重啟、斷電、斷網）;
5)安裝空間不足
安裝完成后：
1)是否正常運行;
2)安裝過程后的文件夾和文件是否寫在了指定的目錄里邊;
3)是否生成了多余的目錄結構和文件;
升級：
1)升級后功能是否和需求說明一樣
2)測試與升級模塊相關的模塊的功能是否
3)升級界面的ui測試（強制/非強制）
4)升級安裝意外情況的測試（死機、重啟、斷電）
5)版本驗證：1.0版-2.0或者1.0-3.0
6)升級中用戶數據、設置、狀態的保留，注意新版本已去掉的狀態或設置；
7)是否可以隔開版本覆蓋安裝；
8)是否可以覆蓋安裝更低版本；
9)如果升級有忽略本次版本升級，那么當有新的升級版本時，是否還有提示升級；
10)大版本更新不升級無法使用；
卸載：
1)系統直接卸載以及卸載時候ui界面測試;
2)直接刪除文件夾，再卸載;
3)卸載過程中是否支持取消，取消后的軟件狀態;
4)卸載時候意外的情況處理（死機、斷網、斷電、重啟);
5)卸載安裝，安裝目錄清理，SD卡存儲數據不被清理；
6)在沒有更新或者網絡時，需要給予用戶正確的信息表達；
App的啟動與停止
1)首次啟動是否出現歡迎界面，可否進入App，停留時間是否合理;
2)首次啟動后拉取的信息是否正確;
3)再次啟動時間是否符合預期；
4)再次啟動app功能是否異常
5)再次啟動后狀態檢查：如初始化信息、初始狀態、啟動對網絡；
6)再次啟動進程服務檢查：進程名、進程數、服務名、服務數、第三方調用的SDK如GPS；
7)再次帶登陸的應用是否再次啟動的時候正常登錄；
8)出現崩潰是否可以再次啟動;
9)手動終止進程、服務是否可以在此啟動;
10)其他系統軟件工具停止進程、清理軟件數據，是否可以啟動；
中斷測試
1)鎖屏中斷：停留在程序操作界面進行鎖屏，恢復后檢查操作是否正常；
2)前后臺切換：停留在程序操作界面，通過Home鍵，進行程序的前后臺切換；
3)加載中斷：頁面接口請求、界面框架加載時，通過Home鍵、返回鍵、快速切換操作進行中斷；
4)系統異常中斷：如關機、斷電、來電；
流暢度
列表滑動、返回進入、快速點擊（這個肉眼不好評判，可以借助GT，一般打分在90分以上是比較好的）
軟件兼容
通用軟件；
輸入法；
安全軟件；
通信類；
競品軟件 同類軟件，是否出現沖突；
總結
移動應用根據技術架構的不同，主要分為 Web App、 App 和 App 三大類，這三類應用的測試方法本質上都屬于 GUI 測試的范疇。
從業務功能測試的角度看，移動應用的測試用例設計和傳統 PC 端的 GUI 自動化測試策略比較類似，只是測試框架不同，數據驅動、頁面對象模型和業務流程封裝依舊適用；
各種專項測試是移動應用的測試重點，也有別于傳統 GUI 測試。專項測試包括：交叉事件測試、兼容性測試、流量測試、耗電量測試、弱網絡測試和邊界測試;