可以看到，一个页面上的所有元素都是定义在这个 class 里面的。 并且这些元素的定位都是通过组件层的方法来完成的。 我们在文件开头就会引入这些组件库来帮助页面层来完成元素的定位于操作。 同时建议页面层文件不仅仅是封装单个元素的定位， 也可以封装页面里常用的操作。 我们推荐这种封装方式， 我们应该尽量避免在 case 中直接调用页面元素操作。 原因有二

• 代码复用， 大量 case 其实都需要调用相同的逻辑，封装成可复用的代码可以减少 case 编写成本
• 当页面元素出现变化，比如增删元素的时候。 可只修改封装的逻辑， 而不必大量修改 case。

组件层封装基本控件，应对前端组件库的变化， 而页面层就是对产品界面进行封装， 应对的是页面逻辑发生的变动

在我们的代码里， 每个模块都有 service 文件， 这个文件就是封装的业务逻辑的文件。 我们在页面层上封装的逻辑都是单页面逻辑。 而在测试中我们往往要执行一个很复杂的业务流程。 为了执行这样一个业务流程我们跳转了很多个页面。 所以我们有必要单独封装这样一层来把业务逻辑进行封装。 这里需要提一下， 业务逻辑层相当于页面层的上层封装。 封装了完成一个业务逻辑的所有操作，比如我们假设创建一个工作流， 需要先填写基本配置， 然后跳转到高级配置页面继续填写， 填写玩后点击确定显示创建成功， 到了这里还没结束，还需要等待这个工作流程执行到某个状态，比如运行成功状态。 这里面需要跳转多个页面，甚至还需要给定一个超时时间并轮询工作流程的状态。 为什么要封装这么一层呢， 因为必然有非常多的 case 去完成这样一个流程。

需要注意的是， 我们每个模块都需要封装自己的业务逻辑层。 因为一个产品里必然有非常多的模块并且这些模块之间是有依赖关系的。 比如我在之前讲大数据的时候介绍过， 一个大数据平台的产品中做什么事都需要先把外部数据源中的数据同步到本系统里对吧， 所以数据中心的测试人员就的把自己模块的业务逻辑封装一下给其他模块的人用。 同样的，模型中心模块的人要测试得先有个模型对吧， 那用来建模的建模中心就得把自己的业务逻辑封装好了给其他人用。 在 UI 自动化中往往就是这样的，各个模块之间需要互相配合，互相调用。 因为就是有很多 case 是横跨多个模块，链路非常长非常复杂的。

用例层就没啥好说的， 就是写 case 而已。 只不过在我的这个设计里， 用例层很轻， 大部分逻辑都已经被上面的 3 层做完了。 用例层大多数时候再调用业务逻辑层， 少数情况调用页面层。 所以 case 层很轻，代码很少。 没什么可以特别强调的。

搜索*TestingStudio霍格沃兹的干货都很硬核