【实战项目】基于Python+Pytest的电商全链路接口自动化测试框架（带Allure报告、Jenkins持续集成）

一、项目介绍

本项目搭建一套电商场景接口自动化测试框架，覆盖登录认证、商品管理、购物车、下单支付、订单查询、物流跟踪等核心业务链路。 传统手工版本回归测试重复工作量大，执行效率低，容易漏测，迭代回归成本高。因此搭建这套高复用、易维护、支持持续集成的接口自动化测试框架。 框架实现 yaml 数据驱动、接口关联、多种方式数据提取、接口断言；封装了数据库断言能力，集成 allure 可视化报告，接入 Jenkins + 钉钉消息推送，模拟企业版本迭代回归流程。

说明：本项目使用本地 Flask 接口服务作为被测对象，用于调试整套自动化框架。

二、整体技术栈

• 编程语言：Python
• 核心测试框架：pytest（用例管理、参数化、fixture 前置后置控制）
• 接口请求库：requests，完成二次封装 http 请求能力
• 数据提取：jsonpath、正则表达式；通过getattr反射执行 DebugTalk 自定义工具函数
• 配置 & 用例管理：yaml，维护接口信息、请求参数、提取规则、断言规则
• 数据库操作：SQLAlchemy，已封装数据库断言工具类（练手环境无业务 MySQL，业务用例未实际运行该能力）
• 测试报告：allure，生成可视化测试报告
• 持续集成：Jenkins + Linux，构建执行、钉钉机器人推送执行结果

三、项目整体架构设计

框架采用分层解耦的工程化思想，业务用例、测试数据、底层工具、环境配置完全分离，做到高复用、低耦合，便于后期维护扩展。

3.1 核心架构思想

1. 业务用例与代码分离：接口地址、请求头、请求参数、提取、断言全部写在 yaml，修改接口和用例不需要改动 Python 底层代码。
2. 数据驱动测试：配合@pytest.mark.parametrize做参数化，同一套执行逻辑执行多组测试数据。
3. 配置化接口关联：解析 yaml 中${func(params)}占位符，通过反射动态调用 DebugTalk 工具函数读取 extract.yaml，拿到上游提取的 token、goodsId、orderNo，实现上下游接口传参。
4. 双层断言设计：支持接口响应断言；封装数据库断言工具，校验数据库落库数据一致性。
5. 全局资源管控：conftest.py会话级 fixture 做全局前置后置；pytest.ini管理 pytest 执行规则。

3.2 项目真实目录结构

pythondemo # 电商接口自动化框架根目录 ├── base # 调度层：apiutil核心调度，串联单条用例完整执行流程 ├── common # 公共工具层：发送http请求、读写yaml、断言封装、日志、DebugTalk自定义函数、钉钉推送 ├── conf # 全局配置层：路径统一管理、读取ini环境配置文件 ├── data # 外部csv测试数据存放目录 ├── logs # 运行日志目录，按大小切割日志，自动清理30天旧日志 ├── report # Allure报告生成目录 ├── testcase # 业务用例层，按业务模块存放yaml用例与pytest执行入口 ├── extract.yaml # 存储接口关联提取出来的变量，供跨用例读取，仅适合串行执行 ├── conftest.py # pytest全局夹具，测试会话启动前清空extract.yaml，防止旧数据污染 ├── environment.xml # allure报告环境信息配置 ├── pytest.ini # pytest执行配置 ├── requirements.txt # 第三方依赖版本锁定 └── run.py # 项目启动入口脚本

四、核心功能亮点（面试重点）

4.1 HTTP 请求统一封装

对 requests 做二次封装，支持 GET、POST 各类请求，兼容 json、form 表单、文件上传；统一处理请求超时、网络异常；打印完整请求响应日志；捕获异常标记用例失败，不会中断整套测试执行。

核心封装代码如下：

4.2 yaml 数据驱动、配置解耦

摒弃代码硬编码，所有接口信息、参数、提取、断言维护在 yaml；新增 / 修改接口用例只维护 yaml，底层代码不用改动。 conf 层统一管理域名、路径等配置，切换环境修改配置文件即可。

4.3 配置化接口关联（项目核心）

执行流程中解析 yaml 里面${get_extract_data(key)}这类占位符。 1、上游接口执行完成，支持 jsonpath、正则两种方式提取字段，写入extract.yaml持久化； 2、执行下游用例时，解析占位符，通过getattr反射动态调用 DebugTalk 的工具函数读取变量，完成参数传递，串联登录‑商品‑购物车‑下单‑支付‑物流完整业务链路。

局限性：extract.yaml 是文件存储，只适合串行执行；多进程并发会出现读写冲突，如果企业项目需要并发可以改用 Redis，每条测试链路分配独立 key。 优化：最开始内存字典存变量，跨 py 文件执行内存销毁变量丢失；增加反射异常捕获，区分函数不存在、参数不匹配，输出友好日志，不抛出晦涩底层堆栈。 前置处理：通过 conftest 会话级 fixture，整套测试运行前清空 extract.yaml，防止上一轮测试脏数据。

4.4 双层断言体系

1. 接口响应断言：支持状态码、相等、不相等、包含等断言，多条断言全部执行完成后统一汇总失败结果；
2. 数据库断言：common 层封装 SQLAlchemy 数据库工具，支持 yaml 配置 sql 做落库校验。由于本项目配套 Flask 被测服务没有提供业务 MySQL，工具代码完成，但业务用例没有实际运行数据库断言场景。真实业务项目可以用来校验新增 / 修改接口的数据是否正确落库。

4.5 Allure 可视化测试报告

生成 allure html 报告，按业务模块归类用例；把请求、响应挂载报告附件；environment.xml 展示环境信息；自定义用例编号控制报告展示顺序，快速定位失败用例。

4.6 日志处理

使用 logging 模块，RotatingFileHandler 按文件大小切割日志；每次启动框架自动遍历日志目录删除超过 30 天的旧日志，防止磁盘占满。报告看执行结果，日志排查详细堆栈问题。

4.7 Jenkins + 钉钉机器人持续集成

Jenkins 拉取代码，安装 requirements.txt 依赖，执行 pytest 自动化；执行结束统计用例结果，调用钉钉 webhook 推送消息，包含总用例数、成功失败数量、allure 报告链接，不用登录 Jenkins 即可查看回归结果。

五、核心业务测试模块

基于本地 Flask 模拟接口，编写电商核心业务用例，一共 19 条用例：

• 用户模块：登录，用户增删改查，提取 token 鉴权
• 商品模块：商品列表、商品详情查询，提取 goodsId
• 购物车模块：添加购物车
• 订单模块：提交订单、支付、查询订单状态
• 物流模块：查询物流状态，完成整条业务闭环。

注意：当前框架只支持串行执行，大量用例无依赖的场景后续可以引入 xdist 多进程优化。

六、项目踩坑与优化思考

开发过程中两大难点是接口关联变量共享、yaml 配置反射调用。

1. 跨用例变量共享：一开始使用内存字典存储 token、goodsId，跨测试文件执行内存销毁，变量变成 None。改用 extract.yaml 持久化，搭配 session fixture 前置清空文件。但是文件存储方案有边界，不支持并发执行。
2. 反射动态调用提取函数：最初写大量 if‑elif 判断匹配函数名字符串，新增提取方法要修改底层代码；改用 getattr 反射动态调用 DebugTalk 工具。早期缺少异常捕获，yaml 写错函数名、参数数量不对直接抛出底层堆栈。补充异常捕获，区分函数不存在、参数不匹配，输出清晰提示日志，降低配置排错成本。

项目启发：开发自动化框架，不光要保证正向流程跑通，要评估每种方案适用场景；配置由使用者手写，框架要做好容错，把底层晦涩报错转化成友好提示，降低排查问题成本。

七、项目总结与收获

本项目是练手实战项目，整套框架按照企业落地标准设计，实现 yaml 数据驱动、配置化接口关联、多层断言、日志报告、Jenkins 持续回归整套流程。模拟业务测试同学只编写 yaml 即可新增用例，不用编写 Python 代码。 通过项目实战，我掌握 pytest 夹具原理、接口自动化分层架构、接口关联多种实现方案、异常容错设计、CI 持续集成流程。

本项目没有真正落地团队，使用本地 Flask 接口服务作为被测目标，用来验证整套自动化框架全部功能，本地和 Jenkins 环境反复调试验证功能可用。