APPcrawler基礎原理解析及使用

時間 2019-12-13

標籤 appcrawler 基礎原理解析使用简体版

原文原文鏈接

1、背景

一年前，咱們一直在用monkey進行Android 的穩定性測試，主要目的就是爲了測試app 是否會產生Crash，是否會有ANR，頁面錯誤等問題，在monkey測試過程當中，實現了脫離Case的依賴，可是monkey測試徹底隨機、不可控，而且只支持Android系統，不支持iOS系統；然而在咱們不斷的實踐中發現，monkey測試已經不能知足於咱們的部分業務需求，好比說咱們想讓穩定性測試更靈活、跨端支持iOS、日誌可讀、定向場景設計、測指定頁面的穩定性、報告清晰展現遍歷結果等等，monkey在這些方面的實現侷限性很大，通過咱們調研發現開源工具appcrawler已然支持這些方面，在咱們最近幾個版本的appcrawler使用過程當中，可以知足咱們複雜的業務測試需求，彌補了monkey測試的不足，下面我詳細的介紹這個自動化UI遍歷工具-appcrawler。html

2、appcrawler UI自動化遍歷工具介紹

appcrawler，使用Scala編程語言運行在JVM上，它是基於app爬蟲的思想，逐漸造成了一種自動化測試方法稱爲「UI遍歷」，其主導思想是儘量多的去操做被測app的界面元素，每一個元素至少操做一遍。支持android和iOS，支持真機和模擬器，最大的特色是靈活性，可經過配置來設定遍歷的規則，用於自動化迴歸測試，實現對整個APP的全部可點擊元素進行遍歷點擊。前端

自動遍歷的價值

迴歸測試，遍歷基本的界面，瞭解主要界面的可用性，好比兼容性，基本功能；
利用遍歷獲取app的加載時間和性能數據，須要藉助其餘的性能數據抓取工具，好比OneApm，NewRelic；
利用遍歷驗證app的內存泄漏以及穩定性等功能，須要藉助LeakCanary和MLeaksFinder；
UI diff 驗證新老版本的功能差別，並識別細節的問題；
抓取接口請求輔助驗證一些模塊基本接口，並輔助分析接口調用流程，爲接口測試作準備；

3、爲何用這個工具

支持android和iOS，支持真機和模擬器；
可經過配置來設定遍歷的規則（好比設置黑名單和白名單，提升遍歷的覆蓋率）；
其自己的遍歷深度覆蓋較全，好比它擁有APP的dom樹，根據每一個activity下的可點擊元素逐個點擊，比monkey更具備規律性，覆蓋更全面；
生成的報告附帶截圖，能夠精確看到點擊了哪一個元素及結果，對crash類的問題定位清晰；
各大雲市場上自動遍歷功能都多有限制企業沒法自由定製.；
解決monkey等工具可控性差的缺點；
發現深層次的UI兼容性問題；
經過新老版本的diff能夠發現每一個版本的UI變更範圍；

4、設計理念

appcrawler UI遍歷基於app爬蟲思想，爲了更好的認識app爬蟲，這裏先介紹一下網絡爬蟲，在瞭解網絡爬蟲框架以後，您將會對app爬蟲有一個清晰的認知。java

網絡爬蟲

通用網絡爬蟲又稱全網爬蟲（Scalable Web Crawler），爬行對象從一些種子 URL 擴充到整個 Web，主要爲門戶站點搜索引擎和大型 Web 服務提供商採集數據。這裏主要對爬蟲以及抓取系統進行一個簡單的概述。node

1、網絡爬蟲的基本結構及工做流程linux

一個通用的網絡爬蟲的框架如圖所示：android

網絡爬蟲的基本工做流程以下：ios

1.首先選取一部分精心挑選的URL放入種子URL隊列中；web

2.將種子URL隊列中URL放入待抓取URL隊列；數據庫

3.從待抓取URL隊列中取出待抓取的URL，解析DNS，而且獲得主機的ip，並將URL對應的網頁下載下來，存儲進已下載網頁庫中。此外，將這些URL放進已抓取URL隊列。編程

4.分析已抓取URL隊列中的URL，分析其中的其餘URL，而且將URL放入待抓取URL隊列，從而進入下一個循環。

抓取策略：

在爬蟲系統中，待抓取URL隊列是很重要的一部分。待抓取URL隊列中的URL以什麼樣的順序排列也是一個很重要的問題，由於這涉及到先抓取那個頁面，後抓取哪一個頁面。而決定這些URL排列順序的方法，叫作抓取策略。下面介紹兩種常見的抓取策略：

1.深度優先遍歷策略

深度優先遍歷策略是指網絡爬蟲會從起始頁開始，一個連接一個連接跟蹤下去，處理完這條線路以後再轉入下一個起始頁，繼續跟蹤連接。咱們如下面的圖爲例：

遍歷的路徑：A-F-G E-H-I B C D

2.廣度優先遍歷策略

廣度優先遍歷策略的基本思路是，將新下載網頁中發現的連接直接插入待抓取URL隊列的末尾。也就是指網絡爬蟲會先抓取起始網頁中連接的全部網頁，而後再選擇其中的一個連接網頁，繼續抓取在此網頁中連接的全部網頁。仍是以上面的圖爲例：

遍歷路徑：A-B-C-D-E-F G H I

app爬蟲

app爬蟲比web端更容易抓取，大部分也都是http/https協議，返回的數據類型大多數爲json。也就是指app爬蟲會先抓取啓動app後初始頁面的全部URL，而後再選擇其中一個URL進行抓取，而後讀取URL、解析URL、執行URL，下面對app爬蟲作詳細的概述。

一個app爬蟲的基本結構及工做流程、通用的app爬蟲的框架如圖所示：

爲了更好的理解app爬蟲思想，下面app爬蟲的工做流程中，括號中內容時結合業務作的解述。

app爬蟲的基本工做流程以下：

1.進入app，首先獲取當前BaseURL,支持類型：http、https、ftp、file（好比啓動百度外賣app後有N個url）；

2.將這些URL放入待抓取的隊列（待抓取即待遍歷，也就是說有些元素點擊後會生成新的url）；

3. 從待抓取的隊列中取出即將抓取（待遍歷）的URL，讀取URL，並解析attribute、Label、name放入堆棧中；

4.遍歷（執行）已抓取URL中的全部元素，分析當前URL隊列是否包含baseURL，若是包含則清空堆棧記錄從新計數（分析其中的其餘URL，並將URL放入待抓取（待遍歷）的URL隊列中，從而進入下一個循環），若是不包含，則使用當前頁面，再也不記錄堆棧；

抓取策略：

appcrawler中的採起的抓取策略是：深度優先策略（其中遍歷深度可配置）

5、appcrawler技術要點解析

5.1 appcrawler和appium 的關係

5.1.1 appium支持

appcrawler在selenium2.0支持的基礎上作了一個針對appium的封裝，類名叫MiniAppium，他具備以下的特點。

設計極簡，除了selenium的自身支持外，增長了幾個API用於app的測試；
封裝了appium命令的啓動中止
強大的斷言

5.1.2 AppiumClient.Scala負責與appium交互

1.監聽appium進程的信息（執行成功，執行失敗，中止等），從appium得到包名和activity

2.經過xpath找到組件，對重名的id只使用第一個。每隔5秒找一次，找10次後若是還找不到，則放棄

3.對組件的操做（如：滑動，點擊，長按等）進行定義，動做是隨機取的（相似monkey，方法名也叫monkey），位置信息用的是經過xpath找到的x，y座標

4. 對每次操做以後的界面截屏（若是界面改變的話）

5.獲取頁面結構（最多3次）解析xpath的時候拿到一個節點樹，對樹中全部節點遍歷，具體實如今TreeNode.scala和Tree

5.1.3 appium關鍵字

在selenium支持的基礎上只增長了少數幾個方法.：

see：元素定位與屬性提取

tap：點擊

send：入文本

swipe：滑動

原來scalatest的selenium的支持仍然所有可用. 好比click on id("login")

具體用法以下：

1. see（）

惟一的元素定位API，see是引用了<阿凡達>電影裏面一句臺詞"I See You"，它的做用是當你看到一個控件, 你應該能夠根據看見的東西就能夠定位它，並獲取到這個控件的屬性，無須藉助其餘工具或者使用findElementByXXX之類的函數，好比有個Button, 名字是"登陸"，它的id是account，定位它能夠經過以下多種方式的任何一種：

• see("登陸")
• see("登")
• see("錄")
• see("account")
• see("acc")
• see("//UIAButton[@id="account"]")
• see("screen_name")("text")
• see("screen_name").nodes.head("text")
• see("action_bar_title")("text") 文本
• see("action_bar_title")("tag") 類型
• see("action_bar_title")("selected") 是否選中

若是當前界面中存在了有歧義的空間，好比其餘一個名字爲"登陸"的輸入框，那麼上述定位方法中定位中兩個控件的定位方法會失敗，你須要本身調整便可，這就是關於元素定位你只須要用see這個方法便可。

2. 動做 tap send swipe

目前只封裝了3個動做. tap 、send 、swipe.
see("輸入手機號").send("13067754297")
see("password").send("xueqiu4297")
see("button_next").tap()

支持鏈式調用. 固然不推薦平常使用

//對三次連續出現的tip控件點擊三次.
see("tip").tap().tap().tap()
see("輸入手機號").send("13067754297").see("password").send("x297")

3. 斷言

支持標準的scalatest的should風格的斷言，支持兩種風格的斷言
assert風格
assert(2>1)

5.2 測試執行

1.定義URL

界面惟一性:每一個screen都有一個惟一的id，這樣若是在報錯的截圖中就能夠很容易找到那個url，以下圖所示
android的url默認爲當前的activity名字
iOS沒有activity概念，默認使用當前頁面dom的md5值的後五位做爲標記，若是頁面不變，那麼這個md5值也不會變
也能夠本身指定某些特徵做爲url，好比title或者某些關鍵控件的文本
控件的惟一性取決於這個url和控件自身的id name tag text loc等屬性
好比一個輸入框id=input，在多個頁面中都出現了
若是url爲空，那麼它只會被點擊一次
若是url設置爲當前activiy的名字，那麼有多少頁面包含它他就會被點擊多少次
url的定義是一門藝術，能夠決定如何優雅的遍歷

2.遍歷控制

遍歷控制依賴於項目目錄下的配置文件Baiduwaimai.yml, 裏面有詳細的註釋解釋每一個配置項的做用

3.如何寫配置文件Baiduwaimai.yml（運行的核心所在）

配置文件基本都是以key-value格式，因此能夠用文本編輯器，而後更名爲 .yml或者.json文件便可。這裏展現一下百度外賣app的配置文件 Baiduwaimai.yml部份內容：

後退標記back

android默認是back鍵,不須要設定.

iOS上沒有back鍵，須要本身指定，經過xpath定位方式指定遍歷完全部控件應該點擊什麼控件返回

黑名單black

控件黑名單爲black方法，他會繞過id name或者text中包含特定關鍵詞的控件

url黑名單能夠繞過特定的activity

遍歷的行爲控制

總體的配置項應用順序爲：

capability

androidCapability和iosCapability分別用來存放不一樣的平臺的設置，最後會和capability合併爲一個

startupActions

用於啓動時候自定義一些劃屏或者刷新的動做

selectedList

適用於在一些列表頁或者tab頁中精確的控制點擊順序
selectedList表示要遍歷的元素特徵
firstList表示優先遍歷元素特徵
lastList表示最後應該遍歷的元素特徵
tagLimit定義特定類型的控件遍歷的最大次數. 好比列表項只須要遍歷少數
須要注意的是firstList和lastList指定的元素必須包含在selectedList中

元素定位的方法

appcrawler大量的使用XPath來表示元素的範圍，大部分的選項均可以經過XPath來指定範圍，好比黑白名單，遍歷順序等

4. 點擊先後截圖

URIElementStore.scala負責記錄控件是否被點擊

1.使用枚舉類型，Clicked表示已遍歷，Skiped = Value表示跳過

2.使用elementStore（Map類型）存儲被點擊的組件列表。URIElement.scala用來表明惟一的控件，每一個特定的命名控件只被點擊一次，因此這個element的構造決定了控件是否可被點擊屢次，若是組件url=baiduwaimai，key只有1個，因此只能點一次。若是組件url=baiduwaimai/xxxActivity，因爲多是不一樣Activity中的，因此能夠點擊屢次

截圖加紅框是如何實現的？

appcrawler使用了java的ImageIO庫，能夠對已有的圖片進行標記， appcrawler在點擊前會先識別元素的位置，並加上一個紅框用於提示.。

5.3 跨平臺

Android UI遍歷

1.啓動appium

appium --session-override

2.啓動appcrawler UI遍歷
java -jar appcrawler-2.1.1.jar -a bdwm.apk -o demo/ --capability appActivity=.view.WelcomeActivityAlias

3.配置文件的運行方式

java -jar appcrawler-2.1.1.jar -a bdwm.apk -c conf/baiduwaimai.yml

4.跳太重新安裝app

java -jar appcrawler-2.1.1.jar -a bdwm.apk -c conf/baiduwaimai.yml --capability appPackage=waimai_4.11.6.apk

IOS UI遍歷

模擬器運行:

1.啓動appium

appium --session-override

2.啓動appcrawler 開始UI遍歷

java -jar appcrawler-2.1.1.jar -a bdwm.app -c conf/baiduwaimai.yml

xcode編譯出來的app地址可經過編譯過程本身查看

真機運行

使用xcode編譯源代碼，使用開發證書才能作自動化，編譯出真機可自動化的.app或者.ipa包

java -jar appcrawler-2.1.1.jar -a bdwm.ipa -c conf/baiduwaimai.yml

5.4 自定義

5.4.1 Xpath的充分利用

獲取控件XPath路徑的工具

uiautomatorviewer（最經常使用）、名字、平臺

Android：只能直接生成xpath, 須要本身拼湊

iOS：inspector，只能工做在mac上，

Android和iOS控件差別

tag名字是不同的.、控件佈局不同

android.view.View

android.widget.XXXXX

關鍵的定位屬性也不同

iOS：name、label、value

Android：resource-id、content-desc、text

常見xpath表達式用法

5.4.2 插件化

1.代理插件

自動獲取app上每次點擊對應的網絡請求，支持http和https

安裝

目前是默認自帶

啓用

在配置文件中加入插件

代理插件默認開啓7771端口，配置你的Android或者iOS的設備的代理，指向你當前運行appcrawler的機器和7771端口

結果

在作每一個點擊的時候都會保存這期間發送的請求，也就是記錄先後兩次點擊中間的全部經過代理的請求，最後會在結果目錄裏面生成後綴名爲har的文件

https支持

若是要錄製https，須要安裝一個特殊的證書"BrowserMob Proxy"，或者用burp把當前端口設置爲burp的上游代理，對於一些用url中包含有ip的https請求不支持

2. Log插件

做用

自動記錄Android的LogCat或者iOS的syslog

安裝

目前是默認自帶

啓用

在配置文件中加入插件
"pluginList" : [
"com.testerhome.appcrawler.plugin.LogPlugin"
],

結果

記錄一次點擊事件後所發生的log記錄，並保存爲後綴名爲.log的文件中

3. TagLimit插件

做用

智能判斷列表和其餘的類似佈局元素，只遍歷前3個類似空間. 適用於微博這種無限刷新的列表，用於節省時間，原理是利用特定元素的tag佈局層級是否徹底同樣

安裝

目前是默認自帶.

啓用

在配置文件中加入插件

"pluginList" : [
"com.testerhome.appcrawler.plugin.TagLimitPlugin"
],

結果

無

6、appcrawler使用流程

6.1 環境搭建

1. appcrawler的最新jar包（最新的功能多，兼容性比較高），目前最新的是 appcrawler-2.1.2.jar ，

2. appium環境安裝

3.Android SDK,主要是爲了使用tools文件夾下的 uiautomatorviewer.bat 來定位元素，獲取元素的xpath,

6.2 appcrawler目錄結構

6.3 執行步驟

1. 手機安裝好最新的安裝包，

2.開啓appium服務

在命令行中輸入： appium ，提示：則開啓成功

3.在放 appcrawler-2.1.0.jar 的文件夾下執行如下命令：

Java -jar appcrawler-2.1.0.jar -a bdwm.apk -c baiduwaimai.yml

或者如上目錄，運行start.py 腳本

便可自動啓動APP，並自動遍歷點擊元素

由於遍歷的深度比較大，在覆蓋比較全面的條件下，基本要跑2個半小時左右，截圖2600+張

4.輸出結果-日誌和報告以下：

5. html報告：

7、目前的使用方向和收益

在每一個版本的集成測試階段，會跑3次appcrawler UI 自動遍歷，總體測試方式是手工測試+自動遍歷

如今咱們只在android端進行UI自動遍歷測試，運行2小時半左右，大約一小時截圖1000張，經過截圖+報告能夠直觀的看到哪些頁面正常，哪些頁面異常

利用appcrawler發現bug2個：商超方向的一些空白頁面

8、工具問題分析

雖然appcrawler對咱們app的穩定性測試帶了很客觀的收益，可是這個工具自己仍是有一些不足須要改善，主要不足以下：

1. 測試速度可能比較慢，會對重複的界面進行點擊

2. 每一個版本的配置文件或許有不一樣，對比三次測試，一方面是在類似的組件中可能漏掉比較重要的組件，另外一方面是爲了追求測試覆蓋，重複點擊了類似的界面組件。二者不能很好地平衡

3. 配置文件有必定的侷限性，有時不能很好地表達測試者的意圖

4. 不能自動輸入文本信息

9、後續TODO

後續咱們會更加充分利用appcrawler，並進行二次開發，主要實現如下功能：

ios UI遍歷

多端執行，多個設備同時運行

和Jenkins結合

mail通知

調研第三方雲測平臺

時間： 2017-12-04

Tags: 測試, 插件, 配置, android, ios, url, 測試技術, Monkey

每日一句

每一个你不满意的现在，都有一个你没有努力的曾经。