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é)了。 就是講我也講不出什么花來(lái)，只是網(wǎng)上的文章基本都是講解設(shè)計(jì)模式的本身實(shí)現(xiàn)，很少針對(duì)某一領(lǐng)域的實(shí)際場(chǎng)景去講具體改怎么用設(shè)計(jì)模式。 所以今天我只針對(duì)一些實(shí)際的場(chǎng)景來(lái)說(shuō)一下如何使用這些設(shè)計(jì)模式來(lái)完善UI自動(dòng)化。

工廠(chǎng)

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

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

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

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

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

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

單例

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

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)建模型的操作。 總不能直接在類(lèi)加載的時(shí)候就執(zhí)行吧。 至于在不加鎖的情況下判斷一下對(duì)象是否為null也是不行的。 因?yàn)楝F(xiàn)在的大規(guī)模UI自動(dòng)化都是并發(fā)執(zhí)行的。 所以可選的方案就是加鎖的雙重檢查機(jī)制以及靜態(tài)內(nèi)部類(lèi)了。 這里主要講一下靜態(tài)內(nèi)部類(lèi)吧， 雙重檢查機(jī)制估計(jì)大家都玩爛了。 如下：

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

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

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

模板

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

策略

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

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

打開(kāi)瀏覽器

登錄

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

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

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

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

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

既然大量的case都需要執(zhí)行上面的操作，那我們當(dāng)然就希望能做到代碼復(fù)用，所以就寫(xiě)了一個(gè)方法來(lái)做這個(gè)事情。 但是我們發(fā)現(xiàn)這些步驟中有一個(gè)操作是無(wú)法預(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è)圖形。 這些是完全不一樣的操作， 也就是說(shuō)雖然我們想寫(xiě)一個(gè)方法來(lái)封裝上面所有的操作。但是其中構(gòu)建DAG這一步是我們預(yù)先控制不了也復(fù)用不了的。這怎么辦？ 所以我們索性把build DAG的操作定義為一個(gè)接口。 如下：

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

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

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

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

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

建造者

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

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

可以看到上面每個(gè)一個(gè)node的importToDag的方法中都會(huì)有兩個(gè)int類(lèi)型的數(shù)字參數(shù)。 這個(gè)意思是將算子拖拽到DAG中的哪一個(gè)點(diǎn)上。 并且link方法用來(lái)連接兩個(gè)算子， build方法會(huì)執(zhí)行UI操作配置當(dāng)前算子。 通過(guò)這樣一段代碼就可以構(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è)圖形封裝起來(lái)給很多個(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類(lèi)中定義要使用的零件。

上面是我們構(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)用方來(lái)設(shè)置。然后我們就可以在builder的build方法里使用本節(jié)里一開(kāi)始貼出的代碼來(lái)動(dòng)態(tài)的構(gòu)建圖形了。

策略模式的混用

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

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

工廠(chǎng)模式的混用

根據(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)麻煩。 或者說(shuō)在有些情況下，我們是可以動(dòng)態(tài)的推導(dǎo)出其他算子的配置的。 比如我這次要測(cè)試的是邏輯回歸這個(gè)算子。 那么邏輯回歸是一種二分類(lèi)算子，那么其實(shí)它只能使用二分類(lèi)的數(shù)據(jù)，特征抽取算法中只能使用二分類(lèi)的label處理， 相應(yīng)的下面也只能連接二分類(lèi)算子的預(yù)測(cè)和評(píng)估算子。 這些都是我們可以動(dòng)態(tài)推導(dǎo)出來(lái)的。 沒(méi)有必要讓使用者一個(gè)一個(gè)的去傳遞。所以我們?cè)赽uilder外面再包一層工廠(chǎng)， 一個(gè)創(chuàng)建builder的工廠(chǎng)。如下：

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

@Features(Feature.ModelIde)

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