移動 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:\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測試中常用的命令組合有：
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 Settings\Administrator>adb devices
List of devices attached
emulator-5554 device
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測試出現錯誤後，一般的查錯步驟為以下幾步：
-
找到是monkey裡面的哪個地方出錯
-
檢視Monkey裡面出錯前的一些事件動作，並手動執行該動作
-
若以上步驟還不能找出，可以使用之前執行的monkey命令再執行一遍，注意seed值要一樣--復現
二.一般的測試結果分析：
-
ANR問題：在日誌中搜尋“ANR”
-
崩潰問題：在日誌中搜尋“Exception” Force Close
三. 詳細分析monkey日誌：
將執行Monkey生成的log，從手機中匯出並開啟檢視該log；在log的最開始都會顯示Monkey執行的seed值、執行次數和測試的包名。
首先我們需要檢視Monkey測試中是否出現了ANR或者異常，接下來要看文件。找出錯誤點，然後打包給開發。