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

內容來源：

2017 年 6 月 24 日，TesterHome聯合創始人黃延勝在「Testwo第一屆測試分享沙龍」進行《App crawler自動遍歷工具》演講分享。IT 大咖說作為獨家視頻合作方，經主辦方和講者審閱授權發布。

閱讀字數：

3308 | 9分鐘閱讀

嘉賓演講視頻及PPT

，請複製：http://t.cn/RkiDn6v，粘貼至瀏覽器即可。

摘要

本次演講主要圍繞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就是一種簡單的分析策略，其實在拿到新舊版本的不同數據的時候還可以做更深入的挖掘，比如通過一定的方法分析股票漲跌幅是否滿足特定特徵。

以上為今天的分享內容，謝謝大家！

編者：IT大咖說，轉載請標明版權和出處

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！