移動應用專項測試的思路和方法
對於移動應用，順利完成全部業務功能測試往往是不夠的。如果你的關註點只是業務功能測試，那麽， 當你的移動應用被大量用戶安裝和使用時，就會暴露出很多之前完全沒有預料到的問題，比如：
流量使用過多；
耗電量過大；
在某些設備終端上出現崩潰或者閃退的現象；
多個移動應用相互切換後，行為異常；
在某些設備終端上無法順利安裝或卸載；
弱網絡環境下，無法正常使用；
Android環境下，經常出現ANR(Application Not Responding)； …
這樣的問題還有很多，為了避免或減少此類情況的發生，所以移動應用除了進行常規的功能測試外，通 常還會進行很多移動應用所特有的專項測試。
第一，交叉事件測試
交叉事件測試也叫中斷測試，是指App執行過程中，有其他事件或者應用中斷當前應用執行的測試。
比如，App在前臺運行過程中，突然有電話打進來，或者收到短信，再或者是系統鬧鐘等等情況。所 以，在App測試時，就需要把這些常見的中斷情況考慮在內，並進行相關的測試。
註意，此類測試目前基本還都是采用手工測試的方式，並且都是在真機上進行，不會使用模擬器。
首先，采用手工測試的原因是，此類測試往往場景多，而且很多事件很難通過自動化的方式來模擬，比 如呼入電話、接收短信等，這些因素都會造成自動化測試的成本過高，得不償失，所以工程實踐中，交 叉事件測試往往全是基於手工的測試。
交叉事件測試，需要覆蓋的場景主要包括：
多個App同時在後臺運行，並交替切換至前臺是否影響正常功能； 要求相同系統資源的多個App前後臺交替切換是否影響正常功能，比如兩個App都需要播放音樂，那 麽兩者在交替切換的過程中，播放音樂功能是否正常； App運行時接聽電話； App運行時接收信息； App運行時提示系統升級； App運行時發生系統鬧鐘事件； App運行時進入低電量模式； App運行時第三方安全軟件彈出告警； App運行時發生網絡切換，比如，由Wif切換到移動4G網絡，或者從4G網絡切換到3G網絡等； …
第二，兼容性測試
兼容性測試顧名思義就是，要確保App在各種終端設備、各種操作系統版本、各種屏幕分辨率、各種網 絡環境下，功能的正確性。常見的App兼容性測試往往需要覆蓋以下的測試場景：
不同操作系統的兼容性，包括主流的Andoird和iOS版本； 主流的設備分辨率下的兼容性； 主流移動終端機型的兼容性； 同一操作系統中，不同語言設置時的兼容性； 不同網絡連接下的兼容性，比如Wif、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 Traffc Control（ATC ）。
ATC 最好用的地方在於，它能夠在移動終端設備上通過Web界面隨時切換不同的網絡環境，同時多個移 動終端設備可以連接到同一個Wif，各自模擬不同的網絡環境，相互之間不會有任何影響。也就是說， 只要搭建一套ATC 就能滿足你所有的網絡模擬需求。
如果你對ATC 感興趣，可以在它的官方網站找到詳細的使用說明。
第六，邊界測試
邊界測試是指，移動App在一些臨界狀態下的行為功能的驗證測試，基本思路是需要找出各種潛在的臨 界場景，並對每一類臨界場景做驗證和測試。 主要的場景有：
系統內存占用大於90%的場景； 系統存儲占用大於95%的場景； 飛行模式來回切換的場景； App不具有某些系統訪問權限的場景，比如App由於隱私設置不能訪問相冊或者通訊錄等； 長時間使用App，系統資源是否有異常，比如內存泄漏、過多的鏈接數等； 出現ANR的場景； 操作系統時間早於或者晚於標準時間的場景； 時區切換的場景；
移動應用專項測試的思路和方法