本文首發于 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，詳情請參看《
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的自動化測試腳本片段
八、移動端自動化測試的探索
1、基于資料驅動的自動化測試 → 基于關鍵字驅動的自動化測試。
從以上具體實作中可以看出，要針對一個測試用例編寫出對應的測試腳本，這需要的代碼量不算少，并且還需要對每個方法的定義和輸入輸出十分熟悉。
是以，要實作UI層面的自動化測試，成本很高，甚至超過了收益。
是以，如果可以讓測試腳本的編寫變的簡單，那麼将大大改善現狀。
2、探索
仔細觀察上述具體實作，可以發現，一個測試腳本是可以由多個測試用例組成，而每一個測試用例又可以是由多條語義清晰的指令構成的。
于是這就可以考慮對其進行抽象，這也是政策模式的一種具體應用，主要包括三個方面：
- 界面元素名與測試内部對象名的分離。
将界面上的所有元素映射成相對應的一個邏輯對象，測試針對這些邏輯對象進行，界面元素的改變隻會影響映射表，而不會影響測試。 - 測試描述與具體實作細節的分離，把測試描述和測試的具體實作細節分離開來。
測試描述隻說明軟體測試要做什麼以及期待什麼樣的結果，而不管怎樣執行測試或怎樣證明結果。 這樣做是因為測試的實作細節通常與特定的平台以及特定的測試執行工具有着密切的聯系。 這種分離使得測試描述對于應用實作細節是不敏感的，而且有利于測試在工具和平台間的移植。 - 腳本與資料的分離。
把測試執行過程中所需的測試資料從腳本中提取出來，在運作時測試腳本再從資料存放處讀取預先定制好的資料，這樣腳本和資料可以獨立維護
如下所示為一個基于關鍵字驅動的指令模型映射表
九、移動端UI自動化測試的展望
一個完整的移動端UI自動化流程應該是包括功能和視覺兩部分内容的。
在功能方面，盡管利用一些主流架構可以實作自動化，但編寫腳本的成本依然很大并且很複雜。
在視覺方面，更是需要依賴圖像識别、圖像相似度比對、音頻比對等等技術手段。
是以，目前針對移動端UI的自動化測試還是困難重重，并沒有一個成熟的解決方案。
傳統測試技術 → 基于AI的測試技術
從AI在圍棋界接連擊敗李世石、柯潔開始，AI技術逐漸影響着人類社會的方方面面。
而自動化測試也慢慢朝AI的方向在發展，基于深度學習，通過疊代訓練，讓機器自己做出決策，最終完成操作。
比較具有代表性的AI自動化測試實踐有愛奇藝團隊的Aion測試架構、騰訊遊戲QA團隊的AI自動化測試系統。
相信在不久的将來，借助AI的力量，自動化測試将會變的越來越簡單！