第一次搭接口自动化测试框架的时候我犯过一个典型的错误以为把 Postman 里的请求复制到 Python 脚本里再用 Pytest 跑起来就算完成任务了。后来发现真正让这套东西有长期价值的从来不是单个请求能跑通而是你如何组织用例、处理登录态、管理数据、应对限流、记录失败原因以及在一周之后改接口时还能稳定回归。在这条路上Pytest Requests 是一套非常合适的起点。Requests 负责把 HTTP 请求发出去Pytest 负责把用例组织起来两个库都足够轻足够流行也足够支撑到中大型接口自动化测试任务。1. 先搞清楚接口自动化测试框架真正解决的是哪类问题很多新手学接口自动化测试第一反应是“把手动点的接口变成自动化执行能省时间”。这个理解没有错但只看到了表层。真正值得投入这件事的原因不是省那几次点击而是把测试判断变成可重复验证的资产。1.1 手动验证的痛点不只是慢手动点接口表面上看到的问题是效率低。接口一多每次回归都要从头点一遍几十个接口下来至少几十分钟。但更隐蔽的问题是两边手动点接口时很容易漏掉非关键字段的变化。人眼核对响应内容往往只看状态码和几个主要字段其他字段变动不会被察觉。手动操作没有留下可复用的检查资产。这周你仔细验证了登录、下单、查询订单下周别人改动了一行代码你又要重新点一遍而且可能漏掉上次发现的边界情况。接口自动化测试把“预期结果”变成代码里的断言。以后每次执行不仅能看到接口是否返回 200还能看到业务码、关键字段、数据结构是否仍然符合预期。失败时能精确定位到具体接口和字段而不是靠感觉找问题。1.2 Pytest Requests 组合为什么合适Requests 是 Python 里最常用的 HTTP 客户端。它的风格非常直接requests.post(url, jsonpayload, timeout10)一行就能发请求并拿到响应。它把 URL、Header、Body、响应解析都封装得很友好很适合测试脚本。Pytest 解决了组织用例的问题。fixture 可以处理前置条件参数化可以覆盖多组数据assert可以直接表达断言插件生态又提供了报告、重试、并行等能力。相比 Postman Newman 或者 JMeterPytest Requests 更接近“写代码”但灵活度高很多相比 Java 的 RestAssuredPython 的学习曲线更短更适合测试同学快速上手。不是说其他方案不好而是从 0 到 1 搭一套接口自动化测试框架这对组合几乎是成本最低的路径之一。1.3 主判断不是“更快”而是“可复用”我的一个核心判断是接口自动化测试框架的价值不是让你省几次点击而是把一次性的临时验证变成可重复执行的资产。具体体现在三个层面环境可复用测试环境、预发环境、生产环境的地址和账号通过配置切换不用改用例逻辑。逻辑可复用登录、鉴权、公共请求头、公共数据处理都集中在 fixture 和公共函数里后续用例直接引用。结果可复用测试报告、日志、失败信息可以通过 CI 保留下来成为团队回归的依据。所以哪怕你只是一个人维护测试这套框架也不是“写过就算完”而是“每次执行都在复用之前的判断”。2. 从零把最小可运行框架跑通很多人学接口自动化测试上来就想一次性把所有功能都做出来配置中心、数据驱动、报告、CI。结果光环境就配了好几天最后一条用例都没跑通。我更建议先搭一个“最小可运行框架”目标只有一个用 Pytest 跑通一条 Requests 用例。2.1 环境准备和项目目录建议使用 Python 3.10 及以上版本并用虚拟环境隔离依赖。一个可开始的目录结构是api_test/ config/ settings.py testcases/ test_login.py conftest.py requirements.txt pytest.ini每个文件干什么用可以先用一张表建立概念文件作用config/settings.py存放环境地址、账号、超时等配置testcases/test_login.py放接口用例一个文件对应一类接口conftest.py放全局 fixture、钩子、日志配置requirements.txt锁定依赖pytest.ini配置 pytest 默认行为这个结构不是唯一标准但它在“够简单”和“易扩展”之间比较平衡。后续想加数据目录、公共方法目录都可以在这个基础上扩。2.2 安装依赖并验证进入项目目录后创建虚拟环境并安装依赖python -m venv venv source venv/bin/activate # Windows 下执行 venv\Scripts\activate pip install pytest requests pytest --version建议把依赖写入requirements.txt可以锁一个大版本范围pytest7.0,9.0 requests2.28,3.0锁版本范围是为了避免未来第三方库升级导致行为变化。如果一个项目长期不锁版本某天pip install -r requirements.txt后可能因为依赖升级出现一堆原本不存在的失败。2.3 第一个 Requests 请求和 Pytest 用例假设有一个登录接口地址是https://api.example.com/api/login接收 JSON返回标准业务结构。常见写法如下import requests BASE_URL https://api.example.com def test_login(): url f{BASE_URL}/api/login payload { username: test_user, password: test_password, } resp requests.post(url, jsonpayload, timeout10) assert resp.status_code 200, fHTTP状态码异常: {resp.status_code} data resp.json() assert data[code] 0, f业务码异常: {data} assert data[data][token], 响应中没有 token这里有两个容易忽略的点timeout必须设置。如果不设置一次请求卡住测试可能挂很久网络抖动时整个任务看起来像死掉很难排查。断言不能只看status_code。HTTP 200 只能说明请求链路通了业务逻辑可能仍然报错。所以要同时校验业务码和关键字段。如果接口返回的不是 JSONresp.json()会抛异常。可以先判断响应类型也可以让异常自然暴露出来再根据返回内容调整处理。2.4 让第一条用例独立跑起来运行pytest testcases/test_login.py -s-s可以显示 print 输出调试时好用。判断“最小可运行框架”是否达成不是看代码量而是看三条用例能稳定通过失败时能通过assert信息直接定位问题所有地址和账号都还能方便更换。不要在这个阶段急着做封装、数据驱动、HTML 报告。先让一条用例在 5 分钟内跑通后面所有复杂能力都是在稳定基础上加出来的。注意本地学习阶段图省事可以把地址和账号写在用例里但至少心里要清楚下一步就要把它们抽到配置文件中硬编码越久切换环境时越痛苦。3. 用 Fixture 和配置把框架立起来最小框架跑通后下一步是解决重复代码登录逻辑、
