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

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

簡單介紹下常見的幾個問題。比如不容易感知到股票資訊中欄位內容的丟失或資料異常，使用者網路慢時發出請求後退出當前頁面發生崩潰，某系介面在4.4和5.0的系統上操作體驗不同，還有最典型的在app的某些特定頁面崩潰或某介面報錯。

後續我們總結分析了下這些測試的難點。首先是快速迭代導致自動化用例吃力，現有的自動化框架無法滿足穩定性和易用性的要求。其次是驗證的內容點太多，比如介面欄位正確性、介面返回內容等都需要一一驗證。另外是變更範圍測試覆蓋困難，因缺少對程式碼流和功能的關鍵建模，所以無法從程式碼層分析出可靠的變更範圍。

自動化測試理想情況應該是這樣的，較少的自動化程式碼維護，能夠穩定執行，可以對眾多的待驗證資料進行自動驗證，能夠代替人自動對app的每個角落進行檢查分析。總結起來有3項必要功能：自動遍歷、業務建模以及資料自動對比，這些已會包含在接下來講到的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對比的相關命令，candidate引數是當前的測試報告，master引數上一輪app的測試報告。

這是新老版本的UI Diff報告，每一處變更都會有一條資訊展現，如圖中紅線框出的。如果不想檢測某種變更，可以通過黑名單遮蔽掉該欄位，便於過濾大量屬於正常變更的情況。

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

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

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

Xpath支援多種匹配特性，常規的xpath方式例如*[@resource-id=”xxx”]，也可以使用正則例如“^確定&”。更誇張的是包含的方式，直接輸入控制元件包含的欄位就可以直接定位，比如通過輸入“密碼”定位到密碼輸入框。

自動遍歷的第一步是獲取資訊，把當前app的介面dump為xml結構。然後判斷是否還在當前app，否則後退backApp backButton，一直退到app內。

重點是獲取待遍歷的元素，使用“//*”這個Xpath表示式可以找出所有的控制元件。之後通過selectList 設定要測試的控制元件進行第一步操作，第二步通過blackList過濾黑名單、小控制元件或不可見控制元件，第三步重排控制元件順序以確定點選流程，第四步通過tagList跳過已點選或限制點選的控制元件，最後根據匹配的規則執行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就是一種簡單的分析策略，其實在拿到新舊版本的不同資料的時候還可以做更深入的挖掘，比如通過一定的方法分析股票漲跌幅是否滿足特定特徵。