下面給大家分享一下UI自動化中常用的設計模式。 由于網上已經有非常多的文章詳細講解了設計模式的編碼實現，所以我今天也就不講實現細節了。 就是講我也講不出什么花來，只是網上的文章基本都是講解設計模式的本身實現，很少針對某一領域的實際場景去講具體改怎么用設計模式。 所以今天我只針對一些實際的場景來說一下如何使用這些設計模式來完善UI自動化。

工廠

每種語言實現設計模式的方式都不一樣，這里僅以java為例。 一般來說，工廠模式是為了把創建一個對象的操作都集中在一起管理，其他所有需要用到這個對象的代碼都調用工廠類來創建對象。 在UI自動化中，工廠類有一個重要的作用就是提供數據的能力。 這里直接上一個例子， 在我的項目中有這樣一個場景， 我們的測試都分模塊的， 不同的模塊有不同的QA。 測試模型中心模塊的QA想要測試的話就需要依賴建模IDE來產出各種各樣的模型。 那根據上一個帖子我講到的一個設計原則--模塊間有數據依賴的時候。每個模塊自己負責提供對外接口。 模型IDE的QA需要提供一個可以生產出各種不同模型的API來。 如下：

上面我們我們用一個簡單工廠來實現創建各種模型。 其他模塊調用此工廠方法滿足自己對模型的需求。 如果我們創建模型的類型更復雜的話，可以引入工廠模式和抽象工廠模式。 但實際上我最常用的還是簡單工廠，偶爾用工廠模式抽象工廠基本沒用過。使用設計模式的時候最容易出現的是過度設計， 把過于復雜的模式硬搬到項目中來。 這是不可取的。

那接下來說一說這個工廠存在的意義吧。 簡單工廠算是設計模式里最簡單的了， 簡單到它幾乎不是一個什么模式。 它其實只有一種思想，就是把創建一個東西的操作都統一放到一起，調用方只需要知道我要一個東西，我需要把什么參數傳遞進來就可以得到這個東西。 比如我們的這個例子里，調用方只需要傳遞我需要一個什么類型的模型的參數。 至于如何創建這個模型它不需要知道，里面包含了多復雜的UI操作它也不需要知道。 這樣做的好處是：

代碼復用，我們使用工廠的來創建的東西一般都是比較復雜的，需要很多的步驟才能創建。 如果只是隨便new一下就可以得到的對象也就犯不著專門搞個工廠方法了。 如果任由寫case的人根據自己的想法去創建這些對象，不僅造成了很多的重復代碼。 而且這些碎片的話的代碼在后期的維護上也是一個難以接受的事情。

封裝變化，我們把創建模型的所有操作都統一放在一起。之后生產模型的操作發生變化，比如需求變動。那我們只需要改動這一處就可以了。而且調用方也完全不感知

解耦，就如開始說的那個設計原則一樣， 調用方不感知復雜的模型生產過程， 達到解耦的作用。 在UI自動化中，尤其是業務邏輯特別復雜的大型項目中。 多人協作有個比較重要的點在這里提一下。 就是解耦，不要讓其他模塊的人感知自己模塊的任何實現細節。 他們了解的越少，操作的越少， 出錯的概率就越小，學習成本就越小。 畫地為界，分而治之。 其實我個人覺得整個設計模式就是在解決兩件事情：解耦和代碼復用

單例

我們有了上面的工廠方法來幫助我們創建模型， 但是這里有個問題。 就是我有太多的case依賴這些模型了。 如果每個case都執行一遍上面的操作重新創建一個模型的話會有兩個問題：

UI操作尤其耗時，尤其是生產模型這種異步操作

UI本就不穩定，這些重復的操作會增加case失敗的概率

所以我們希望除了有這種創建新模型的能力之外。 還能夠復用之前已經產生的模型。 于是我們就有了使用單例模式的需求。 一般提到單例模式，基本上就是懶漢式，餓漢式什么的。 但這兩種大概率都是不可用的。 因為首先我們的操作是延遲加載的，只有到了使用的時候才會去UI上執行創建模型的操作。 總不能直接在類加載的時候就執行吧。 至于在不加鎖的情況下判斷一下對象是否為null也是不行的。 因為現在的大規模UI自動化都是并發執行的。 所以可選的方案就是加鎖的雙重檢查機制以及靜態內部類了。 這里主要講一下靜態內部類吧， 雙重檢查機制估計大家都玩爛了。 如下：

靜態內部類不會再LRModel的類加載的時候就加載，而是有人調用getInstance 的時候才會加載。所以保證了延遲加載

java 的classloader會保證靜態內部類的線程安全，所以不用擔心并發的問題

上面是靜態內部類的實現方式，優點是相較于鎖的雙重檢查方來說實現起來簡單，坑少。 比如沒有那個經典的指令重排序的問題。 當然缺點也明顯， 就是一旦創建對象失敗， 那以后就再也沒有機會重新創建對象了。 而UI自動化又是出了名的不穩定。 所以還是要慎重的。

模板

模板模式在UI自動化中比較常用的原因是在產品中有很多的操作路徑是復用的。 所以我們可以使用模板模式， 把固定的路徑抽象出來，由子類去實現那些獨立的邏輯。 比如：

上面是我們的產品引入一份數據的邏輯。 我們的數據引入有很多種類型。 比如從本地引入， 從數據庫引入，從hdfs引入，從ftp上引入等等等等。但是他們的基本步驟都是一樣的（看截圖中的注釋）， 所以模板模式的思想是使用父類來規定到執行操作的步驟， 為了代碼復用所以也會實現一些通用的步驟比如所有的引入都得點擊某些button，填寫一些都行。 然后留下一些abstract的方法給子類實現。 這種父類規定骨架，子類實現細節的方式就是模板方法了。 在這里我們的父類定義好了所有的步驟，但是部分的具體實現細節由子類完成。 這里我們發現子類需要實現兩個方法

每個數據引入的關于生成table的操作的setTableConfig

每種數據引入的文件配置方式操作的setFileConfig

當然模板方法也是可以有較深的結構的。 比如上面說的一些引入方式雖然都屬于數據引入，但是也分為兩大類， 一個是結構化數據，一個是圖片數據。 而且凡是屬于結構化數據的引入方式有很多步驟都是相同的。 凡是屬于圖片數據引入的方式的大部分步驟也是相同的。 所以我們繼續有抽象類如下：

上面是結構化數據的抽象類。 他實現了父類IDataload的setTableConfig方法。 因為所有結構化數據引入的這個頁面操作都是一樣的。然后才是我們具體的本地文件的數據引入的類。如下。

這個具體的本地文件引入的類實現了方法setFileConfig。 這樣我們就看到了這個模板模式的全貌。

基類IDataload負責定義執行步驟，以及個別UI操作的實現。 規定子類必須實現setTableConfig和setFileConfig這兩個方法

類StructureDataLoad繼承基類IDataload，并實現了setTableConfig方法。 因為所有的結構化數據引入在這里使用的是同樣的頁面

具體的實現類LocalFileDataLoad繼承StructureDataLoad，代表著本地數據引入并實現了針對于本地文件引入所獨有的頁面操作setFileConfig

所以實際上調用方要做的事情就是這樣的

模板模式的優點：

代碼復用， UI上很多操作路徑都是重復的，甚至說不同的業務流程操作中的部分頁面使用的是相同的頁面。 使用模板模式可以很好的整理我們的代碼結構，將業務邏輯分類并組織起來，可以服用的代碼由上層的父類實現。

模板模式的缺點：

如果類層級結構較多的時候，維護起來有點麻煩。

策略

策略模式也是非常常用的， 甚至很多時候它是其他模式的基礎。 它的思想也特別簡單。 當初它誕生的原因是為了擺脫大量的if else， 把每個條件分支做一個策略類。 具體原理我就不介紹了，不知道的可以google一下，網上一堆講設計模式的文章，我也講不出什么花來，我就講在UI自動化中我們怎么做。 舉一個最簡單的例子。如下：

在我們的測試中，大量的case都需要經過如下的操作步驟：

打開瀏覽器

登錄

進入模型IDE頁面

創建一個工程

創建一個DAG

在DAG頁面上build一個DAG

運行DAG并等待運行結束

既然大量的case都需要執行上面的操作，那我們當然就希望能做到代碼復用，所以就寫了一個方法來做這個事情。 但是我們發現這些步驟中有一個操作是無法預測的。 也就是如何Build一個DAG， 我們的產品的DAG如下

每個DAG中都有不同的算子組合在一起，形成一個圖形。并且每個算子有它不同的配置。 要在UI上build一個DAG還是需要很多的操作的。 并且case之間要build的DAG的圖形也是不一樣的。 有的case需要5個算子組成一個圖形， 有的case可能需要10個算子組成一個圖形。 這些是完全不一樣的操作， 也就是說雖然我們想寫一個方法來封裝上面所有的操作。但是其中構建DAG這一步是我們預先控制不了也復用不了的。這怎么辦？ 所以我們索性把build DAG的操作定義為一個接口。 如下：

它只有一個方法，就是build（）， 意思是這個方法要實現build一個DAG的操作。 但具體build一個什么圖形什么配置的DAG， 由子類自己實現。

于是我們有了很多固定圖形的dag的子類， 他們分別實現不同的固定圖形的build 操作。 如下：

于是我們創建這個可以用來復用的方法：

可以看到這個方法里我們執行了上面說的所有的步驟，比如打開瀏覽器，登錄，跳轉頁面，創建工程等。 但是在build一個dag的時候，我們依賴一個DagBuilder類型的參數，也就是我們之前的定義的那個接口，當然這個dagbuilder使用了建造者模式，這個我們之后會講。 現在我們在case中就可以很愉快的使用很少量的代碼完成測試了。 如下：

當然熟悉函數式編程的同學會覺得這玩意非常眼熟。 實際上在java8中也完全可以使用lamda表達式來完成DagBuilder的構造

建造者

這里會涉及到建造者，策略和工廠三種模式的混合使用。可能會比較啰嗦還請大家耐心看完。

建造者模式和工廠模式都是用來創建對象的。 建造者模式適用于一個對象的內部有特別多的屬性需要外部來傳遞的情況。 比如在上一個說策略模式的例子中。我們把Dagbuilder作為策略類，在case調用的時候動態傳遞一個具體的Dagbuilder類型決定如何build一個DAG. 那么剛才我們也看到了一個DAG是非常復雜的，里面有不同的圖形， 并且即便圖形固定了， 但是里面的算子的類型和配置可能都會變化。 比如，按照上面的一個通用的模型訓練的DAG圖形， 我們就可以用下面的代碼來構建。

可以看到上面每個一個node的importToDag的方法中都會有兩個int類型的數字參數。 這個意思是將算子拖拽到DAG中的哪一個點上。 并且link方法用來連接兩個算子， build方法會執行UI操作配置當前算子。 通過這樣一段代碼就可以構建出上面講策略模式的時候，截圖中的那個DAG圖形。 我們會發現非常多的case都會用到這個圖形。 比如測試所有的模型訓練算法的時候， 都是走這個DAG圖形的。 所以我們理所應當的會想把這個圖形封裝起來給很多個case使用。 但是雖然case使用的圖形一樣，可是每個算子的配置可能是不一樣的， 而且可能在某一個節點上使用的算子都是不一樣的，這需要調用方動態的傳遞。 所以builder（建造者）模式是一個包含了很多個零件的對象， 它封裝了如何操作這些組件創造出最終調用方想要的東西。但是需要調用方自由的傳遞這些不同的零件給builder。 首先我們看看這個DAG的builder類中定義要使用的零件。

上面是我們構建這個模型訓練雙輸入DAG所需要的零件。 可以看到由一個數據節點，一個數據拆分算子，兩個特征抽取，一個模型訓練，一個模型預測和一個模型預估組成。 而且這些零件都分別有set方法讓調用方來設置。然后我們就可以在builder的build方法里使用本節里一開始貼出的代碼來動態的構建圖形了。

策略模式的混用

這里需要注意一點的是，這些零件大部分都是具體的實體類。 但是有些不是，比如模型訓練算法，我們規定的是一個抽象類型。 如下：

為什么這么做呢，因為對于所有要測試模型訓練的case來說。 圖形是固定的， 某些算法也是固定的。 不論測試什么模型訓練算法，都是一個數據下面連接數據拆分算法，再下面連接兩個特征抽取算法。 也就是說對于模型訓練算法來說，這些流程都是固定的，我們實現就知道該拉取什么樣的算子，只是配置需要調用方動態傳遞。 但是測試的時候我們有各種不同的模型訓練算法，這些可不是配置不同，而是連算子都變了， 所以我們把模型訓練算法抽象成策略類。我不需要知道到底該拉取哪一個算子，讓調用方動態傳遞就好了。 只要它傳遞的是我規定的策略類型，有規定的方法來設置這個算子就可以了。

工廠模式的混用

根據上面的策略模式和建造者模式的混用我們就可以比較方便的構建DAG圖形給case使用了。 但是還是有一點麻煩。那就是一個builder需要傳遞的零件太多了。這個體驗有點不友好。 而且我們發現在大多數的模型訓練測試場景下，我們只關心模型訓練算法的配置參數，而不是很在意其他算法的配置是什么樣子的。 這種場景下讓我一個一個的去傳遞這些零件還是有點麻煩。 或者說在有些情況下，我們是可以動態的推導出其他算子的配置的。 比如我這次要測試的是邏輯回歸這個算子。 那么邏輯回歸是一種二分類算子，那么其實它只能使用二分類的數據，特征抽取算法中只能使用二分類的label處理， 相應的下面也只能連接二分類算子的預測和評估算子。 這些都是我們可以動態推導出來的。 沒有必要讓使用者一個一個的去傳遞。所以我們在builder外面再包一層工廠， 一個創建builder的工廠。如下：

如上圖，根據傳遞的模型訓練算子的類型找到預先導入的數據，配置好特征抽取，推導出所有依賴的算子配置后。 配置好這個builder并返回給調用方。這樣我們通過之前講的fastCreateDag的策略模式的例子。 就可以在case中只寫入非常少量的代碼就完成了測試用例的編寫：

@Features(Feature.ModelIde)

可以看到上面的每一個模型訓練的case的代碼量都非常的少。