移動 App 應用測試方法與思路

分析三種主流的移動 App 類型，并給出和普通web測試不同的地方，給出測試的思路，并給出部分場景組合。 附：安卓 App 測試常用 adb命令和 money 命令

移動端測試還是 PC 端測試，業務測試其實都屬于 GUI 測試的范疇，所以基本的測試思路，比如基于頁面對象封裝和基于業務流程封裝的思想是相通的。

三種移動端產品類型介紹

移動端應用的測試其自身特點，和其他傳統測試又有一些獨特的測試方法與思路。 移動端應用又可以進一步細分為三大類：

Web App 指的是移動端的 Web 瀏覽器， 其實和 PC 端的 Web 瀏覽器沒有任何區別，只不過Web 瀏覽器所依附的操作系統不再是 Windows 和 Linux 了，而是 iOS 和 Android 了。 Web App 采用的技術主要是，傳統的HTML、JavaScript、CSS等Web技術棧，當然 現在HTML5 也得到了廣泛的應用。另外，WebApp所訪問的頁面內容都是放在服務器端的，本質上就是 Web 網頁，所以天生就是跨平臺的。

Native App 指的是移動端的原生應用， 對于 Android 是 apk，對于 iOS 就是 ipa。NativeApp 是一種基于手機操作系統（iOS 和 Android），并使用原生程序編寫運行的第三方應用程序。 Native App 的開發，Android 使用的語言通常是 Java，iOS 使用的語言是 Objective-C。通常來說，Native App 可以提供比較好的用戶體驗以及性能，而且可以方便地操作手機本地資源。

Hybrid App，是介于 Web App 和 Native App 兩者之間的一種 App 形式。 Hybrid App 利用了 Web App 和 Native App 的優點，通過一個原生實現的 NativeContainer 展示HTML5的頁面。更通俗的講法可以歸結為，在原生移動應用中嵌入了Webview，然后通過該 Webview 來訪問網頁。 Hybrid App 具有維護更新簡單，用戶體驗優異以及較好的跨平臺特性，是目前主流的移動應用開發模式。

三類不同移動應用的測試方法

根據它們的特性來總結出它們的測試方法。

Web App，顯然其本質就是Web瀏覽器的測試，所有GUI自動化測試的方法和技術，比如數據驅動、頁面對象模型、業務流程封裝等，都適用于 Web App的測試。 如果Web 頁面是基于自適應網頁設計（即符合ResponsiveWeb設計的規范），而且測試框架如果支持 Responsive Page，那么原則上之前開發的運行在 PC Web 端的 GUI自動化測試用例，不做任何修改就可以直接在移動端的瀏覽器上直接執行，當然運行的前提是你的移動端瀏覽器必須支持WebDriver。其中，自適應網頁設計（Responsive Web Design）是指，同一個網頁能夠自動識別屏幕分辨率、并做出相應調整的網頁設計技術。

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 下。

web測試和app測試的區別：

相同點：WEB測試和App測試從流程上來說，沒有區別。都需要經歷測試計劃方案，用例設計，測試執行，缺陷管理，測試報告等相關活動。從技術上來說，WEB測試和APP測試其測試類型也基本相似，都需要進行功能測試、性能測試、安全性測試、GUI測試等測試類型。

不同點他們的主要區別在于具體測試的細節和方法有區別，

性能測試，在WEB測試只需要測試響應時間這個要素，在App測試中還需要考慮流量測試和耗電量測試。

兼容性測試：在WEB端是兼容瀏覽器，在App端兼容的是手機設備。而且相對應的兼容性測試工具也不相同，WEB因為是測試兼容瀏覽器，所以需要使用不同的瀏覽器進行兼容性測試（常見的是兼容IE6，IE8，chrome，firefox）如果是手機端，那么就需要兼容不同品牌，不同分辨率，不同android版本甚至不同操作系統的兼容。（常見的兼容方式是兼容市場占用率前N位的手機即可），有時候也可以使用到兼容性測試工具，但WEB兼容性工具多用IETester等工具，而App兼容性測試會使用Testin這樣的商業工具也可以做測試。

安裝測試：WEB測試基本上沒有客戶端層面的安裝測試，但是App測試是存在客戶端層面的安裝測試，那么就具備相關的測試點。

App測試基于手機設備，還有一些手機設備的專項測試。如交叉事件測試，操作類型測試，網絡測試（弱網測試，網絡切換）交叉事件測試：就是在操作某個軟件的時候，來電話、來短信，電量不足提示等外部事件。操作類型測試：如橫屏測試，手勢測試網絡測試：包含弱網和網絡切換測試。需要測試弱網所造成的用戶體驗，重點要考慮回退和刷新是否會造成二次提交。弱網絡的模擬，據說可以用360wifi實現設置。升級測試：升級測試的提醒機制，升級取消是否會影響原有功能的使用，升級后用戶數據是否被清除了。

從系統架構的層面，WEB測試只要更新了服務器端，客戶端就會同步會更新。而且客戶端是可以保證每一個用戶的客戶端完全一致的。但是APP端是不能夠保證完全一致的，除非用戶更新客戶端。如果是APP下修改了服務器端，意味著客戶端用戶所使用的核心版本都需要進行回歸測試一遍。

如此看來，移動端的測試除了使用的測試框架不同以外，測試設計本身和 GUI 測試有異曲同工之妙，對于移動端還應該有其他的不同測試思路和方法。

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

對于移動應用，順利完成全部業務功能測試往往是不夠的，當移動應用被大量用戶安裝和使用時，就會暴露出很多之前完全沒有預料到的問題， 比如：

流量使用過多；
耗電量過大；
在某些設備終端上出現崩潰或者閃退的現象；
多個移動應用相互切換后，行為異常；
在某些設備終端上無法順利安裝或卸載；
弱網絡環境下，無法正常使用；
Android 環境下，經常出現 ANR(Application Not Responding)；

… 這樣的問題還有很多，為了避免或減少此類情況的發生，所以移動應用除了進行常規的功能測試外，通常還會進行很多移動應用所特有的專項測試。

1. 交叉事件測試

交叉事件測試也叫中斷測試，是指 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+OpenST去搭建自己的移動設備私有云平臺外，其他公司一般都會使用第三方的移動設備云測平臺完成兼容性測試。第三方的移動設備云測平臺，國外最知名的是 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”來獲取應用的耗電量信息耗電測試中，Google推出的history batterian工具很好分析耗電情況；

iOS 通過 Apple 的官方工具 Sysdiagnose 來收集耗電量信息，然后，可以進一步通過Instrument 工具鏈中的 Energy Diagnostics 進行耗電量分析。

第五，弱網絡測試

與傳統桌面應用不同，移動應用的網絡環境比較多樣，而且經常出現需要在不同網絡之間切換的場景，即使是在同一網絡環境下，也會出現網絡連接狀態時好時壞的情況，比如時高時低的延遲、經常丟包、頻繁斷線，在乘坐地鐵、穿越隧道，和地下車庫的場景下經常會發生。

所以，移動應用的測試需要保證在復雜網絡環境下的質量。在測試階段，模擬這些網絡環境，在 App 發布前盡可能多地發現并修復問題。推薦開源移動網絡測試工具：Facebook Augmented TrafficControl（ATC）。

ATC 最好用的地方在于，它能夠在移動終端設備上通過Web界面隨時切換不同的網絡環境，同時多個移動終端設備可以連接到同一個Wifi，各自模擬不同的網絡環境，相互之間不會有任何影響。也就是說，只要搭建一套ATC就能滿足你所有的網絡模擬需求。

第六，邊界測試

邊界測試是指，移動 App在一些臨界狀態下的行為功能的驗證測試，基本思路是需要找出各種潛在的臨界場景，并對每一類臨界場景做驗證和測試。

主要的場景有：

系統內存占用大于 90% 的場景；
系統存儲占用大于 95% 的場景；
飛行模式來回切換的場景；
App不具有某些系統訪問權限的場景，比如App由于隱私設置不能訪問相冊或者通訊錄等；
長時間使用 App，系統資源是否有異常，比如內存泄漏、過多的鏈接數等；
出現 ANR 的場景；
操作系統時間早于或者晚于標準時間的場景；
時區切換的場景；

…

耗電量測試，流量測試，以及app性能測試，如何界定數據是否正常？例如流量消耗是到哪個值覺得有優化空間，內存CPU到哪個值不正常需要優化

其實并沒有明確的標準，主要基于一些歷史統計數據，主要的做法是和現有版本，以及同類app做比較。

結合一些實際情況測試點簡單組合下場景場景：

比如： 出現崩潰：

設備碎片化：由于設備極具多樣性，App在不同的設備上可能有表現不同;
帶寬限制：帶寬不佳的網絡對App所需的快速響應時間可能不夠;
網絡的變化：不同網絡間的切換可能會影響App的穩定性;
內存管理：可用內存過低，或非授權的內存位置的使用可能會導致App失敗;
用戶過多：連接數量過多可能會導致App崩潰;
代碼錯誤：沒有經過測試的新功能，可能會導致App在生產環境中失敗;
第三方服務：廣告或彈出屏幕可能會導致App崩潰;

App的安裝與卸載

就是其他web里邊沒有的場景，最基本的藥考慮不同操作系統，考慮不同的操作系統版本，考慮不同手機廠商再操作系統版本修改上的不同，等等

安裝過程中：

各個選項是否符合概要設計說明;
安裝向導的ui測試;
是否支持取消，以及取消后的操作流程（是否有殘留);
意外情況處理（司機、重啟、斷電、斷網）;
安裝空間不足

安裝完成后：

是否正常運行;
安裝過程后的文件夾和文件是否寫在了指定的目錄里邊;
是否生成了多余的目錄結構和文件;

升級：

升級后功能是否和需求說明一樣
測試與升級模塊相關的模塊的功能是否
升級界面的ui測試（強制/非強制）
升級安裝意外情況的測試（死機、重啟、斷電）
版本驗證：1.0版-2.0或者1.0-3.0
升級中用戶數據、設置、狀態的保留，注意新版本已去掉的狀態或設置；
是否可以隔開版本覆蓋安裝；
是否可以覆蓋安裝更低版本；
如果升級有忽略本次版本升級，那么當有新的升級版本時，是否還有提示升級；
大版本更新不升級無法使用；

卸載：

系統直接卸載以及卸載時候ui界面測試;
直接刪除文件夾，再卸載;
卸載過程中是否支持取消，取消后的軟件狀態;
卸載時候意外的情況處理（死機、斷網、斷電、重啟);
卸載安裝，安裝目錄清理，SD卡存儲數據不被清理；
在沒有更新或者網絡時，需要給予用戶正確的信息表達；

App的啟動與停止

首次啟動是否出現歡迎界面，可否進入App，停留時間是否合理;
首次啟動后拉取的信息是否正確;
再次啟動時間是否符合預期；
再次啟動app功能是否異常
再次啟動后狀態檢查：如初始化信息、初始狀態、啟動對網絡；
再次啟動進程服務檢查：進程名、進程數、服務名、服務數、第三方調用的SDK如GPS；
再次帶登陸的應用是否再次啟動的時候正常登錄；
出現崩潰是否可以再次啟動;
手動終止進程、服務是否可以在此啟動;
其他系統軟件工具停止進程、清理軟件數據，是否可以啟動；

中斷測試

鎖屏中斷：停留在程序操作界面進行鎖屏，恢復后檢查操作是否正常；
前后臺切換：停留在程序操作界面，通過Home鍵，進行程序的前后臺切換；
加載中斷：頁面接口請求、界面框架加載時，通過Home鍵、返回鍵、快速切換操作進行中斷；
系統異常中斷：如關機、斷電、來電；

流暢度 列表滑動、返回進入、快速點擊（這個肉眼不好評判，可以借助GT，一般打分在90分以上是比較好的）

軟件兼容 通用軟件； 輸入法； 安全軟件； 通信類； 競品軟件 同類軟件，是否出現沖突；

總結

移動應用根據技術架構的不同，主要分為 Web App、Native App 和 Hybrid App 三大類，這三類應用的測試方法本質上都屬于 GUI 測試的范疇。

從業務功能測試的角度看，移動應用的測試用例設計和傳統 PC 端的 GUI 自動化測試策略比較類似，只是測試框架不同，數據驅動、頁面對象模型和業務流程封裝依舊適用；

各種專項測試是移動應用的測試重點，也有別于傳統 GUI 測試。專項測試包括：交叉事件測試、兼容性測試、流量測試、耗電量測試、弱網絡測試和邊界測試;

---

附：ADB常用命令

adb connect+ip 遠程連接Android設備

adb devices 獲取設備列表和設備狀態

adb install apk路徑 安裝應用 -r 覆蓋安裝

adb uninstall apk包名 卸載應用 -k 卸載時保存數據和緩存目錄

adb pull 遠程路徑 本地路徑 將Android設備上的文件或者文件夾復制到本地

adb push 本地路徑 遠程路徑 將本地的文件或者文件夾復制到Android設備上

adb start-server 啟動adb服務進程

adb kill-server 關閉adb 服務進程

adb reboot 重啟設備

adb shell 進入模擬器的shell模式

adb logcat 查看log信息

adb logcat > d:log.txt 將log導出到d盤

adb shell logcat -b radio 查看無線通信日志

adb shell logcat -b radio > d:log.txt

adb version 查看adb命令版本號

adb help 查看adb幫助命令

adb shell pm list packages 查看設備中所有應用的包名

adb shell pm list packages -s 列出系統應用的所有包名

adb shell pm list packages -3 列出除了系統應用的第三方應用包名

adb shell 查看指定應用的包名

pm list packages|grep qq

adb shell pm clear 包名 清除指定應用的緩存

adb shell dumpsys meminfo 查看手機內存使用情況

adb shell dumpsys cpuinfo 查看cpu信息

adb shell dumpsys battery 查看電量信息

附：Monkey簡單實用方法

Monkey 就是SDK中附帶的一個工具。Monkey是Android中的一個命令行工具，可以運行在模擬器里或實際設備中。它向系統發送偽隨機的用戶事件流(如按鍵輸入、觸摸屏輸入、手勢輸入等)，實現對正在開發的應用程序進行壓力測試。Monkey測試是一種為了測試軟件的穩定性、健壯性的快速有效的方法。

該工具用于進行壓力測試。然后開發人員結合monkey打印的日志和系統打印的日志，分析測試中的問題

優點：

Monkey 測試,所有的事件都是隨機產生的，不帶任何人的主觀性。

缺點：

測試的對象僅為應用程序包，有一定的局限性。
Monky測試使用的事件數據流是隨機的，不能進行自定義。
可對MonkeyTest的對象，事件數量，類型，頻率等進行設置。

Monkey基本語法如下：

$ adb shell monkey [options]

如果不指定options，Monkey將以無反饋模式啟動，并把事件任意發送到安裝在目標環境中的全部包。下面是一個更為典型的命令行示例，

$ adb shell monkey -p your.package.name -v 500

它啟動指定的應用程序，并向其發送500個偽隨機事件： 使用android自動化測試工具monkeyrunner啟動應用時，需要填寫被測程序的包名和啟動的Activity。

使用monkey help 命令查看命令參數 C:Userschenfenping>adb shell monkey -help

1 參數： -p 用于約束限制，用此參數指定一個或多個包（Package，即App）。指定包之后，monkey將只允許系統啟動指定的APP,如果不指定包，將允許系統啟動設備中的所有APP.

指定一個包： adb shell monkey -p cn.emoney.acg 10

指定多個包：adb shell monkey -p cn.emoney.acg –p cn.emoney.wea -p cn.emoney.acg 100

不指定包：adb shell monkey 100

2 參數: -v 用于指定反饋信息級別（信息級別就是日志的詳細程度），總共分3個級別，分別對應的參數如下表所示：

日志級別 Level0

示例 adb shell monkey -p cn.emoney.acg –v 100 說明缺省值，僅提供啟動提示、測試完成和最終結果等少量信息

日志級別 Level 1

示例 adb shell monkey -p cn.emoney.acg –v -v 100 說明提供較為詳細的日志，包括每個發送到Activity的事件信息

日志級別 Level 2

示例 adb shell monkey -p cn.emoney.acg –v -v –v 100 說明最詳細的日志，包括了測試中選中/未選中的Activity信息

3 參數： -s

用于指定偽隨機數生成器的seed值，如果seed相同，則兩次Monkey測試所產生的事件序列也相同的。 Monkey 測試1：adb shell monkey -p cn.emoney.acg -s 10 100 Monkey 測試2：adb shell monkey -p cn.emoney.acg –s 10 100 兩次測試的效果是相同的，因為模擬的用戶操作序列（每次操作按照一定的先后順序所組成的一系列操作，即一個序列）是一樣的。

4 參數： --throttle<毫秒> 用于指定用戶操作（即事件）間的時延，單位是毫秒； adb shell monkey -p cn.emoney.acg --throttle 5000 100

在monkey測試中常用的命令組合有：

1、monkey -p com.yourpackage -v 500

簡單的輸出測試的信息。

2、monkey -p com.yourpackage -v -v 500

以深度為二級輸出測試信息。

3、monkey -p com.yourpackage -s 數字 -v 500

為隨機數的事件序列定一個值，若出現問題下次可以重復同樣的系列進行排錯。

4、monkey -p com.yourpackage -v --throttle 3000 500

為每一次執行一次有效的事件后休眠3000毫秒。

Monkey測試的一個實例

通過這個實例，我們能理解Monkey測試的步驟以及如何知道哪些應用程序能夠用Monkey進行測試。

Windows下（注：2—4步是為了查看我們可以測試哪些應用程序包，可省略）：

1、通過eclipse啟動一個Android的emulator

2、在命令行中輸入：adb devices查看設備連接情況

C:Documents and SettingsAdministrator>adb devices

List of devices attached

emulator-5554 device

3、在有設備連接的前提下，在命令行中輸入：adb shell 進入shell界面

C:Documents and SettingsAdministrator>adb shell

4、查看data/data文件夾下的應用程序包。注：我們能測試的應用程序包都在這個目錄下面

C:Documents and SettingsAdministrator>adb shell

# ls data/data

ls data/data

5、以com.android.calculator2作為對象進行MonkeyTest #monkey -p com.android.calculator2 -v 500

運行過程中，Emulator中的應用程序在不斷地切換畫面。

按照選定的不同級別的反饋信息，在Monkey中還可以看到其執行過程報告和生成的事件。

測試過程中，在輸出monkeylog的一個小錯誤

跑monkey的時候或者想抓程序log導出時，有時會提示：cannot create D:monkeytest.txt: read-only file system 為什么有時候可以有時候不可以？ 后來發現跟使用使用習慣不一樣，一會是先進入adb shell 再用命令，一會是直接命令進入。 進入adb shell后再用命令就會失敗~ 正確方法：退出shell或者執行命令時先不要進shell C:Documents and SettingsAdministrator>adb shell monkey -p 包名 -v 300 >e: ext.txt 進入adb shell后就相當于進入linux的root下面，沒有權限在里面創建文件~

關于Monkey測試結果分析基本步驟

一. Monkey測試出現錯誤后，一般的查錯步驟為以下幾步：

找到是monkey里面的哪個地方出錯

查看Monkey里面出錯前的一些事件動作，并手動執行該動作

若以上步驟還不能找出，可以使用之前執行的monkey命令再執行一遍，注意seed值要一樣--復現

二.一般的測試結果分析：

ANR問題：在日志中搜索“ANR”

崩潰問題：在日志中搜索“Exception” Force Close

三. 詳細分析monkey日志：

將執行Monkey生成的log，從手機中導出并打開查看該log；在log的最開始都會顯示Monkey執行的seed值、執行次數和測試的包名。

首先我們需要查看Monkey測試中是否出現了ANR或者異常，接下來要看文檔。找出錯誤點，然后打包給開發。

總結

以上是生活随笔為你收集整理的移动 App 应用测试方法与思路的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。