Pytest与Requests接口自动化测试框架搭建实战

Pytest 和 Requests 组合做接口自动化测试是目前 Python 后端测试里最常见、也最接近“成本低、见效快”这个目标的方案。这套框架解决的核心问题很直接把业务接口从手工验证变成脚本回归把重复的请求、断言、结果收集和报告展示做成一套可以重复跑的结构而不是散落一地的临时脚本。如果你刚接触接口自动化测试或者想从 Postman 手工点选往自动化方向过渡这篇内容会按零基础可落地的顺序拆清环境准备、用例编写、公共封装、批量执行和常见问题排查。看到“框架搭建”四个字不用紧张Pytest Requests 的最小可用形态其实非常简单一个测试目录、几个 test_ 开头的函数、一个发请求的公共封装就能跑起来。所谓框架化只是随着接口数量变多把重复的请求逻辑、断言逻辑、数据准备和结果收集逐步收拢到公共层。关键在于先有一条能稳定跑通的链路再慢慢加东西。下面按实际落地顺序拆从环境准备开始最后到批量执行和排坑。1. 先想清楚Pytest Requests 解决什么问题1.1 先把两个工具的分工拆开Requests 是 Python 的 HTTP 客户端库只负责一件事发送 HTTP 请求并接收响应。你在代码里写requests.get(url)、requests.post(url, jsondata)它会帮你处理 URL 拼接、请求头、请求体、Cookie、超时、SSL 校验这些底层细节。它本身没有测试能力不会帮你统计多少条用例通过、失败也不负责生成报告。Pytest 是测试框架负责用例的发现和组织。它会按规则找到名字以 test_ 开头的函数或文件按顺序或分组执行把断言失败的信息收集起来最后输出汇总结果。它还提供 fixture、参数化、标记、插件等机制用来解决用例复用、数据驱动和运行控制。所以 Pytest Requests 的本质是两条线Requests 负责“怎么发请求”Pytest 负责“什么时候执行、执行结果怎么判断、失败了怎么反馈”。理解这个分工后后面所有框架设计都围绕它展开不会跑偏。1.2 适合哪些场景不适合哪些场景适合的场景后端 RESTful API 的功能回归测试。比如新增了一个订单接口要求不影响旧的下单流程。多环境接口检查。开发环境、测试环境、预发环境同一套用例换 base_url 跑一遍。数据驱动的接口测试。同一个登录接口要验几十组账号和预期结果。接口层级的前置校验。UI 自动化跑之前先用接口准备测试数据或者先用接口做冒烟。不适合的场景纯 UI 自动化。按钮点击、页面元素、浏览器兼容这些应该交给 Selenium 或 Playwright。高并发压测。Requests 是同步请求会阻塞等待响应压测应该用 Locust、JMeter 这类专门工具。需要很复杂协议模拟的场景。gRPC、WebSocket、MQ 这类场景Requests 不是最合适的选择。这个边界不是说不可以而是不划算。接口自动化的核心价值是快速回归和拦截低级问题不是替代压测工具也不是替代 UI 测试。把边界认清楚后面做框架设计才不会越做越重。2. 环境准备从一个最小可运行用例开始2.1 环境检查和依赖安装先从 Python 3.8 以上版本开始。当前主流开发环境基本都在 3.9 到 3.12 之间Requests 和 Pytest 对这几个版本的兼容都很好。如果机器上还没装 Python直接装官网的稳定版即可不用刻意装老版本。项目目录建议单独建一个 venv避免依赖和系统环境互相干扰。命令行操作大概是这样mkdir api_test cd api_test python -m venv venvWindows 下激活虚拟环境venv\Scripts\activatemacOS 或 Linux 下激活source venv/bin/activate然后安装核心库和辅助库pip install requests pytest pytest-html pytest-rerunfailures如果想用并发执行可以装 pytest-xdist想用 Allure 报告装 allure-pytest。这一步先装三个就够后面用到再补。装完后验证pytest --version python -c import requests; print(requests.__version__)能看到版本号输出说明环境没问题。开发机只要有一个干净的独立目录后面所有依赖都有记录。2.2 第一个 pytest 用例在 api_test 目录下新建一个文件名字叫 test_smoke.pydef test_add(): assert 1 1 2 def test_sub(): assert 3 - 1 2然后执行pytest -v test_smoke.py-v会打印每条用例的执行结果看到 test_add 和 test_sub 都 PASSEDPytest 就正常工作了。之所以用 test_ 开头是因为 Pytest 默认的用例发现规则就是匹配 test_ 开头的函数、类和方法。文件名也建议用 test_ 开头目录命名也可以统一用 testcase 风格。2.3 加一个真正发 HTTP 请求的用例接下来给 Requests 一个真正的工作。示例用公开测试服务网上常见的接口测试服务是 httpbin.org。但办公环境里建议先确认网络可达性很多公司内网访问外网会不稳定还会遇到网络策略限制。实际落地时最好直接换成自己公司的开发或测试环境。import requests def test_get_request(): resp requests.get(https://httpbin.org/get, timeout10) assert resp.status_code 200执行pytest -v test_smoke.py如果看到 PASSED说明 Requests 已经能在当前环境里正常发起 HTTP 请求。这里有两个细节容易被忽略timeout10是必需的。如果不写Requests 会一直等待响应遇到服务端不返回的情况用例就会长时间挂住很难排查。不能只看状态码是 200 就认为通过了。很多接口在 200 状态下仍然会返回业务错误比如{code: 5001, message: 参数错误}。所以断言要分层先验状态码再验业务字段。3. 围绕 Requests 做基础封装session、超时、重试和统一断言3.1 为什么不能在每个用例里直接发请求如果只有几个用例直接在用例里requests.get完全没问题。但项目慢慢变大后问题就出来了每个用例都要写请求头token 一变所有用例都要改。每个用例都要处理超时、重试、日志代码重复。测试环境切换时base_url 到处散落。接口请求日志不统一出了问题不知道请求到底发出没有。所以框架化的第一个动作就是把 HTTP 请求收拢成一个公共封装。最小封装可以是一个函数也可以是类。我更建议用类因为后续要扩展 session、认证、公共参数类的扩展性更好。3.2 用 Session 复用连接和认证信息requests.Session很重要。它会在同一实例内复用 TCP 连接自动管理 Cookie还能统一设置请求头。比如登录后拿到 token可以存在 session.headers 里后续请求自动带上。import requests from requests.adapters import HTTPAdapter class ApiClient: def __init__(self, base_url, tokenNone): self.base_url base_url self.session requests.Session() # 有 token 就统一加到请求头 if token: self.session.headers.update({Authorization: fBearer {token}}) # 配置连接层重试只针对连接错误和读超时不是针对 429 adapter HTTPAdapter(max_retries2) self.session.mount(http://, adapter) self.session.mount(https://, adapter) def get(self, path, paramsNone): url self.base_url path return self.session.get(url, paramsparams, timeout10) def post(self, path, jsonNone): url self.base_url path return self.session.post(url, jsonjson, timeout10)这里有一个很容易踩的坑HTTPAdapter(max_retries2)负责的是连接失败或连接池读失败时的自动重试它不会把 HTTP 429 或 500 这类响应状态码当作失败去重试。很多新手以为设置 max_retries 后就能解决限流导致的 429实际不会。429 需要单独做状态码层面的重试策略。3.3 统一超时和异常处理封装里必须考虑两个问题。第一timeout10只认一个超时值其实可以传一个元组(连接超时, 读取超时)timeout(5, 15)5 秒内连不上就失败连上后 15 秒内读不到数据就失败。这个比只写一个数字更精细建议在自有项目里用。第二请求异常要转成清晰的信息。Requests 在连接失败时会抛出requests.exceptions.ConnectionError超时抛出requests.exceptions.Timeout如果不处理Pytest 会把它