本文首發於 vivo互聯網技術 微信公衆號
連接: https://mp.weixin.qq.com/s/ZsgstdmaiFUKkLItc6y-Lw
做者:何彥軍html
軟件測試做爲軟件生命週期中不可缺乏的組成部分,對提升軟件質量起着重要做用。隨着軟件測試的發展,自動化測試技術也獲得了很大提升。python
本文首先介紹了自動化測試的概念、分類和現狀,並分別對不一樣端上的自動化測試實現原理進行了詳細地分析和闡述,經過對目前主流的一些自動化測試框架和工具的比較,指出了當前不一樣端上實施自動化測試的痛點和困難。web
最後經過由數據驅動的自動化測試向關鍵詞驅動的自動化測試的探索,進而由傳統模式下的自動化測試轉向基於AI的自動化測試的摸索,對自動化測試的將來進行了展望。面試
自動化測試是把以人爲驅動的測試行爲轉化爲機器執行的一種過程。chrome
按項目流程:單元測試、集成測試、系統測試、迴歸測試、驗收測試編程
按技術:黑盒測試、白盒測試、灰盒測試windows
按功能:邏輯功能測試、界面測試、易用性測試、安裝測試、兼容性測試瀏覽器
按性能:時間性能測試、空間性能測試微信
項目流程 + 自動化 → 分層測試:unit測試(單元測試)、service測試(接口測試)、UI測試架構
一、單元測試(極限編程-測試驅動開發),佔比70%
(1)對軟件中最小可測試單元進行檢查和驗證
(2)由開發人員編寫,檢驗測試單元的語義是否正確
(3)通常在構建階段執行自動化測試腳本
(4)表明工具:XUnit等
二、接口測試,佔比20%
(1)測試系統組件間接口的測試
(2)主要是保證接口的正確和穩定
(3)表明工具:Jmeter、Postman等
三、UI測試,佔比10%
(1)驗證佈局是否合理、風格是否一致等等
(2)確保UI功能內部的對象符合預期
(3)表明工具:selenium、robot framework等
四、小結
(1)單元測試藉助對應語言的測試框架,能夠作到在構建時執行測試腳本,難度較小
(2)接口測試經過定義好每一個用例的輸入和輸出,藉助接口測試工具,也能夠實現自動化,難度不大
(3)UI測試更可能是與界面渲染相關的,包括元素的位置、大小是否正確,元素內容是否正確等等,主要是對界面渲染後的結果進行測試
要判斷渲染界面是否知足預期,首先就須要具有操控終端界面的能力,經過定位元素獲取元素的信息與預期結果比較。
注意:這僅僅屬於功能性測試的範疇,若是包括多媒體內容的話,還須要藉助其餘手段進行比較。
而操控終端界面的能力也隨終端的不一樣而不一樣,這裏主要是PC端和移動端的區別。
每一個瀏覽器廠商都會提供相應的driver,它們都實現了Selenium定義的WebDriver's wire protocol,經過這個協議能夠操控瀏覽器作任何事情!
這個driver會啓動基於這個協議的web服務,實際上就是在一個端口上監聽http請求,根據不一樣的請求執行不一樣的操做。
表明框架:
以Selinium爲例,實現原理以下:
與PC端上原理相似,但又有Android與IOS的區別
Android:主要基於UIAutomator和UIAutomator2,更早的能夠追溯到instrumentation框架。
(1)instrumentation能夠把測試包和目標測試app加載到同一個進程中運行,以此實現對app的控制。
以後封裝造成Selendroid架構
(2)UIAutomator是Google在Android4.1版本發佈時推出的基於Java編寫的UI測試框架,與Bootstrap配合使用。
其特色是能夠跨進程操做,能夠獲取屏幕上任意一個app的任意一個控件屬性並對其操做。
但不足的是隻能用Java編寫,且測試腳本必須上傳到設備上運行。
(3)UIAutomator2修復了原有版本的bug,還增長了不少新功能
設備和開發機能夠脫離數據線,經過WiFi互聯(基於atx-agent)
集成了openstf/minicap達到實時屏幕投頻,以及實時截圖
集成了openstf/minitouch達到精確實時控制設備
修復了xiaocong/uiautomator常常性退出的問題
代碼進行了重構和精簡,方便維護
IOS:主要基於UIAutomation,Xcode 7以後引入UITesting
(1)經過UIAutomation操做app時,UIAutomation會給app發送WM_GETOBJECT的消息
若是app處理WM_GETOBJECT消息,實現了UIAutomation Provider,並調用了下面的函數,則該app支持UiaReturnRawElementProvider(HWND hwnd, WPARAM wparam, LPARAM lparam, IRawElementProviderSimple *el)IRawElementProviderSimple就是UIAutomation Provider,包含了控件的各類信息,如Name,ClassName,座標等。
所以,app想要支持自動化,就必須實現UIAutomation Provider,詳情請參看《UI Automation Client Programmer's Guide》
(2)UITesting是蘋果公司推出,在Xcode 7引入的UI自動化測試框架,其原理利用了IOS的Accessibility
Xcode 自帶,不須要搭建環境
支持 OC、Swift,學習成本低
支持 WebView 測試
下圖列舉了一部分測試框架在一些指標上的表現,除了這些,還有Robot framework、阿里的macaca框架等也可考慮。
一千個嘴把式,不如lai個手把式!
下面這一段自動化測試腳本代碼基於Appium實現了在app裏截屏的功能:
固然,除了寫好測試腳本之外,還有不少工做須要準備
usb要鏈接好設備,設備須要打開開發者模式
安裝好目標測試app的debug包
檢查chromeDriver的驅動版本是否與設備匹配
下面是基於Robot framework的自動化測試腳本片斷
從以上具體實現中能夠看出,要針對一個測試用例編寫出對應的測試腳本,這須要的代碼量不算少,而且還須要對每一個方法的定義和輸入輸出十分熟悉。
所以,要實現UI層面的自動化測試,成本很高,甚至超過了收益。
因此,若是可讓測試腳本的編寫變的簡單,那麼將大大改善現狀。
仔細觀察上述具體實現,能夠發現,一個測試腳本是能夠由多個測試用例組成,而每個測試用例又能夠是由多條語義清晰的指令構成的。
因而這就能夠考慮對其進行抽象,這也是策略模式的一種具體應用,主要包括三個方面:
界面元素名與測試內部對象名的分離。
將界面上的全部元素映射成相對應的一個邏輯對象,測試針對這些邏輯對象進行,界面元素的改變只會影響映射表,而不會影響測試。
測試描述與具體實現細節的分離,把測試描述和測試的具體實現細節分離開來。
測試描述只說明軟件測試要作什麼以及期待什麼樣的結果,而無論怎樣執行測試或怎樣證明結果。
這樣作是由於測試的實現細節一般與特定的平臺以及特定的測試執行工具備着密切的聯繫。
這種分離使得測試描述對於應用實現細節是不敏感的,並且有利於測試在工具和平臺間的移植。
腳本與數據的分離。
把測試執行過程當中所需的測試數據從腳本中提取出來,在運行時測試腳本再從數據存放處讀取預先定製好的數據,這樣腳本和數據能夠獨立維護
以下所示爲一個基於關鍵字驅動的指令模型映射表
一個完整的移動端UI自動化流程應該是包括功能和視覺兩部份內容的。
在功能方面,儘管利用一些主流框架能夠實現自動化,但編寫腳本的成本依然很大而且很複雜。
在視覺方面,更是須要依賴圖像識別、圖像類似度匹配、音頻匹配等等技術手段。
因此,目前針對移動端UI的自動化測試仍是困難重重,並無一個成熟的解決方案。
傳統測試技術 → 基於AI的測試技術
從AI在圍棋界接連擊敗李世石、柯潔開始,AI技術逐步影響着人類社會的方方面面。
而自動化測試也慢慢朝AI的方向在發展,基於深度學習,經過迭代訓練,讓機器本身作出決策,最終完成操做。
比較具備表明性的AI自動化測試實踐有愛奇藝團隊的Aion測試框架、騰訊遊戲QA團隊的AI自動化測試系統。
相信在不久的未來,藉助AI的力量,自動化測試將會變的愈來愈簡單!