移動應用專項測試的思路和方法

對於移動應用，順利完成所有業務功能測試每每是不夠的。若是你的關注點只是業務功能測試，那麼， 當你的移動應用被大量用戶安裝和使用時，就會暴露出不少以前徹底沒有預料到的問題，好比：
流量使用過多；

耗電量過大；

在某些設備終端上出現崩潰或者閃退的現象；

多個移動應用相互切換後，行爲異常；

在某些設備終端上沒法順利安裝或卸載；

弱網絡環境下，沒法正常使用；

Android環境下，常常出現ANR(Application Not Responding)； …
這樣的問題還有不少，爲了不或減小此類狀況的發生，因此移動應用除了進行常規的功能測試外，通 常還會進行不少移動應用所特有的專項測試。
今天這篇文章，我就從交叉事件測試、兼容性測試、流量測試、耗電量測試、弱網絡測試、邊界測試 這6個最主要的專項測試來展開。

第一，交叉事件測試

交叉事件測試也叫中斷測試，是指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的場景； 操做系統時間早於或者晚於標準時間的場景； 時區切換的場景；