UI自動(dòng)化常用設(shè)計(jì)模式深度解析

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

工廠

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

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

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

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

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

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

單例

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

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

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

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

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

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

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

模板

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

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

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

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

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

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

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

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

類StructureDataLoad繼承基類IDataload，并實(shí)現(xiàn)了setTableConfig方法。 因?yàn)樗械慕Y(jié)構(gòu)化數(shù)據(jù)引入在這里使用的是同樣的頁面

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

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

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

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

模板模式的缺點(diǎn)：

如果類層級(jí)結(jié)構(gòu)較多的時(shí)候，維護(hù)起來有點(diǎn)麻煩。

策略

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

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

打開瀏覽器

登錄

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

創(chuàng)建一個(gè)工程

創(chuàng)建一個(gè)DAG

在DAG頁面上build一個(gè)DAG

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

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

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

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

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

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

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

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

建造者

這里會(huì)涉及到建造者，策略和工廠三種模式的混合使用?？赡軙?huì)比較啰嗦還請(qǐng)大家耐心看完。

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

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

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

策略模式的混用

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

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

工廠模式的混用

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

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

@Features(Feature.ModelIde)

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