自动化测试中的pom模型浅谈

测试活动中，实现了自动化用例编码后，总会面临深度封装的问题，在代码编辑时就应考虑到低耦合的特性，且尽量简洁，以便后期个人维护。

利用POM(page object model)模型实现实际生产中的自动化测试，是实现低耦合及可复用性的一个可行方式。

pom中，我们将代码实现分层，一个项目中最基本结构有以下层次结构：

1.common 目录（公共方法的提取封装）

2.page/api 目录（对各UI页面或接口调用实现的封装）

3.cases 目录（测试用例/脚本目录）

4.datas 目录 （存放测试数据yaml文件）

5.report 目录（测试报告生成目录）

6.pytest.ini 文件（测试执行时的配置参数文件）

tips:各目录中的文件名命名规则要遵守实际使用框架的的命名规则。

一、common目录一般是存放测试代码中都需要用到的公共方法，比如在UI自动化中，对webdriver对象的实例化，在API自动化中对重复使用底层库requests的发送请求的动作都可进行提取，封装到一个base_page.py/base_api.py文件中，在其他文件中通过导包继承的方式实现类和方法的复用。

如：

此处将发送请求的动作封装到base_api.py文件中，将数据生成封装到create_data.py中，将各请求获取token的动作封装到get_token.py文件中，共性就是很多其他文件会复用他们，且不会发生方法的改写。

二、page/api 目录

1.在UI项目中，page目录内实现对各页面的封装，每个待测试的页面可以实现一个page，例如首页，可命名为house_page.py,达到见名知意的效果，也方便个人在其他文件中对该文件的导入复用以及后期维护，每个page文件中，实现对该页面中待操作的元素（表现层）以及各元素要实现的动作（操作层）的封装。

2.在接口项目中，api目录内实现对各接口实例的调用封装，方便在测试类中直接调用各api，无需在每个测试用例中重复造轮子。

如：

三、cases 目录用来存放实际的测试用例，每个文件以test开头命名，对page/api中的文件进行测试步骤的实现。例如：可根据自己习惯结合项目特点实现断言等功能。

四、datas 目录用来存放实现数据驱动时的各yaml文件，例如本人举例项目中，将各个接口的测试对应创建关联名的yaml文件，将数据写入yaml文件中，然后在测试用例中动读取态载入yaml文件中的数据，实现测试的数据驱动，当然，存放测试数据的方式有很多，录入csv文件，excel文件，json文件，yaml文件等，但是个人建议使用yaml文件，相对于其他几种格式文件，yaml支持更多格式形式的数据存放与读取，且能结构化存放与输出，方便后期个人修改与维护，并且在后期实现了定制框架后，其他代码能力不足的同事也方便上手使用该框架，不用去实现代码，也不用明白代码实现逻辑，只需维护对应的yaml文件即可。

如：

时间有限，有空再补充些pom模型中其他内容~