1. 簡介
1.1 概要
AppCrawler 是由霍格沃茲測試學院校長思寒開源的一個項目,通過名字我們大概也能猜出個方向，Crawler 是爬蟲的意思，App 的爬蟲，遍歷 App ：
官方 GitHub 上對這款工具的解釋是：
一個基於自動遍歷的 App 爬蟲工具。支持 Android 和 iOS，支持真機和模擬器。最大的特點是靈活性，可通過配置來設定遍歷的規則。
這里順便提一下的是谷歌也發布了一款自動遍歷的工具，名字幾乎一樣，叫做 App Crawler (差了一個空格)，設計的思想也一致，但是這款工具目前還在開發完善中，思寒大佬的工具比谷歌的早了兩年時間，厲害啊！
下面來看看 AppCrawler 的作用和價值。
1.2 需求背景
互聯網的業務需求背景：
- 業務變更快速
- 業務線眾多
- 業務流程復雜
- 依賴第三方接口較多
測試工作常見問題：
- UI 自動化只能覆蓋核心業務邏輯，新功能來不及上自動化
- 產品業務測試量較大，新版發布后，老功能來不及全面回歸，容易漏測
- 時間長，強度大的工作后，人容易產生疲乏，對數字的位數，文字的顯示等錯誤信息的敏感度下降
- 產品的界面深度很深，且包含大量的展示信息功能
- 專項測試回歸難度大：內存泄漏、健壯性測試、弱網等測試太多
這個時候我們需要一種手段，可以達到兩方面的目的：
- Code less: UI 自動化用例維護成本降到最低
- Automate: 盡可能的自動化覆蓋回歸業務
而自動遍歷就可以滿足我們對上述的業務的需求；接着再來看我們對自動遍歷測試的一些需求，既然要用自動遍歷，那么具體要等到什么樣的效果？
2. 工具選擇
2.1 遍歷工具需求
自動遍歷的需求：
- 可控：可以定義遍歷的路徑，指定需要測試的業務，保證核心業務的覆蓋優先級
- 可定制：可實現自動輸入、自動滑動等基礎行為
結果分析：
- 點擊前后的截圖對比
- 結果的數據建模
2.2 工具對比
2.2.1 Monkey
首先來看業界用的較早也是經常聽過的一款工具—— Monkey
這是 Android 官方提供的一個工具，在 Android 的官網我們可以看到對這款工具的解釋如下：
沒錯，谷歌原本設計這款工具是為了對 App 進行壓力測試的，而並不是自動遍歷測試，注意的是這里的壓力測試並不是我們平常意義上的對服務端的壓力，而是對 App 前端的壓力。下面是思寒對 App 壓力測試的原因解釋：
谷歌早期在設計 Android 的時候，Android 需要響應滑動、輸入、音量、電話等事件，早期 activity 設計不完善的時候，谷歌希望測試 activity 的性能，把所有的數據批量化的輸出給 activity，看 activity 一秒鍾可以處理多少數據。所以早期 Monkey 是用來做 Android 的一個壓力測試的工具。
由於 Monkey 在測試過程中的“隨機”性，恰巧可以被用來做自動遍歷測試，但是 monkey 的缺點行業很明顯，就是不滿足我們的兩個自動遍歷需求：可控性和可定制。
- 缺點：不支持業務行為定制，無法靈活的控制，經常會點到外部的 App 無法回歸原測試 App；或者點擊到注銷和退出，造成無法繼續后面的測試；因此 monkey 在經過調研了解后沒有成為我們做自動遍歷測試的首選。
2.2.2 Maxim
Maxim 也是一款自動遍歷工具，由我們國內的一名叫做 zhangzhao 的工程師開發，官方給出的定義是：
An efficient Android Monkey Tester, available for emulators and real devices 基於遍歷規則的高性能 Android Monkey，適用於真機/模擬器的 APP UI 壓力測試。
我們來看看這款工具的優缺點：
優點：
- 基於Monkey二次開發，也用了一些 AppCrawler 的設計思路，擁有定制化功能；
- 因為底層基於了 Monkey，所以運行速度還是比較快的；
缺點：
- 因為是基於 Monkey，所以不具備跨平台性，只能測試 Android，不能測試 iOS，Web 等；
這款工具沒有開源，但是可以直接使用，在 GitHub 上下載后根據官方說明操作即可，這里不做重點說明，后期有空時候專門研究，獨立成篇，或者直接參考作者在 TesterHome 上的帖子；
重點來看一下工具的特點和選擇性：
- 配置文件，官方給出了配置文件的示例，以 json 格式進行編寫：
接觸過 AppCrawler 后會發現寫法非常相似，只不過 AppCrawler 是以 YAML 文件進行書寫。
選擇：
這也是一款很優秀的工具，可在一定程度上進行定制，如果只測試 Android 系統的話，可以考慮選用 Maxim 做自動遍歷，速度相對較快；如果想要跨平台或者對開源工具進行二次開發，那就要 AppCrawler 登場了。
2.2.3 AppCrawler
再來看今天的主角 AppCrawler，看看它為何滿足我們的測試需求，它的優缺點有在哪里。
先來看它與其他框架的關系結構
- 與其他框架的關系
優點：
- 跨平台性：AppCrawler 是基於 Appium 開發的，所以支持 Android 和 iOS。
- 可控性：對測試的頁面，控件類型的選擇，測試的深度等都可自由控制；
- 可定制：可自定義操作，如輸入，滑動等；
缺點：
- 運行速度較慢：AppCrawler 是基於 Appium 開發具備了跨平台的優點，但是也因為這層封裝造成了運行速度相對較慢；
- 使用門檻高：正因為使用靈活性的問題，也造成了使用門檻的提高，主要基於 YAML 文件中使用 Appium 的相關技術知識進行配置，這就對使用者有了一定的技術要求；
安裝和啟動
3.1 下載
這里以目前最新的2.4.0為例
如何自己編譯打包：
1）從 GitHub 上 Clone 源碼，當前開源的最新 2.4.0 版本對應的分支是 2.3.1
2）切換到分支：git checkout 2.3.1
3）執行 mvn clean compile
4）使用 maven 構建：執行 mvn assembly:single 命令進行編譯即可
安裝 ：
AppCrawler 本身是個 jar 包，不需要安裝，需要安裝的是運行時所依賴的環境：
Java版本：Java8、Java10 (未測試過，作者說支持)
Appium：Appium 1.8 以上 因為 AppCrawler 是基於 Appium 開發的，
所以 Appium 的環境是必不可少的Appium的安裝方式可參考另外一篇博客: Windows (Win10)、Mac 下安裝 Appium；
查看幫助文檔：
直接使用命令 java -jar appcrawler-2.4.0-jar-with-dependencies.jar，可以看到如下幫助文檔信息 相關參數含義和部分注解如下：
$ java -jar appcrawler-2.4.0-jar-with-dependencies.jar
----------------
AppCrawler 2.4.0 [霍格沃茲測試學院特別紀念版]
Appium 1.8.1 Java8 tested
app爬蟲, 用於自動遍歷測試. 支持Android和iOS, 支持真機和模擬器
項目地址: https://github.com/seveniruby/AppCrawler
移動測試技術交流: https://testerhome.com
聯絡作者: seveniruby@testerhome.com (思寒)
致謝: 曉光 泉龍 楊榕 恆溫 mikezhou yaming116 沐木
--------------------------------
Usage: appcrawler [options]
-a, --app <value> Android或者iOS的文件地址, 可以是網絡地址, 賦值給appium的app選項 #安裝App，實際中使用較少
-e, --encoding <value> set encoding, such as UTF-8 GBK #在Windows下可能會產生亂碼，對其編碼格式進行設置
-c, --conf <value> 配置文件地址 #復雜且重要，是AppCrawler定制的核心
-p, --platform <value> 平台類型android或者ios, 默認會根據app后綴名自動判斷
-t, --maxTime <value> 最大運行時間. 單位為秒. 超過此值會退出. 默認最長運行3個小時
-u, --appium <value> appium的url地址 #運行依賴於appium，不加此參數就使用默認的appium地址端口
-o, --output <value> 遍歷結果的保存目錄. 里面會存放遍歷生成的截圖, 思維導圖和日志
--capability k1=v1,k2=v2... # 和appium的capability設置一致
appium capability選項, 這個參數會覆蓋-c指定的配置模板參數, 用於在模板配置之上的參數微調
-r, --report <value> 輸出html和xml報告
--template <value> 輸出代碼模板
--master <value> master的diff.yml文件地址
--candidate <value> candidate環境的diff.yml文件
--diff 執行diff對比
-vv, --verbose 是否展示更多debug信息
--demo 生成demo配置文件學習使用方法
--help
示例
appcrawler -a xueqiu.apk
appcrawler -a xueqiu.apk --capability noReset=true
appcrawler -c conf/xueqiu.json -p android -o result/
appcrawler -c xueqiu.json --capability udid=[你的udid] -a Snowball.app
appcrawler -c xueqiu.json -a Snowball.app -u 4730
appcrawler -c xueqiu.json -a Snowball.app -u http://127.0.0.1:4730/wd/hub
#生成demo例子
appcrawler --demo
#啟動已經安裝過的app
appcrawler --capability "appPackage=com.xueqiu.android,appActivity=.view.WelcomeActivityAlias"
#從已經結束的結果中重新生成報告
appcrawler --report result/
#新老版本對比
appcrawler --candidate result/ --master pre/ --report ./這里順便說一下的是當前版本的diff功能還不完善，也相對較復雜，目前先不做深入研究
Quick Start：
1） 啟動appium
$ appium
[Appium] Welcome to Appium v1.14.1
[Appium] Appium REST http interface listener started on 0.0.0.0:47232）啟動模擬器或真機，保證 adb devices 可有找到你的設備
$ adb devices
List of devices attached
FKFBB19120151100 device3） 根據參考文檔中的命令,啟動遍歷一個已經安裝過的 App (以示例中的雪球 App 為例):
java -jar appcrawler-2.4.0-jar-with-dependencies.jar --capability
"appPackage=com.xueqiu.android,appActivity=.view.WelcomeActivityAlias"這個命令執行后會以默認的方式去執行用例,然后遍歷
- 遍歷原則：它的遍歷原則是，找頁面的里層次最深的元素，也就是處於中心位置元素會被優先遍歷
- 部分遍歷效果展示：
測試結果
如果沒有使用 -o 參數指定 log 輸出的路徑，AppCrawler 就會在當前目錄下生成以時間為命名的文件夾，里面保存了所有的數據，文件、截圖、log
$ ls
20191129154742
appcrawler-2.4.0-jar-with-dependencies.jar打開文件夾會發現如下，每一步都會進行截圖(這也是速度變慢的原因之一吧)以及對於的 dom 文件，這里會看到有幾個 steps 文件，這個只是隨意點了某個操作來告知用戶正在操作，真正的執行步驟是從這之后開始。
- 測試報告在測試 log 中有一個 index.html 文件，打開它會看到剛才運行的測試報告，AppCrawler 會把每一次點擊當做一個測試用例，沒一個頁面當做是一個測試套件；將界面和界面內的控件點擊模擬成了測試套件和測試用例的關系；
成功的用 Succeed 表示，Canceled 是遍歷的時候發現有這個可點擊的控件，但是最后卻沒遍歷到的控件。
報告中也可以查看對應頁面操作事件的截圖
- 測試 log在生成的文件夾中有 appcrawler.log，里面記錄了詳細的執行步驟的 log 信息(加上 -vv 參數運行的話會得到更多更多的 log 信息)
截取部分 log 展示如下：
2019-11-29 15:48:10 INFO [Crawler.996.doElementAction] current element = MainActivity.tag=ImageView.depth=24
2019-11-29 15:48:10 INFO [Crawler.997.doElementAction] current index = 2
2019-11-29 15:48:10 INFO [Crawler.998.doElementAction] current action = click
2019-11-29 15:48:10 INFO [Crawler.999.doElementAction] current xpath = //*[@resource-id="com.xueqiu.android:id/decor_content_parent"]//*[@resource-id="android:id/content"]//*[@resource-
id="com.xueqiu.android:id/mainContent"]//*[@resource-id="com.xueqiu.android:id/main_content"]//*[@resource-
id="com.xueqiu.android:id/pager"]//*[@resource-id="com.xueqiu.android:id/layout_refresh"]//*[@resource-
id="com.xueqiu.android:id/list"]//*[@resource-id="com.xueqiu.android:id/today_topic_container"]//*[@resource-
id="com.xueqiu.android:id/time_line_topic_item_case2"]//*[@resource-
id="com.xueqiu.android:id/today_topic_container"]//*[@resource-
id="com.xueqiu.android:id/time_line_topic_footer"]//*[@resource-id="com.xueqiu.android:id/feedback"]
2019-11-29 15:48:10 INFO [Crawler.1000.doElementAction] current url = MainActivity
2019-11-29 15:48:10 INFO [Crawler.1001.doElementAction] current tag path =
hierarchy/android.widget.FrameLayout/android.widget.LinearLayout/android.widget.FrameLayout/android.view.ViewGroup/android.widget.FrameLayout/android.widget.LinearLayout/android.widget.FrameLayout/android.widget.FrameLayout/android.widget.RelativeLayout/android.view.ViewGroup/androidx.viewpager.widget.ViewPager/android.widget.RelativeLayout/android.view.ViewGroup/androidx.recyclerview.widget.RecyclerView/android.widget.LinearLayout/android.widget.FrameLayout/android.widget.FrameLayout/android.widget.LinearLayout/android.widget.RelativeLayout/android.widget.FrameLayout/android.widget.RelativeLayout/android.widget.FrameLayout/android.widget.ImageView
2019-11-29 15:48:10 INFO [Crawler.1002.doElementAction] current file name = MainActivity.tag=ImageView.depth=24
2019-11-29 15:48:10 INFO [Crawler.1071.doElementAction] need input click
2019-11-29 15:48:10 INFO [AppiumClient.53.findElementByURI] find by uri element= MainActivity.tag=ImageView.depth=24
2019-11-29 15:48:10 INFO [AppiumClient.245.findElementsByURI] findElementByAndroidUIAutomator new UiSelector().className("android.widget.ImageView")
2019-11-29 15:48:10 INFO [AppiumClient.60.findElementByURI] find by xpath success
2019-11-29 15:48:10 INFO [Crawler.1080.doElementAction] mark 20191129154742/1_Steps.tag=.name=NOT_FOUND.clicked.png to 20191129154742/2_MainActivity.tag=ImageView.depth=24.click.png
2019-11-29 15:48:10 INFO [AppiumClient.141.mark] read from 20191129154742/1_Steps.tag=.name=NOT_FOUND.clicked.png
2019-11-29 15:48:11 INFO [AppiumClient.154.mark] write png 20191129154742/1_Steps.tag=.name=NOT_FOUND.clicked.png
2019-11-29 15:48:11 INFO [AppiumClient.161.mark] ImageIO.write newImageName 20191129154742/2_MainActivity.tag=ImageView.depth=24.click.png
2019-11-29 15:48:11 INFO [Crawler.1095.$anonfun$doElementAction$5] click element
index 等於幾就表示第幾次事件，action 表示當前的操作，xpath 就表示當前操作的元素的 xpath 表達式。
4. 補充說明
總說 AppCrawler 慢，其他工具相對較快，原因為何，先來看他們的架構組成
- appcrawler
- appium、atx
- appium on Uiautomator2 server、atx on Uiautomator2、maxim、adb shell uiautomator、改進版本Uiautomator2 server
- Uiautomator2
- AccessibilityService底層有個叫 AccessibleServices 東西，它可以獲取 Android 所有界面的控件，uiautomator獲取元素進行操作的時候就是靠 AccessibleServices 去獲取控件，然后去觸發一定的行為，uiautomator 就是將其進行了包裝；
基於 uiautomator，Appium 開發了一個 uiautomator server，ATX 開發了一個uiautomator2,maxim 就處於這一層。
Appium 走的是 HTTP 協議，ATX 走的是 JSON-RPC 協議，AppCrawler 處於最上層 所以 AppCrawler 由於多了兩層封裝，再加上運行過程中加入了截圖(可以在配置中取消，但是取消后不利於結果的查看)，運行起來自然就慢了。
- 改進期望：后期期望 AppCrawler 團隊可以將其根據需求指定底層操作，繞過很多不必要的流程來增加效率，這樣功能非常完善的同時也能保證效率
（文章來源於霍格沃茲測試學院）