內容來源：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大咖說 的文章
