总体规则
所有模块设计均遵循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标注。
具体如下：
