用 Python requests 和 pytest 搭一个接口自动化框架

3. 配置文件

这里放两个配置文件：base.ini 管数据库连接，interface.ini 放各个接口自己的配置。

4. 日志文件

日志按日期滚动，log.log 是当天文件，其余是历史日志。

5. 参数化与测试文件

conftest.py 是 pytest 的固定入口文件，放在被测接口脚本同目录下，负责给测试文件提供参数化支持。test_XXX.py 是具体的接口测试脚本，XXX 对应接口名。

6. 执行入口

run.py 是测试执行入口。如果框架接到 Jenkins 上做持续集成，也可以直接让 Jenkins 触发，不一定非要走这个脚本。

使用方式

假设现在要测一个叫 abc 的接口，流程会是这样：

1. 在 interface.ini 里新增 abc 节点，把参数文件格式、HTTP 请求方式、接口 URL、接口 Wiki 配好。
2. 在 caseparams 目录下创建 abc.xlsx 用例数据文件。
3. 执行 common 目录下的 testcasetemplate.py，脚本会根据前两步的配置，在 casefile 目录生成 test_abc.py。
4. 在 test_abc.py 里补上断言，验证接口返回是否符合预期。
5. 执行 run.py 完成测试。

测试执行时，run.py 会指定 pytest 要跑的目录，也就是 testcase。pytest 先加载同目录下的 conftest.py，它会遍历所有以 test_ 开头的测试文件，调用 config.py 读取配置，再通过 get_caseparams.py 读取并组装参数，把测试数据传给测试文件。测试文件拿到参数后，拆分字段，调用 request.py 发 HTTP 请求，拿到 JSON 返回，再按实际场景去验证：

• 如果业务逻辑已经明确，能直接算出预期结果，就把预期值写进 Excel 或 YAML，执行时直接取出来和接口返回比对；
• 如果需要查库确认，就把入参写进 SQL 条件，调用 selectDB.py 拿到查询结果，再和接口返回比对；
• 如果逻辑更复杂，就在脚本里先算出预期结果，再做断言。

这套结构不追求花哨，核心是把'数据从哪来、请求怎么发、结果怎么验'拆开。这样后面接口多了，新增成本不会全压在测试脚本上。