淺談自動化測試

本文首發於 vivo網際網路技術 微信公眾號 
連結： https://mp.weixin.qq.com/s/ZsgstdmaiFUKkLItc6y-Lw
作者：何彥軍

軟體測試作為軟體生命週期中不可缺少的組成部分，對提高軟體質量起著重要作用。隨著軟體測試的發展，自動化測試技術也得到了很大提高。

本文首先介紹了自動化測試的概念、分類和現狀，並分別對不同端上的自動化測試實現原理進行了詳細地分析和闡述，透過對目前主流的一些自動化測試框架和工具的比較，指出了當前不同端上實施自動化測試的痛點和困難。

最後透過由資料驅動的自動化測試向關鍵詞驅動的自動化測試的探索，進而由傳統模式下的自動化測試轉向基於AI的自動化測試的摸索，對自動化測試的未來進行了展望。

一、自動化測試的概念

自動化測試是把以人為驅動的測試行為轉化為機器執行的一種過程。

二、適用自動化測試的專案特徵

三、軟體測試的分類

• 按專案流程：單元測試、整合測試、系統測試、迴歸測試、驗收測試

• 按技術：黑盒測試、白盒測試、灰盒測試

• 按功能：邏輯功能測試、介面測試、易用性測試、安裝測試、相容性測試

• 按效能：時間效能測試、空間效能測試

• 按自動化：功能自動化、效能自動化

專案流程 + 自動化 → 分層測試：unit測試（單元測試）、service測試（介面測試）、UI測試

四、自動化測試的現狀

1、單元測試（極限程式設計-測試驅動開發），佔比70%
（1）對軟體中最小可測試單元進行檢查和驗證
（2）由開發人員編寫，檢驗測試單元的語義是否正確
（3）一般在構建階段執行自動化測試指令碼
（4）代表工具：XUnit等

2、介面測試，佔比20%
（1）測試系統元件間介面的測試
（2）主要是保證介面的正確和穩定
（3）代表工具：Jmeter、Postman等

3、UI測試，佔比10%
（1）驗證佈局是否合理、風格是否一致等等
（2）確保UI功能內部的物件符合預期
（3）代表工具：selenium、robot framework等

4、小結
（1）單元測試藉助對應語言的測試框架，可以做到在構建時執行測試指令碼，難度較小
（2）介面測試透過定義好每個用例的輸入和輸出，藉助介面測試工具，也可以實現自動化，難度不大
（3）UI測試更多是與介面渲染相關的，包括元素的位置、大小是否正確，元素內容是否正確等等，主要是對介面渲染後的結果進行測試

五、不同端上的UI自動化測試

要判斷渲染介面是否滿足預期，首先就需要具備操控終端介面的能力，透過定位元素獲取元素的資訊與預期結果比較。

注意：這僅僅屬於功能性測試的範疇，如果包括多媒體內容的話，還需要藉助其他手段進行比較。

而操控終端介面的能力也隨終端的不同而不同，這裡主要是PC端和移動端的區別。

1、PC端：

每個瀏覽器廠商都會提供相應的driver，它們都實現了Selenium定義的WebDriver's wire protocol，透過這個協議可以操控瀏覽器做任何事情！

這個driver會啟動基於這個協議的web服務，實際上就是在一個埠上監聽http請求，根據不同的請求執行不同的操作。

代表框架：

以Selinium為例，實現原理如下：

2、移動端：

與PC端上原理類似，但又有Android與IOS的區別

Android：主要基於UIAutomator和UIAutomator2，更早的可以追溯到instrumentation框架。
（1）instrumentation可以把測試包和目標測試app載入到同一個程式中執行，以此實現對app的控制。

之後封裝形成Selendroid架構

（2）UIAutomator是谷歌在Android4.1版本釋出時推出的基於Java編寫的UI測試框架，與Bootstrap配合使用。
其特點是可以跨程式操作，可以獲取螢幕上任意一個app的任意一個控制元件屬性並對其操作。
但不足的是隻能用Java編寫，且測試指令碼必須上傳到裝置上執行。

（3）UIAutomator2修復了原有版本的bug，還增加了很多新功能

• 裝置和開發機可以脫離資料線，透過WiFi互聯（基於atx-agent）

• 整合了openstf/minicap達到實時螢幕投頻，以及實時截圖

• 整合了openstf/minitouch達到精確實時控制裝置

• 修復了xiaocong/uiautomator經常性退出的問題

• 程式碼進行了重構和精簡，方便維護

• 實現了一個裝置管理平臺(也支援iOS) atxserver2

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，詳情請參看《 》

（2）UITesting是蘋果公司推出，在Xcode 7引入的UI自動化測試框架，其原理利用了IOS的Accessibility

• Xcode 自帶，不需要搭建環境

• 支援 OC、Swift，學習成本低

• 支援 WebView 測試

• 穩定性好

六、常用的移動端自動化測試框架

下圖列舉了一部分測試框架在一些指標上的表現，除了這些，還有Robot framework、阿里的macaca框架等也可考慮。

七、移動端自動化測試的具體實現

一千個嘴把式，不如lai個手把式！

下面這一段自動化測試指令碼程式碼基於Appium實現了在app裡截圖的功能：

當然，除了寫好測試指令碼以外，還有很多工作需要準備

1. usb要連線好裝置，裝置需要開啟開發者模式

2. 安裝好目標測試app的debug包

3. 檢查chromeDriver的驅動版本是否與裝置匹配

4. 可能遇到其他未知問題......

下面是基於Robot framework的自動化測試指令碼片段

八、移動端自動化測試的探索

1、基於資料驅動的自動化測試 →  基於關鍵字驅動的自動化測試。

從以上具體實現中可以看出，要針對一個測試用例編寫出對應的測試指令碼，這需要的程式碼量不算少，並且還需要對每個方法的定義和輸入輸出十分熟悉。

因此，要實現UI層面的自動化測試，成本很高，甚至超過了收益。

所以，如果可以讓測試指令碼的編寫變的簡單，那麼將大大改善現狀。

2、探索

仔細觀察上述具體實現，可以發現，一個測試指令碼是可以由多個測試用例組成，而每一個測試用例又可以是由多條語義清晰的指令構成的。

於是這就可以考慮對其進行抽象，這也是策略模式的一種具體應用，主要包括三個方面：

1. 介面元素名與測試內部物件名的分離。

   將介面上的所有元素對映成相對應的一個邏輯物件，測試針對這些邏輯物件進行，介面元素的改變只會影響對映表，而不會影響測試。

2. 測試描述與具體實現細節的分離，把測試描述和測試的具體實現細節分離開來。

   測試描述只說明軟體測試要做什麼以及期待什麼樣的結果，而不管怎樣執行測試或怎樣證實結果。

   這樣做是因為測試的實現細節通常與特定的平臺以及特定的測試執行工具有著密切的聯絡。

   這種分離使得測試描述對於應用實現細節是不敏感的，而且有利於測試在工具和平臺間的移植。

3. 指令碼與資料的分離。

   把測試執行過程中所需的測試資料從指令碼中提取出來，在執行時測試指令碼再從資料存放處讀取預先定製好的資料，這樣指令碼和資料可以獨立維護

如下所示為一個基於關鍵字驅動的指令模型對映表

九、移動端UI自動化測試的展望

一個完整的移動端UI自動化流程應該是包括功能和視覺兩部分內容的。

在功能方面，儘管利用一些主流框架可以實現自動化，但編寫指令碼的成本依然很大並且很複雜。

在視覺方面，更是需要依賴影像識別、影像相似度匹配、音訊匹配等等技術手段。

所以，目前針對移動端UI的自動化測試還是困難重重，並沒有一個成熟的解決方案。

傳統測試技術 →  基於AI的測試技術

從AI在圍棋界接連擊敗李世石、柯潔開始，AI技術逐步影響著人類社會的方方面面。

而自動化測試也慢慢朝AI的方向在發展，基於深度學習，透過迭代訓練，讓機器自己做出決策，最終完成操作。

比較具有代表性的AI自動化測試實踐有愛奇藝團隊的Aion測試框架、騰訊遊戲QA團隊的AI自動化測試系統。

相信在不久的將來，藉助AI的力量，自動化測試將會變的越來越簡單！

十、參考文獻：

1. 什麼樣的專案適合自動化測試
2. python selenium自動化測試之路（1）--分層測試概念、selenium工具介紹
4. selenium實現原理