當前位置:
首頁 > 最新 > 自動化測試的理想境界:AppCrawler自動遍歷工具

自動化測試的理想境界: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大咖說,轉載請標明版權和出處


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

本站內容充實豐富,博大精深,小編精選每日熱門資訊,隨時更新,點擊「搶先收到最新資訊」瀏覽吧!


請您繼續閱讀更多來自 聊娛君君君君 的精彩文章:

中國三類特種兵一個比一個厲害,有一種最神秘資料全是未知

TAG:聊娛君君君君 |