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

【轉載】

移動 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 測試有殊途同歸之妙，對於移動端還應該有其餘的不一樣測試思路和方法。

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

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

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

… 這樣的問題還有不少，爲了不或減小此類狀況的發生，因此移動應用除了進行常規的功能測試外，一般還會進行不少移動應用所特有的專項測試。

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 網絡等；

… 其實你能夠發現，這些須要覆蓋的場景，也是咱們從此測試的測試用例集，每一場景都是一個測試用例的集合。

第二，兼容性測試

兼容性測試顧名思義就是，要確保App在各類終端設備、各類操做系統本、各類屏幕分辨率、各類網絡環境下，功能的正確性。常見的App兼容性測試每每須要覆蓋如下的測試場景：

1. 不一樣操做系統的兼容性，包括主流的 Andoird 和 iOS 版本；
2. 主流的設備分辨率下的兼容性；
3. 主流移動終端機型的兼容性；
4. 同一操做系統中，不一樣語言設置時的兼容性；
5. 不一樣網絡鏈接下的兼容性，好比 Wifi、GPRS、EDGE、CDMA200 等；
6. 在單一設備上，與主流熱門 App 的兼容性，好比微信、抖音、淘寶等；

…

兼容性測試一般都須要在各類真機上執行相同或者相似的測試用例，因此每每採用自動化測試的手段。 同時，因爲須要覆蓋大量的真實設備，除了大公司會基於 Appium + Selenium Grid+OpenST去搭建本身的移動設備私有云平臺外，其餘公司通常都會使用第三方的移動設備雲測平臺完成兼容性測試。第三方的移動設備雲測平臺，國外最知名的是 SauceLab，國內主流的是Testin。

第三，流量測試

因爲 App 常常須要在移動互聯網環境下運行，而移動互聯網一般按照實際使用流量計費，因此若是你的App耗費的流量過多，第一會致使用戶流量費用增長，第二會會致使功能加載緩慢。

流量測試，一般包含如下幾個方面的內容：

1. App 執行業務操做引發的流量；
2. App 在後臺運行時的消耗流量；
3. App 安裝完成後首次啓動耗費的流量；
4. App 安裝包自己的大小；
5. App 內購買或者升級須要的流量;

…

流量測試，每每藉助於 Android 和 iOS 自帶的工具進行流量統計，也能夠利用 tcpdump、Wireshark 和 Fiddler 等網絡分析工具。

對於 Android 系統，網絡流量信息一般存儲在/proc/net/dev目錄下，也能夠直接利用 ADB工具獲取實時的流量信息。Android的輕量級性能監控小工具Emmagee，相似於 Windows 系統性能監視器，可以實時顯示App運行過程當中CPU、內存和流量等信息。

對於 iOS 系統，可使用 Xcode 自帶的性能分析工具集中的 Network Activity，分析具體的流量使用狀況。

可是，流量測試的最終目的，並非獲得 App 的流量數據，而是要想辦法減小 App 產生的流量。減小App消耗的流量不是測試工程師的工做，但瞭解一些經常使用的 方法，也將有助於你的測試平常工做：

1. 啓用數據壓縮，尤爲是圖片；
2. 使用優化的數據格式，好比一樣信息量的 JSON 文件就要比 XML 文件小；
3. 遇到既須要加密又須要壓縮的場景，必定是先壓縮再加密；
4. 減小單次 GUI 操做觸發的後臺調用數量；
5. 每次回傳數據儘量只包括必要的數據；
6. 啓用客戶端的緩存機制；

…

第四，耗電量測試

耗電量也是一個移動應用可否成功的關鍵因素之一。在目前的生態環境下，能提供相似服務或者功能的 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在一些臨界狀態下的行爲功能的驗證測試，基本思路是須要找出各類潛在的臨界場景，並對每一類臨界場景作驗證和測試。

主要的場景有：

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、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 測試,全部的事件都是隨機產生的，不帶任何人的主觀性。

缺點：

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

Monkey基本語法以下：

$ adb shell monkey [options]

若是不指定options，Monkey將以無反饋模式啓動，並把事件任意發送到安裝在目標環境中的所有包。下面是一個更爲典型的命令行示例，

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

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

使用monkey help 命令查看命令參數 C:\Users\chenfenping>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測試中經常使用的命令組合有：

一、monkey -p com.yourpackage -v 500

簡單的輸出測試的信息。

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

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

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

爲隨機數的事件序列定一個值，若出現問題下次能夠重複一樣的系列進行排錯。

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

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

Monkey測試的一個實例

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

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

一、經過eclipse啓動一個Android的emulator

二、在命令行中輸入：adb devices查看設備鏈接狀況

C:\Documents and Settings\Administrator>adb devices

List of devices attached

emulator-5554 device

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

C:\Documents and Settings\Administrator>adb shell

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

C:\Documents and Settings\Administrator>adb shell

# ls data/data

ls data/data

五、以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 Settings\Administrator>adb shell monkey -p 包名 -v 300 >e:\text.txt 進入adb shell後就至關於進入linux的root下面，沒有權限在裏面建立文件~

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

一. Monkey測試出現錯誤後，通常的查錯步驟爲如下幾步：

1. 找到是monkey裏面的哪一個地方出錯

2. 查看Monkey裏面出錯前的一些事件動做，並手動執行該動做

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

二.通常的測試結果分析：

1. ANR問題：在日誌中搜索「ANR」

2. 崩潰問題：在日誌中搜索「Exception」 Force Close

三. 詳細分析monkey日誌：

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

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

 

做者：友臺連接：https://juejin.im/post/5cb2d09ee51d456e2d69a75d來源：掘金著做權歸做者全部。商業轉載請聯繫做者得到受權，非商業轉載請註明出處。