今天跟朋友讨论了一下他公司selenium设计方式，对我来说很有启发。故总结下，后续根据这个理解在项目中完善下。
大致的项目结构：
- 基础方法
- 数据提供
- 元素封装
- 模块封装
- 用例组合
基础方法：
- 项目中全部方法封装汇总
- 项目中需要用到的基础功能支撑
数据提供：
- 数据库表的相关操作封装
其实最重要的还是表（库）的设计，因为在后续的操作中会出现很多相同数据的依赖，这样就需要我们能将表的设计更加合理，用起来才会更加方便-（这也是我目前所尴尬的地方） - Redis库相关操作的封装
这里主要存储一些临时数据，比如项目中生成的且对后续用例中依赖的数据；另外可以将一些预置数据提前从数据库中放在redis中，从而提高执行速度
元素封装：
- 这里他们用的是统一处理，即 抓取被测页面元素，重新组装为
xpth格式并分类，这样应用时直接调用 - 我准备将以页面为一个文件进行当前页面元素的封装，达到的效果就是使用这个元素的时候直接
pages.element_name
模块封装：
- 这是一个比较难的问题了，有的时候会出现模块的边界划分问题；什么是一个模块，大到完成一个功能，小到一个元素的操作；
- 目前来说模块的划分还是跟实际业务联系起来是比较好的，最常见的登录、注册、退出登录等等，单独封装保准没问题；
- 其实有的时候让你去硬生生的建一个模块或许挺难的，但是从用例中提取出通用的部分，单独封装起来这样就轻松许多；-- 我这么做的
- 还有个问题，我希望再用例中只是实现顺序、逻辑的拼装，不涉及到元素操作类的东西，这样的话元素的所有操作都将在模块中完成；
- 最后最重要的就是在模块中要完成本模块元素的校验
用例组合
- 基础的东西已经在前几步全部完事了，在这里就轻松很多了，按照业务流程拼接组装吧；
总结：
1.原理比较浅显，基础方法、数据 和 元素为模块提供基础服务，主要的工作量在模块封装中
2.这种结构增加了复杂度，且维护成本增加了一层，但是代码查看起来比较整洁规范，个人感觉比较适合业务较稳定的公司；
3.模块封装的健壮性很重要，且模块大大增加的用例的组装速度，如果公司业务稳定，并且在模块中有一定沉淀，那么再新增一个UI校验点将简单很多；
