我们测试的系统一定不是只需要几条用例就可以测试完成的，所以需要维护大量的用例，本节主要讲述了使用ride来管理用例的一种方法，讲用例按照4层结构模式进行管理，让用例尽可能的可读和好维护。

13.1 整体结构

4层结构如下图所示。

用例层：用例执行的单位。

业务层：业务层服务于用例层，同时也服务于同层的其他业务。

数据层：服务于用例、业务、数据、元素各层。

元素层：服务于业务层。

资源文件：服务于整个用例框架。

13.2  元素层

元素层主要是指页面的各个元素的操作，主要就是点击和输入。如下图，我对3个页面，分别作了拆分，维护了3个元素子集。

一个页面下面就是对该页面下所有元素的相关操作。

13.3 数据层

数据层主要是对数据库的各种操作，包含增删改查等。我会以每个表作为一个子文件，然后下面是该表的各种操作。

13.4 业务层

 业务层主要是为了进行一些操作的封装，比如登录、或者重复使用的一些步骤等。

业务层调用的是数据层和元素层。

13.5 用例层

用例层也就是我们所编写的自动化用例，用例层调用的是业务层、数据层和元素层。用例层要求我们的用例尽量写成自然语言式的步骤，便于阅读。

所以我们再元素层、业务层命名关键字时需要下一些功夫，规范和合理的命名。

按照不同的层次结构进行管理后，整个用例的可读和维护性会更强。

当然是不是必须按照这4层结构来做呢？我认为大家完全可以以此为思路，然后做自己的创新来适应自己的项目结构。没有什么东西是不可变的，也没有必须遵循的统一的标准，在吸收优点的同时不断改善为适合自己项目的架构，才是最优的。

今天到这里把。这是年前的最后一篇了，祝大家新年快乐，新的一年，可以“牛”转自我，牛年更牛。

同样的，有错误还望海涵和指出，共同学习进步。