在我看來無論是移動端測試還是PC端測試，都屬於GUI測試的範疇，所以基本的測試思路，比如基於頁面對象封裝和基於業務流程封裝的思想是相通的，之前介紹的那些腳本分層的實現方法也都同樣適用於移動端的GUI測試。
與此同時，移動端應用的測試也會因爲其自身特點，有一些獨特的測試方法與思路。嚴格來講，移動端應用又可以進一步細分爲三大類：Web App、Native App和Hybrid App。所以，我今天分享的內容重點就是，這三類移動應用的測試方法，以及移動專項測試的思路與方法。
三類移動應用的特點
Web App指的是移動端的Web瀏覽器， 其實和PC端的Web瀏覽器沒有任何區別，只不過Web瀏覽器所依附的操作系統不再是Windows和Linux了，而是iOS和Android了。
Web App採用的技術主要是，傳統的HTML、JavaScript、CSS等Web技術棧，當然現在HTML5也得到了廣泛的應用。另外，Web App所訪問的頁面內容都是放在服務器端的，本質上就是Web網頁，所以天生就是跨平臺的。
Native App指的是移動端的原生應用， 對於Android是apk，對於iOS就是ipa。Native App是一種基於手機操作系統（iOS和Android），並使用原生程序編寫運行的第三方應用程序。
Native App的開發，Android使用的語言通常是Java，iOS使用的語言是Objective-C。通常來說，Native App可以提供比較好的用戶體驗以及性能，而且可以方便地操作手機本地資源。
Hybrid App（俗稱：混血應用），是介於Web App和Native App兩者之間的一種App形式。
Hybrid App利用了Web App和Native App的優點，通過一個原生實現的Native Container展示HTML5的頁面。更通俗的講法可以歸結爲，在原生移動應用中嵌入了Webview，然後通過該Webview來訪問網頁。
Hybrid App具有維護更新簡單，用戶體驗優異以及較好的跨平臺特性，是目前主流的移動應用開發模式。
圖2 三類移動應用的架構原理
三類不同移動應用的測試方法
瞭解了Web App、Native App和Hybrid App這三類應用的特性，接下來，我就跟你說說它們的測試方法。
好了，我們已經知道了移動應用的三個主要種類，接下來我們從測試的角度再來看看這三類不同的移動應用。
對於Web App，顯然其本質就是Web瀏覽器的測試，我在前面文章中介紹的所有GUI自動化測試的方法和技術，比如數據驅動、頁面對象模型、業務流程封裝等，都適用於Web App的測試。
如果你的Web頁面是基於自適應網頁設計（即符合Responsive Web設計的規範），而且你的測試框架如果支持Responsive Page，那麼原則上你之前開發的運行在PC Web端的GUI自動化測試用例，不做任何修改就可以直接在移動端的瀏覽器上直接執行，當然運行的前提是你的移動端瀏覽器必須支持Web Driver。
其中，自適應網頁設計（Responsive Web Design）是指，同一個網頁能夠自動識別屏幕分辨率、並做出相應調整的網頁設計技術。比如，圖3所示的例子就是同一個網頁在不同分辨率下的不同展示效果。
圖3 自適應網頁設計實例
對Native App的測試，雖然不同的平臺會使用不同的自動化測試方案（比如，iOS一般採用XCUITest Driver，而Android一般採用UiAutomator2或者Espresso等），但是數據驅動、頁面對象以及業務流程封裝的思想依舊適用，你完全可以把這些方法應用到測試用例設計中。
對Hybrid App的測試，情況會稍微複雜一點，對Native Container的測試，可能需要用到XCUITest或者UiAutomator2這樣的原生測試框架，而對Container中HTML5的測試，基本和傳統的網頁測試沒什麼區別，所以原本基於GUI的測試思想和方法都能繼續適用。
唯一需要注意的是，Native Container和Webview分別屬於兩個不同的上下文（Context），Native Container默認的Context爲“NATIVE APP"，而Webview默認的Context爲“WEBVIEW_+被測進程名稱”。
所以，當需要操作Webview中的網頁元素時，需要先切換到Webview的Context下，如圖4所示代碼就完成了這一切換操作。
圖4 Hybrid App中切換Context的代碼示例
如此看來，移動端的測試除了使用的測試框架不同以外，測試設計本身和GUI測試有異曲同工之妙，似乎並沒有什麼新的內容，那真的是這樣嗎？
答案顯然是否定的。
移動應用專項測試的思路和方法
對於移動應用，順利完成全部業務功能測試往往是不夠的。如果你的關注點只是業務功能測試，那麼，當你的移動應用被大量用戶安裝和使用時，就會暴露出很多之前完全沒有預料到的問題，比如：
- 流量使用過多；
- 耗電量過大；
- 在某些設備終端上出現崩潰或者閃退的現象；
- 多個移動應用相互切換後，行爲異常；
- 在某些設備終端上無法順利安裝或卸載；
- 弱網絡環境下，無法正常使用；
- Android環境下，經常出現ANR(Application Not Responding)；
- …
這樣的問題還有很多，爲了避免或減少此類情況的發生，所以移動應用除了進行常規的功能測試外，通常還會進行很多移動應用所特有的專項測試。
今天這篇文章，我就從交叉事件測試、兼容性測試、流量測試、耗電量測試、弱網絡測試、邊界測試這6個最主要的專項測試來展開。
第一，交叉事件測試
交叉事件測試也叫中斷測試，是指App執行過程中，有其他事件或者應用中斷當前應用執行的測試。
比如，App在前臺運行過程中，突然有電話打進來，或者收到短信，再或者是系統鬧鐘等等情況。所以，在App測試時，就需要把這些常見的中斷情況考慮在內，並進行相關的測試。
注意，此類測試目前基本還都是採用手工測試的方式，並且都是在真機上進行，不會使用模擬器。
首先，採用手工測試的原因是，此類測試往往場景多，而且很多事件很難通過自動化的方式來模擬，比如呼入電話、接收短信等，這些因素都會造成自動化測試的成本過高，得不償失，所以工程實踐中，交叉事件測試往往全是基於手工的測試。
其次，之所以採用真機，是因爲很多問題只會在真機上才能重現，採用模擬器測試沒有意義。
交叉事件測試，需要覆蓋的場景主要包括：
- 多個App同時在後臺運行，並交替切換至前臺是否影響正常功能；
- 要求相同系統資源的多個App前後臺交替切換是否影響正常功能，比如兩個App都需要播放音樂，那麼兩者在交替切換的過程中，播放音樂功能是否正常；
- App運行時接聽電話；
- App運行時接收信息；
- App運行時提示系統升級；
- App運行時發生系統鬧鐘事件；
- App運行時進入低電量模式；
- App運行時第三方安全軟件彈出告警；
- App運行時發生網絡切換，比如，由Wifi切換到移動4G網絡，或者從4G網絡切換到3G網絡等；
- …
其實你可以發現，這些需要覆蓋的場景，也是我們今後測試的測試用例集，每一場景都是一個測試用例的集合。
第二，兼容性測試
兼容性測試顧名思義就是，要確保App在各種終端設備、各種操作系統版本、各種屏幕分辨率、各種網絡環境下，功能的正確性。常見的App兼容性測試往往需要覆蓋以下的測試場景：
- 不同操作系統的兼容性，包括主流的Andoird和iOS版本；
- 主流的設備分辨率下的兼容性；
- 主流移動終端機型的兼容性；
- 同一操作系統中，不同語言設置時的兼容性；
- 不同網絡連接下的兼容性，比如Wifi、GPRS、EDGE、CDMA200等；
- 在單一設備上，與主流熱門App的兼容性，比如微信、抖音、淘寶等；
- …
兼容性測試，通常都需要在各種真機上執行相同或者類似的測試用例，所以往往採用自動化測試的手段。 同時，由於需要覆蓋大量的真實設備，除了大公司會基於Appium + Selenium Grid + OpenSTF去搭建自己的移動設備私有云平臺外，其他公司一般都會使用第三方的移動設備雲測平臺完成兼容性測試。
第三方的移動設備雲測平臺，國外最知名的是SauceLab，國內主流的是Testin。
第三，流量測試
由於App經常需要在移動互聯網環境下運行，而移動互聯網通常按照實際使用流量計費，所以如果你的App耗費的流量過多，那麼一定不會很受歡迎。
流量測試，通常包含以下幾個方面的內容：
- App執行業務操作引起的流量；
- App在後臺運行時的消耗流量；
- App安裝完成後首次啓動耗費的流量；
- App安裝包本身的大小；
- App內購買或者升級需要的流量。
流量測試，往往藉助於Android和iOS自帶的工具進行流量統計，也可以利用tcpdump、Wireshark和Fiddler等網絡分析工具。
對於Android系統，網絡流量信息通常存儲在/proc/net/dev目錄下，也可以直接利用ADB工具獲取實時的流量信息。另外，我還推薦一款Android的輕量級性能監控小工具Emmagee，類似於Windows系統性能監視器，能夠實時顯示App運行過程中CPU、內存和流量等信息。
對於iOS系統，可以使用Xcode自帶的性能分析工具集中的Network Activity，分析具體的流量使用情況。
但是，流量測試的最終目的，並不是得到App的流量數據，而是要想辦法減少App產生的流量。雖然，減少App消耗的流量不是測試工程師的工作，但瞭解一些常用的方法，也將有助於你的測試日常工作：
- 啓用數據壓縮，尤其是圖片；
- 使用優化的數據格式，比如同樣信息量的JSON文件就要比XML文件小；
- 遇到既需要加密又需要壓縮的場景，一定是先壓縮再加密；
- 減少單次GUI操作觸發的後臺調用數量；
- 每次回傳數據儘可能只包括必要的數據；
- 啓用客戶端的緩存機制；
- …
第四，耗電量測試
耗電量也是一個移動應用能否成功的關鍵因素之一。
在目前的生態環境下，能提供類似服務或者功能的App往往有很多，如果在功能類似的情況下，你的App特別耗電、讓設備發熱比較嚴重，那麼你的用戶一定會卸載你的App而改用其他App。最典型的就是地圖等導航類的應用，對耗電量特別敏感。
耗電量測試通常從三個方面來考量：
- App運行但沒有執行業務操作時的耗電量；
- App運行且密集執行業務操作時的耗電量；
- App後臺運行的耗電量。
耗電量檢測既有基於硬件的方法，也有基於軟件的方法。我所經歷過的項目都是採用軟件的方法，Android和iOS都有各自自己的方法：
- Android通過adb命令“adb shell dumpsys battery”來獲取應用的耗電量信息；
- iOS通過Apple的官方工具Sysdiagnose來收集耗電量信息，然後，可以進一步通過Instrument工具鏈中的Energy Diagnostics進行耗電量分析。
第五，弱網絡測試
與傳統桌面應用不同，移動應用的網絡環境比較多樣，而且經常出現需要在不同網絡之間切換的場景，即使是在同一網絡環境下，也會出現網絡連接狀態時好時壞的情況，比如時高時低的延遲、經常丟包、頻繁斷線，在乘坐地鐵、穿越隧道，和地下車庫的場景下經常會發生。
所以，移動應用的測試需要保證在複雜網絡環境下的質量。具體的做法就是：在測試階段，模擬這些網絡環境，在App發佈前儘可能多地發現並修復問題。
在這裏，我推薦一款非常棒的開源移動網絡測試工具：Facebook的Augmented Traffic Control（ATC）。
ATC最好用的地方在於，它能夠在移動終端設備上通過Web界面隨時切換不同的網絡環境，同時多個移動終端設備可以連接到同一個Wifi，各自模擬不同的網絡環境，相互之間不會有任何影響。也就是說，只要搭建一套ATC就能滿足你所有的網絡模擬需求。
如果你對ATC感興趣，可以在它的官方網站找到詳細的使用說明。
第六，邊界測試
邊界測試是指，移動App在一些臨界狀態下的行爲功能的驗證測試，基本思路是需要找出各種潛在的臨界場景，並對每一類臨界場景做驗證和測試。 主要的場景有：
- 系統內存佔用大於90%的場景；
- 系統存儲佔用大於95%的場景；
- 飛行模式來回切換的場景；
- App不具有某些系統訪問權限的場景，比如App由於隱私設置不能訪問相冊或者通訊錄等；
- 長時間使用App，系統資源是否有異常，比如內存泄漏、過多的鏈接數等；
- 出現ANR的場景；
- 操作系統時間早於或者晚於標準時間的場景；
- 時區切換的場景；
- …
總結
好了，最後我來總結一下今天的主要的知識點：
移動應用根據技術架構的不同，主要分爲Web App、Native App和Hybrid App三大類，這三類應用的測試方法本質上都屬於GUI測試的範疇。
從業務功能測試的角度看，移動應用的測試用例設計和傳統PC端的GUI自動化測試策略比較類似，只是測試框架不同，數據驅動、頁面對象模型和業務流程封裝依舊適用；
各種專項測試是移動應用的測試重點，也有別於傳統GUI測試。專項測試包括：交叉事件測試、兼容性測試、流量測試、耗電量測試、弱網絡測試和邊界測試。