總體規則
所有模塊設計均遵循page object結構
- 用例層：測試人員編寫測試用例代碼的地方，可以調用page層和封裝層。
- page層：一個頁面一個類，包含該頁面的業務邏輯封裝以及部分控件定義。
- 封裝層：根據業務需要，封裝常用的業務邏輯(相比於page層的業務邏輯封裝，它的范圍更廣，有些時候是跨頁面的業務邏輯。 屬於模塊級的業務封裝)
頁面設計規則
所有導航，頁面輔助以及會跨越多個頁面的邏輯均涉及為接口，接口中定義默認實現。
如上圖的導航，二級導航以及頁面輔助功能都會在不同的主頁面上出現。 一級導航為幾乎所有頁面都會用到， 二級導航為該模塊下所有頁面會用到。 頁面輔助功能為不同的頁面會用到不同的頁面輔助功能。比如DAG頁面會使用元素列表和算子列表。 但是notebook文件只使用元素列表。 基於此種特性， 我們將這些功能設計為接口並提供默認實現。哪個頁面需要用到就去implement。以此來達到代碼復用的目的。例如：
由於jdk 1.8的接口有default實現的功能。所以需要用到相應功能的子類直接實現接口以繼承相應的能力。 這也是為什么選擇用jdk1.8的主要原因。
每個page類只負責自己頁面的邏輯
page類遵循一個原則---- 產品UI上這個頁面能做什么， 這個page類就只能做什么。 不准許跨頁面邏輯合並在一個類中實現(頁面可以有跨頁面和模塊級功能，但是具體每個頁面的邏輯必須由每個頁面自己實現)。 出現多個頁面共用的功能參考上一條規則將其實現為接口。
頁面類的類名以Page為結尾。 接口(共用邏輯)不得使用Page結尾
頁面較多的時候用來區分頁面和共用邏輯的規則
每個頁面以封裝業務邏輯為主，通過參數控制調用不同的業務邏輯。 無特殊情況下不要讓外界知道控件的信息。
如上圖，這是一個設置FE算子的邏輯，其他任何頁面或者測試用例都通過此邏輯來設置FE算子。外界不感知任何控件信息。 如需要不同的算子設置，可以在初始化該類對象的時候，set不同的屬性值。如下：
所有頁面邏輯皆返回特定頁面對象，以保證測試用例使用workflow式API。
以登錄為例。 如下圖：
登錄后，進入導航頁，然后在導航頁的方法如下：
在進入模型IDE的時候返回模型IDE page的對象。
這樣可以保持測試用例始終保持workflow式的調用。 如下：
除特別簡單的邏輯外。所有業務邏輯的參數均使用java bean以及枚舉封裝，禁止使用基本數據類型(int,String, long等)，並按照UI實際情況設計默認值
為防止產品設計變化，所有的業務邏輯參數都由java bean封裝。 因為如果不使用java bean而是使用基本數據類型。那么在產品變化的時候，比如UI上多了一個必填的元素的時候。方法簽名就會變化，導致所有調用此方法的調用方都要變化。 而是使用java bean封裝的參數可以在其中直接增加一個屬性並設置默認值即可。
如下圖：圖1為FE算子的配置類，圖二為調用方。
所有狀態嗎，產品特定文案，內置類型等均使用枚舉定義。並使用枚舉來規范入參。
產品文案會變化，狀態流轉會變化。 有些時候我們會使用相應的文案來搜索頁面控件， 有時候我們也會以查詢數據庫的方式來跟蹤任務的狀態， 並且這些會在整個測試的各個地方使用到。 所以嚴禁在case中或者page 類中直接使用字符串或者數據類型的變量直接使用。 而是要將他們提取為枚舉來使用。如下圖：
上圖是數據庫中一個任務當前狀態的枚舉類型，在case運行時會動態查詢數據庫中此任務的status字段來判斷任務當前狀態。在case中調用等待任務完成的時候，需要傳入此枚舉表示這個用例期望這次任務的結果是哪種狀態，如下圖表示期望dataload 運行成功。 當然也有些case會期望任務失敗。
模塊間有數據依賴的時候。每個模塊自己負責提供對外接口。
比如測試模型中心或者預估服務的時候，首先必須要有模型事先產出。而產出一個模型需要在模型IDE中執行很復雜的步驟，跳轉多個頁面。 那么模型IDE負責對外提供一個封裝了所有邏輯的簡單接口對外使用。 例如：
ModelIDE負責提供modelFactory，調用方只需要傳遞一個模型訓練算法的默認配置就可以產出相應算法的模型出來。 至於里面如何創建project和dag， 使用什么數據，怎么抽取特征等等都不是調用方關心的。 他們只要一個模型出來，至於這個模型怎么出來的邏輯，不要暴露給調用方。
所有業務邏輯使用@Step標注進行標記(allure 的特性).
用例編寫規則
每個case都必須使用Features,Stroies, Title 標注來為case添加report 信息(我們使用的是allure這個report框架)， 根據情況可以添加Description標注。
具體如下：
