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

摘要： 分析三種主流的移動 App 型別，並給出和普通web測試不同的地方，給出測試的思路，並給出部分場景組合。 附：安卓 App 測試常用 adb命令和 money 命令 移動端測試還是 PC 端測試，業務測試其實都屬於 GUI 測試的範疇，所以基本的測試思路，比如基於頁面物件封裝和基於業務流程...

分析三種主流的移動 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 dumpsysbattery”來獲取應用的耗電量資訊耗電測試中，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 10100 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 -v500

以深度為二級輸出測試資訊。

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 Settings\Administrator>adb devices

List of devices attached

emulator-5554device

3、在有裝置連線的前提下，在命令列中輸入：adb shell 進入shell介面

C:\Documents and Settings\Administrator>adb shell

4、檢視data/data資料夾下的應用程式包。注：我們能測試的應用程式包都在這個目錄下面

C:\Documents and Settings\Administrator>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 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或者異常，接下來要看文件。找出錯誤點，然後打包給開發。