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

工廠

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

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

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

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

封裝變化，我們把創(chuàng)建模型的所有操作都統(tǒng)一放在一起。之后生產(chǎn)模型的操作發(fā)生變化，比如需求變動。那我們只需要改動這一處就可以了。而且調(diào)用方也完全不感知

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

單例

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

UI操作尤其耗時，尤其是生產(chǎn)模型這種異步操作

UI本就不穩(wěn)定，這些重復(fù)的操作會增加case失敗的概率

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

靜態(tài)內(nèi)部類不會再LRModel的類加載的時候就加載，而是有人調(diào)用getInstance 的時候才會加載。所以保證了延遲加載

java 的classloader會保證靜態(tài)內(nèi)部類的線程安全，所以不用擔(dān)心并發(fā)的問題

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

模板

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

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

每個數(shù)據(jù)引入的關(guān)于生成table的操作的setTableConfig

每種數(shù)據(jù)引入的文件配置方式操作的setFileConfig

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

上面是結(jié)構(gòu)化數(shù)據(jù)的抽象類。 他實現(xiàn)了父類IDataload的setTableConfig方法。 因為所有結(jié)構(gòu)化數(shù)據(jù)引入的這個頁面操作都是一樣的。然后才是我們具體的本地文件的數(shù)據(jù)引入的類。如下。

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

基類IDataload負(fù)責(zé)定義執(zhí)行步驟，以及個別UI操作的實現(xiàn)。 規(guī)定子類必須實現(xiàn)setTableConfig和setFileConfig這兩個方法

類StructureDataLoad繼承基類IDataload，并實現(xiàn)了setTableConfig方法。 因為所有的結(jié)構(gòu)化數(shù)據(jù)引入在這里使用的是同樣的頁面

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

所以實際上調(diào)用方要做的事情就是這樣的

模板模式的優(yōu)點：

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

模板模式的缺點：

如果類層級結(jié)構(gòu)較多的時候，維護起來有點麻煩。

策略

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

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

打開瀏覽器

登錄

進(jìn)入模型IDE頁面

創(chuàng)建一個工程

創(chuàng)建一個DAG

在DAG頁面上build一個DAG

運行DAG并等待運行結(jié)束

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

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

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

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

于是我們創(chuàng)建這個可以用來復(fù)用的方法：

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

當(dāng)然熟悉函數(shù)式編程的同學(xué)會覺得這玩意非常眼熟。 實際上在java8中也完全可以使用lamda表達(dá)式來完成DagBuilder的構(gòu)造

建造者

這里會涉及到建造者，策略和工廠三種模式的混合使用?？赡軙容^啰嗦還請大家耐心看完。

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

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

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

策略模式的混用

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

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

工廠模式的混用

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

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

@Features(Feature.ModelIde)

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