设计说明

API Object是Page Object设计模式在接口测试上的一种延伸，顾名思义，这里是将各种基础接口进行了一层抽象封装，将其作为object，通过不同的API对象调用来组装成不同的业务流场景。

业务流的接口测试，通常一个业务会有很多的接口依赖和调用，并且有些接口会有非常多的http协议字段填充，比如各种headers、token以及默认字段；有些接口会反复调用，有些接口会有较多的处理等。而针对这些情况，尤其是当项目接口越来越多，业务越来越繁杂，API Object的优势就凸显出来了

技术栈

• python
• requests
• pytest
• yaml
• 模板替换
• allure

分层设计

整个框架分为5层：Base层、接口层、业务层、用例层、数据层

如图所示：(流转图.png)

继承关系：用例层-->业务层-->接口层-->Base层。

调用关系：用例层（从数据层拿测试数据）-->业务层-->接口层-->Base层。

Base层

baseapi用于封装通用的接口流程方法，它代表的是通用接口的封装，用于跟各个api object提供支持，如提供发送http请求、读取yaml文件、替换数据等公共方法，而无关业务逻辑。

此外，baseapi的核心只关心api的通用逻辑（遵循设计模式中单一职责原则），所以这里对baseapi做了瘦身，解耦了无关逻辑（ 比如它不需要关心yaml用哪个库，能搞定就行 ），因此将工具方法单独封装到utils.py模块中，baseapi只需调用即可。

接口层

接口层是对所有基础单接口的封装，负责http协议的填充。

所有api进行http协议填充后，发送http请求并返回response，供后续对响应结果进行相关处理。

业务层

这一层，即业务流层，完成测试数据的组装并且通过调用不同的接口来实现具体业务逻辑。

用例层

这一层，通过调用不同的业务，来完成相关测试。用例层不关心底层逻辑，比如某个业务具体是如何实现的，测试数据是具体如何清洗组装的，它只关心测试逻辑，这个业务场景如何测试，如何断言。

如果在测试用例中直接塞进去各种http协议的填充过程，会导致用例慢慢的丢失重心，尤其是当业务越来越繁杂后，用例会非常臃肿难以维护。测试用例还是要围绕业务进行，业务要围绕实现进行，通过分层可以让用例更优雅更简洁。

数据层

测试数据（测试用例）通过yaml管理维护，结合pytest.paramtrize可以非常轻松完成数据驱动。在用例层获取yaml中的测试数据，然后将数据打包给业务层，业务层进行数据拆卸组装给到接口层，接口层再封装为http请求格式进行接口请求。这样当测试数据发生变化或者用例更新，我们将不用去更新测试代码，只需维护这份yaml文件即可。

项目结构说明

• api ---->接口层，单接口封装

• base ---->baseapi层

• page ---->业务层，业务场景封装

• common ---->公共方法

  • handle_assert ---->断言封装
  • handle_mysql ---->mysql数据库操作封装
  • handle_path ---->路径处理
  • utils ---->工具方法封装
  • wrapper ---->日志装饰器

• conf ---->配置文件

• data ---->测试数据

• log --->日志

• report --->测试报告

• testcase --->测试用例

• conftest --->前置条件处理

• pytest.ini --->pytest配置文件

• run.py --->测试用例运行主程序

接口依赖处理

token

token或者cookies需要登录获取，后续其它接口大多需要其鉴权，因此将登录接口作为前置条件放于conftest.py中。

如何获取传递token呢？

在用例中调用conftest.py的get_login_data()即可。

测试数据动态处理

测试数据中的参数有时候不能写死，而是动态变化由上一个接口的返回值中获取的。而本框架的测试数据又都是由yaml管理，那么如何能让yaml中的测试数据“动”起来呢？

框架采用的是模板引擎替换技术。

举个栗子，比如在调用充值接口充值的时候，那么肯定要先拿到具体的需要充值的账户id，而账户id是由登录接口获取的，因此在构造充值测试数据时，账户id不能写死，而是以$标记，先调用登录接口拿到账户id，然后替换掉充值接口测试数据中的变量。

测试报告

运行run.py后，当用例全部执行完毕，allure会自动收集测试报告到/report/html/中，打开index.html即可看到完整测试报告。