自動化測試的理想境界：AppCrawler自動遍歷工具

內容來源：2017 年 6 月 24 日，TesterHome聯合創始人黃延勝在「Testwo第一屆測試分享沙龍」進行《App crawler自動遍歷工具》演講分享。IT 大咖說（微信id：itdakashuo）做爲獨家視頻合做方，經主辦方和講者審閱受權發佈。

閱讀字數：3308 | 9分鐘閱讀

獲取嘉賓演講視頻及PPT:

摘要

本次演講主要圍繞App Crawler來展開，介紹該工具背後的實現方法論。

開發背景

開篇先說下開發AppCrawler時候的背景，當時我是在一家互聯網金融公司內，業務測試的主要痛點在於金融領域的業務變動較快，業務線衆多且流程複雜，很難作到全面的覆蓋。

簡單介紹下常見的幾個問題。好比不容易感知到股票信息中字段內容的丟失或數據異常，用戶網絡慢時發出請求後退出當前頁面發生崩潰，某系界面在4.4和5.0的系統上操做體驗不一樣，還有最典型的在app的某些特定頁面崩潰或某接口報錯。

後續咱們總結分析了下這些測試的難點。首先是快速迭代致使自動化用例吃力，現有的自動化框架沒法知足穩定性和易用性的要求。其次是驗證的內容點太多，好比界面字段正確性、接口返回內容等都須要一一驗證。另外是變動範圍測試覆蓋困難，因缺乏對代碼流和功能的關鍵建模，因此沒法從代碼層分析出可靠的變動範圍。

自動化測試理想狀況應該是這樣的，較少的自動化代碼維護，可以穩定執行，能夠對衆多的待驗證數據進行自動驗證，可以代替人自動對app的每一個角落進行檢查分析。總結起來有3項必要功能：自動遍歷、業務建模以及數據自動對比，這些已會包含在接下來說到的AppCrawler中。

AppCrawler

自動遍歷的目標

安卓原先的自動化測試工具Monkey是經過隨機的事件來遍歷全部的App，其本質是健壯型測試工具只不過附帶了測試頁面的特性。在此基礎上要作的改進有兩點，一是可控，作到自定義遍歷的路徑，二是可定製，實現自動輸入或自動滑動等。

結構分析方面咱們指望有點擊先後的截圖對比，結構的數據建模，新老版本的UI Diff，app結構思惟導圖的展現。

其餘框架

（現有的自動化測試框架比較）

（各框架發展趨勢）

目前AppCrawler已支持appium和macaca，未來可能會支持selenium，而appium底層又包含wda、selendroid、uiautomator2。從上圖中能夠看到appium的增加很是迅速，這主要是由於它同時支持安卓、iOS、混合型應用以及全量的腳本語言。

這種方式其實就是協程的體系。經過提高CPU利用率，減小線程切換，進而提高程序運行效率。

延伸開來協程主要有三個特性。第一個是可控制，不一樣於線程協程能作到可被控制的發起子任務；第二個是輕量級，協程很是小、佔用資源比線程還少，在JVM平臺上它的本質就是一次方法的調用；第三個是語法糖，目前可以使用協程的語言都提供了很好的語法糖支持，使多任務或多線程切換不在使用回調語法。

使用流程

在實際應用中能夠直接在測試版本上運行AppCrawler，也能夠用於冒煙階段開發人員自行測試，首先配合使用LeakCanary、Apm、Bugly、Appetizer這幾個工具抓取App中的各類BUG，而後打包成DEBUG版本交給遍歷工具。執行測試以後可以探測出內存泄露和健壯性，迴歸大部分的流程，老版本作diff對比分析。

上圖是執行AppCrawler以後安卓的效果圖。左下方的列出的是全部能遍歷到的界面，選中其中某一個就會在右側顯示出具體界面和點擊的控件。左上方展現的是不一樣解析狀態的次數。

這是跑完以後另外的數據文件，他們被統一存放在一個目錄下。文件名包含着關鍵信息，序號表示第幾回點擊，後面緊隨的是點擊的頁面名、控件，處於點擊先後的哪一個狀態。

Diff對比

上面列出的是關於diff對比的相關命令，candidate參數是當前的測試報告，master參數上一輪app的測試報告。

這是新老版本的UI Diff報告，每一處變動都會有一條信息展示，如圖中紅線框出的。若是不想檢測某種變動，能夠經過黑名單屏蔽掉該字段，便於過濾大量屬於正常變動的狀況。

自動化支持（實驗性支持）

目前自動化還處於實驗階段，經過yaml來配置，主要有這幾個關鍵參數。AutoCrawl是否自動化後執行遍歷，name測試用例名字，xpath定位操做，then斷言。

技術原理剖析

技術點

對跨平臺的支持是基於Appium。配合Yaml來使用更簡化的方式寫配置文件。採用以自動遍歷爲核心功能點，在此之上提供簡單的自動化框架支持的自動化策略。支持插件機制便於開發與擴展。

與傳統WebDriver的不一樣點

傳統WebDriver全部的元素都要根據id、name、xpath進行定位，而後再作截圖、點擊之類的操做。AppCrawler是先getPageSource獲取全部的元素列表，再直接在列表中分析xpath獲得真正的定位符，也就是說即便是使用id、name的定位方式在AppCrawler中速度都是同樣的。另外截圖時增長了對選擇控件的高亮區分，自動化機制的策略相對寬鬆。

Xpath定位方式

Xpath支持多種匹配特性，常規的xpath方式例如*[@resource-id=」xxx」]，也可使用正則例如「^肯定&」。更誇張的是包含的方式，直接輸入控件包含的字段就能夠直接定位，好比經過輸入「密碼」定位到密碼輸入框。

自動遍歷過程

自動遍歷的第一步是獲取信息，把當前app的界面dump爲xml結構。而後判斷是否還在當前app，不然後退backApp backButton，一直退到app內。

重點是獲取待遍歷的元素，使用「//*」這個Xpath表達式能夠找出全部的控件。以後經過selectList 設置要測試的控件進行第一步操做，第二步經過blackList過濾黑名單、小控件或不可見控件，第三步重排控件順序以肯定點擊流程，第四步經過tagList跳過已點擊或限制點擊的控件，最後根據匹配的規則執行action。

以上步驟作完以後，再在新的頁面中循環執行。

Action支持列表

Action默認支持back（後退）、backApp、monkey（隨機事件）。其中backApp通常狀況下等價於back，不過是可定製的，好比某些場景下不能經過back直接回到App中，此時能夠自定義邏輯想辦法回去。另外對於像「xxx（）」這樣的形式會被認爲是可運行的Java編程語句，好比Thread.sleep(3000)、driver.swipe(0.9, 0.5, 0.1, 0.5)。若是非以上全部行爲會被認爲是輸入。

收益

實現基礎功能的迴歸測試，節省了很大的工做量。能夠經過截圖觀察app流程正確性，基於UI diff對比功能正確性。可以結合LeakCanary MLeakFinder發現大部分的內存泄露以及低級的異常和健壯性問題。

自動遍歷的優缺點

自動遍歷並不是銀彈，它僅能解決整個測試環節中的80%，包括自動化的路徑探索測試、迴歸測試、冒煙測試，這些能夠用自動化來代替人工。可是剩下的20%還須要手工測試，好比新功能的業務流程，須要定製化的複雜操做或業務邏輯。

這種自動遍歷方式的潛力無疑是巨大的。除開老的功能迴歸以外，還能夠作異常場景和性能的自動遍歷，有更強大的自動化框架BDD加改進特性支持。還有個重點——測試分析，以前提到的UI diff就是一種簡單的分析策略，其實在拿到新舊版本的不一樣數據的時候還能夠作更深刻的挖掘，好比經過必定的方法分析股票漲跌幅是否知足特定特徵。