前两天有个做测试的朋友问我“接口自动化到底怎么入门我看了一圈教程不是太理论就是太碎片看完还是不知道从哪下手。”这个问题我太熟了——五年前我刚开始接触接口自动化时也走过不少弯路。现在的教程铺天盖地但真正能把“Python Requests做接口自动化”这件事从环境搭建讲到框架设计、再到问题排查讲明白的其实不多。这篇文章就围绕这个题目把我这几年在实际项目中用Requests库做接口自动化的经验完整梳理一遍。不绕弯子不堆概念直接讲怎么落地。内容涵盖Requests库的核心用法、接口自动化的框架设计思路、pytest集成、数据驱动、以及我踩过的那些坑比如429限流、连接池、SSL报错。无论你是刚入门的小白还是已经在做功能测试想转自动化的同学这篇文章都能给你一条清晰可行的路径。1. 内容整体设计与思路拆解1.1 Requests凭什么成为接口自动化的首选先说结论在Python生态里做HTTP接口请求Requests库就是事实上的标准。它比urllib好用太多比aiohttp更贴近普通测试人员的认知模型而且安装简单、文档完善、社区庞大。为什么urllib不好用举个简单例子urllib处理Cookie要手动构建opener处理请求头要逐字段设置返回的响应对象操作起来也别扭。而Requests把这些全部封装好了一行代码发起请求一行的代码拿响应Cookie、Session、代理、证书校验、超时控制这些都是开箱即用。这些年我也见过不少做接口自动化的团队直接用Java、Go甚至Postman做集合测试。但Python Requests组合的优势非常明显代码量少、上手快、生态完善尤其是配合pytest这类测试框架后断言、参数化、固件、报告一整套都能无缝衔接。对于一个需要长期迭代的自动化测试项目来说可维护性和可扩展性才是关键而这一点Python生态几乎是无敌的。1.2 接口自动化到底在自动什么很多人一听“自动化”就想着把功能测试里的点点点变成脚本跑其实接口自动化的核心逻辑完全不同。接口自动化做的事情本质上是三件发请求、验响应、做报告。剥离掉复杂的业务场景任何一个接口自动化用例都逃不出这三步。你要做的就是把这三步变成可重复执行的代码然后把它挂到定时任务或CI流水线上让它自动回归、自动报警。这里有个很重要的观念转变接口自动化不是测试人员的独角戏它更多是技术保障体系里的一环。我参与过的几个项目里接口自动化用例跑得好的往往是测试和开发一起维护的开发提供接口文档和Mock服务测试负责编写用例和断言运维负责CI编排。想清楚这一点你在设计用例时就会有意识地考虑稳定性、可维护性和报告清晰度而不是一口气写几百个跑完就扔的死脚本。2. 环境准备与Requests核心用法2.1 环境搭建的正确姿势先说安装。Python的安装本身不复杂但有个细节很容易踩坑环境变量。Windows下安装Python时记得勾选“Add Python to PATH”否则在命令行里输入python会提示找不到命令。macOS和Linux一般自带Python但版本可能偏旧建议安装Python 3.8以上的版本。装好Python之后强烈建议用虚拟环境管理项目的依赖。我见过太多人把所有包一股脑装到全局环境里最后依赖冲突让人崩溃。推荐用Python自带的venv模块或者直接用pipenv、poetry这类工具也行。# 创建虚拟环境 python -m venv myApiTestEnv # 激活虚拟环境 # Windows: myApiTestEnv\Scripts\activate # macOS/Linux: source myApiTestEnv/bin/activate # 安装Requests pip install requests # 安装pytest和报告插件 pip install pytest pytest-html装完验证一下import requests print(requests.__version__)能正常输出版本号环境就算OK了。这里再推荐一个小工具——Postman或Apifox用来调试接口、查看响应结构非常直观能极大提升你编写测试脚本的效率。2.2 Requests最常用的7个方法Requests库的请求方法很简单和HTTP协议一一对应。日常接口自动化脚本里你最常用的就是get和post但put和delete也偶尔会用到先把全部掌握顺手。方法对应HTTP方法用途requests.get()GET查询资源requests.post()POST创建资源/提交数据requests.put()PUT更新资源requests.delete()DELETE删除资源requests.patch()PATCH部分更新资源requests.head()HEAD获取响应头requests.options()OPTIONS获取服务器支持的HTTP方法每个方法都有几个通用参数你几乎在每次请求中都会用到url请求地址paramsURL查询参数字典格式headers请求头字典格式data表单格式的请求体jsonJSON格式的请求体timeout超时时间单位秒proxies代理设置verifySSL证书校验开关2.3 发起第一个GET请求先来一个最简单的例子请求一个公开接口看下结构import requests url https://httpbin.org/get params {page: 1, size: 10} headers {User-Agent: Mozilla/5.0} resp requests.get(url, paramsparams, headersheaders, timeout10) # 响应状态码 print(resp.status_code) # 200 # 响应URL注意看这里params参数已经在URL里了 print(resp.url) # 响应内容JSON格式直接使用 .json() data resp.json() # 文本格式使用 .text print(resp.text) # 响应字节内容下载场景使用 print(resp.content)这里有几个关键点要讲清楚第一params参数传入的字典Requests会自动帮你拼接到URL上你不用手动去拼接?page1size10而且它会自动处理URL编码问题。第二resp.json()是接口自动化里最常用的方法它内部会先尝试把响应体解析成JSON解析失败就抛异常。第三务必设置timeout参数如果接口卡住脚本会一直等下去严重影响测试效率。2.4 POST请求的三种Body格式POST请求几乎是所有业务系统的核心操作而POST的请求体格式有讲究我在这里踩过不少坑。第一种JSON格式现在的接口大部分都是这种。用json参数传字典Requests会自动把字典序列化成JSON字符串并且设置Content-Type为application/json。url https://httpbin.org/post payload {username: testuser, password: 123456} resp requests.post(url, jsonpayload)第二种表单格式一些老的接口在用。用data参数传字典Requests会自动编码成key1value1key2value2的格式并且设置Content-Type为application/x-www-form-urlencoded。resp requests.post(url, data{key1: value1, key2: value2})第三种字符串格式少见但偶尔会遇到。直接传字符串然后手动指定Content-Type。比如传XML格式请求体xml_body usernametest/name/user headers {Content-Type: application/xml} resp requests.post(url, dataxml_body, headersheaders)这里有个经典坑如果你用data参数传一个字典但服务端需要的是JSON格式接口会报参数解析错误反过来你用json参数传数据但服务端需要的是表单格式也会出问题。对接接口前一定要看清楚接口文档里要求的Content-Type。我在项目里就遇到过后端同学把接口写成了JSON接收前端表单却一直提交成功的情况——这种情况测试时最容易误导人。3. 进阶核心细节与常见机制解析3.1 Session与会话保持接口自动化里有个必须理解的概念——会话。很多系统需要登录后才能访问业务接口登录之后服务端会下发一个Cookie或Token通常是Set-Cookie头后续请求必须带上这个凭证才能正常访问。如果每次请求都新建一个requests调用那Cookie就带不过去每次都要重新登录。正确的做法是用requests.Session()import requests session requests.Session() # 登录接口获取Cookie login_data {username: admin, password: 123456} resp session.post(https://your-api.com/login, jsonlogin_data) # 后续请求自动带上登录后的Cookie resp2 session.get(https://your-api.com/user/info)Session对象还有一个好处它内部维护了连接池多次请求可以复用底层的TCP连接性能上有明显提升。我在一次巡检类接口的测试里对比过用Session比每次新建请求快30%到50%。3.2 Token鉴权怎么处理现在的主流后端架构基本都转向了Token鉴权尤其是JWT。处理方式和Cookie不同Token一般不会自动带上需要你手动从登录接口的响应里提取再设置到后续请求的Header里。import requests BASE_URL https://your-api.com # 第一步登录获取Token login_resp requests.post(f{BASE_URL}/login, json{username: admin, password: 123456}) token login_resp.json()[data][token] # 第二步后续请求手动带上Token headers {Authorization: fBearer {token}} resp requests.get(f{BASE_URL}/user/info, headersheaders)这里推荐一个写法把获取Token的逻辑封装成一个函数用模块级的全局变量缓存Token避免每个用例都调用一次登录接口。Token有过期时间我一般还会判断Token的剩余有效期如果快过期了就先重新登录再拿新Token这样整套用例跑起来既稳定又高效。3.3 超时、重试与异常处理接口自动化最怕什么最怕线上接口突然变慢脚本超时挂掉还可以排查问题更怕接口直接返回一堆错误码然后脚本就报错把本来能用的用例也弄红了。超时设置一定要加。我习惯统一设置timeout(3, 10)第一个数字是连接超时时间第二个是读取超时时间。连接超时表示TCP握手过程的最大等待时间读取超时表示接收响应数据的最大等待时间分别控制能够快速定位是哪一步出现了问题。try: resp requests.get(url, timeout(3, 10)) resp.raise_for_status() # 状态码非2xx时抛出异常 except requests.Timeout: print(请求超时请检查网络或接口响应时间) except requests.ConnectionError: print(连接失败请检查服务是否存活) except requests.HTTPError as e: print(fHTTP错误{e})注意raise_for_status()这个方法它会在状态码为4xx或5xx时主动抛出异常方便你把错误路径统一交给异常处理逻辑。自动化的用例里我一般会区分“断言失败”业务逻辑不对和“请求异常”环境/网络/服务有问题这两类问题混在一起时排查效率极低。4. 搭建一个可落地的接口自动化测试框架4.1 框架分层设计从零搭建接口自动化框架别一上来就追求复杂先理解分层思想。我用的最多、最推荐的结构是这样的api_test_project/ ├── api/ # 接口封装层 │ ├── user_api.py │ └── order_api.py ├── test_cases/ # 测试用例层 │ ├── test_user.py │ └── test_order.py ├── conftest.py # pytest固件 ├── config.py # 配置信息 ├── utils/ # 工具类 │ ├── client.py # 请求封装 │ ├── log.py # 日志封装 │ └── assert_utils.py # 断言工具 ├── data/ # 测试数据excel或yaml │ └── user_data.yaml ├── reports/ # 测试报告 └── requirements.txt这个分层的核心逻辑是接口封装层负责定义接口的调用方式测试用例层负责描述测试场景并写断言数据层负责管理测试数据工具层提供通用的能力。各层之间单向依赖互不交叉。我见过很多失败的自动化项目问题几乎都出在同一处用例直接裸调requests.get每个用例里写死URL、请求头、参数一旦接口地址变更几百个用例要同时改。有了接口封装层你只改一处所有用例自动生效。这个前期设计带来的维护成本差异我印象太深了。4.2 用pytest组织和管理用例pytest是Python生态里最强大的测试框架之一和Requests是天作之合。它天然支持测试固件、参数化、插件扩展而且断言写法非常简洁。先看一个最直接的例子import pytest import requests # conftest.py中定义一个session级别的fixture pytest.fixture(scopesession) def session(): s requests.Session() yield s s.close() def test_get_user_info(session): resp session.get(https://your-api.com/user/1) assert resp.status_code 200 assert resp.json()[code] 0 assert resp.json()[data][name] 张三pytest规范下测试文件必须以test_开头函数名以test_开头这样pytest才能自动发现这些用例。命令也很简单pytest -v test_cases/加-v可以输出每个用例的执行结果-k可以按表达式筛选用例-m可以按标记执行分组用例。这套组合拳足够覆盖日常绝大多数场景。4.3 数据驱动用YAML管理测试用例接口自动化做到一定程度你会发现用例结构高度相似一样的URL不一样的数据不一样的断言。这时候就该引入数据驱动了。我推荐用YAML来管理接口测试数据因为它的格式可读性好嵌套结构也清晰。下面是一个例子# user_data.yaml test_get_user: - name: 正常查询用户 url: /user/1 expect_status: 200 expect_code: 0 expect_name: 张三 - name: 用户不存在 url: /user/99999 expect_status: 200 expect_code: 1001 expect_msg: 用户不存在然后在用例里用pytest的pytest.mark.parametrize装饰器结合YAML读取的结果做参数化import pytest import yaml import requests with open(data/user_data.yaml, encodingutf-8) as f: test_data yaml.safe_load(f) pytest.mark.parametrize(case, test_data[test_get_user], ids[case[name] for case in test_data[test_get_user]]) def test_get_user(case, session): resp session.get(fhttps://your-api.com{case[url]}) assert resp.status_code case[expect_status] body resp.json() assert body[code] case[expect_code] if expect_name in case: assert body[data][name] case[expect_name]这样加新用例时只需要在YAML里加一组数据就行完全不用改代码。我参与的支付项目里对接活动营销接口的用例大概有100多条用这种方式维护下来成本极低。4.4 断言与报告的最佳实践断言这块有个原则尽量断言“业务状态码”而不是只断言HTTP状态码。很多接口即使业务处理失败HTTP状态码也是200只是响应体里的code字段变了。如果只断言HTTP 200接口逻辑错了测试照样通过那这用例写了一票白写。def assert_success(resp, expect_code0): assert resp.status_code 200 body resp.json() assert body[code] expect_code, f业务状态码异常: {body} assert body[msg] success if msg in body else True报告方面pytest-html是最常用的方案pytest -v --htmlreports/result.html --self-contained-html--self-contained-html这个参数很实用它会把CSS和JS全部内嵌到HTML文件里方便直接发给其他人查看不会因为样式文件缺失而乱码。我还有个小习惯给自动化脚本加日志记录。用Python自带的logging模块把每次请求的URL、请求头、响应状态码、响应时间记录下来。接口出问题时日志是排查的第一手资料比看测试报告快得多。5. 踩坑实录接口自动化常见问题排查技巧5.1 “429 Too Many Requests”限流问题解析前阵子有同学在群里发了个报错“exceeded retry limit, last status: 429 too many requests”问这是什么情况。这就是典型的接口限流——你在一段时间内请求次数太多服务端直接不给你返回数据了而是返回429状态码。429的含义是“请求过多”它本质上是服务端的保护机制。遇到429手动重复重试没有意义必须从策略层面解决降低请求频率在循环请求之间time.sleep()一下比如每次间隔0.5秒到1秒。设置重试退避策略遇到429时等待一段时间比如30秒后再重试而不是立即高频重试。使用带鉴权的请求很多服务对匿名请求和认证请求的限流阈值不一样用了合法的Token后上限会显著提高。这个教训我记得特别深那时跑一批批量数据接口大概200个请求没有控制频率跑到第50个就触发了429脚本报错后我手动又从第1个开始跑结果又触发了一次。后来改成每请求间隔0.3秒整体跑完不仅没触发限流耗时反而能接受。接口自动化的间隔设计不能拍脑袋要结合服务端的限流阀值来定。5.2 SSL证书报错verify参数的正确用法内网测试环境经常遇到SSL证书问题报错长这样requests.exceptions.SSLError: HTTPSConnectionPool(...): Max retries exceeded with url: ... (Caused by SSLError(SSLCertVerificationError(1, [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed))原因很简单测试环境的证书不在系统的受信任证书列表里。解决办法有两个第一临时关闭证书验证仅限测试环境requests.get(url, verifyFalse)同时关掉InsecureRequestWarning告警否则控制台会一直刷warningimport urllib3 urllib3.disable_warnings(urllib3.exceptions.InsecureRequestWarning)第二给请求指定一个受信任的CA证书requests.get(url, verify/path/to/ca.crt)我个人建议即使是内网测试环境也尽量用第二种方式。verifyFalse确实方便但养成这个习惯后一旦切换到生产环境的巡检脚本忘了开证书验证安全问题就很难受了。5.3 连接池与Keep-Alive的影响Requests底层依赖urllib3的连接池。我在实际项目中发现大量短连接并发时偶尔会出现“Connection pool is full, discarding connection”的日志。这个有两个原因连接池默认大小是10并发太高时池子满了或者你的请求涉及跨域跳转连接没有有效复用。解决办法是把连接池调大from requests.adapters import HTTPAdapter session requests.Session() adapter HTTPAdapter(pool_connections10, pool_maxsize30) session.mount(http://, adapter) session.mount(https://, adapter)再说一个有关Keep-Alive的坑Session默认启用连接复用这对重复请求是好事但如果服务端有连接空闲回收机制长时间空闲的连接可能已被服务端断开客户端还不知道继续用旧连接发请求就会报ConnectionError: RemoteDisconnected或[Errno 104] Connection reset by peer。遇到这种场景要么在重试逻辑里重建连接要么适当调低连接的复用策略。5.4 接口参数类型的坑这部分是我最想说的。接口自动化的报错里有相当大比例不是代码问题是参数类型不对。举个典型例子很多后端接口要求id参数是Long类型但你在测试数据里写成了字符串1001。某些后端语言比如Java在序列化时会把字符串自动转成Long这种情况下测试能通过但如果框架严格一些直接返回参数类型错误。这类问题在本地联调时不容易暴露因为Postman会自动处理类型脚本里却往往传的是字符串。我的做法是写请求数据时明确区分字段类型。比如在YAML数据文件里给整型字段直接写数字不给引号test_order: - name: 创建订单 item_id: 1001 # 数字 quantity: 2 # 数字 remark: 自动测试 # 字符串在Python字典里也一样数字字段不要写成1001直接写1001。这个细节看起来很小但能帮你节省大量排查时间。前端传布尔值时也有类似的坑有些接口要求flag: true布尔类型但前端呼声很高的写法是flag: true字符串。Requests会把Python的True序列化成JSON的true把true序列化成字符串true如果后端对类型较敏感这两种传法的结果完全不同。5.5 编码与乱码问题接口返回的响应内容如果包含中文经常会遇到resp.text输出乱码。原因是响应头里的charset字段和服务端实际编码不一致或者干脆没声明。直接给一个稳妥方案resp.encoding resp.apparent_encoding # 从响应内容中自动检测编码 resp session.get(url) resp.encoding utf-8 # 或者根据文档明确指定 data resp.json() # JSON方法不受影响类似的请求数据本身有中文时requests会自动进行URL编码GET请求的params参数或字符串编码POST请求的data参数。如果手动拼URL时里面带了中文参数建议先用urllib.parse.quote处理一下避免编码不一致导致的404。5.6 重定向与文件下载的两个细节有的接口会做重定向比如301或302。Requests默认会自动跟随重定向你拿到的响应可能是最终页面。如果业务需要获取重定向后的URL可以通过resp.history查看跳转历史resp requests.get(url, allow_redirectsTrue) if resp.history: print(重定向了) for r in resp.history: print(r.status_code, r.headers.get(Location)) print(最终URL, resp.url)文件下载是另一个常见场景尤其适合用resp.content直接保存不要用resp.text因为文本解码会破坏二进制文件resp requests.get(file_url, streamTrue) with open(output.pdf, wb) as f: for chunk in resp.iter_content(chunk_size8192): if chunk: f.write(chunk)streamTrue的意义在于响应内容不会一次性全部读入内存特别适合下载大文件时防止内存被打爆。6. 我的体会接口自动化进阶方向与最后建议把上面这些内容跑通你已经能独立搭建一套好用的接口自动化框架了。但实际投入项目以后你还会遇到几个进阶问题。第一是接口依赖管理。下单接口通常要依赖登录接口的Token检测结果的接口可能又依赖下单接口生成的订单号。我一般用一个全局缓存字典来管理这些上下文数据在fixture里先跑前置接口保存关键数据后续用例直接从缓存里取。代码虽简单但用例间的顺序依赖很容易让框架变得脆弱——尽量用“每个用例独立准备数据”的思路来设计而不是依赖别人的执行结果。第二是结合CI/CD。理想状态是每个提交commit或每个合并merge之后自动触发接口测试任务。推荐用Jenkins或GitLab CI把pytest命令配好失败时自动发邮件或推送企业微信/钉钉消息这样接口问题能在几分钟内被发现而不是等到测试阶段才暴露。第三是用例分层。冒烟用例、业务主流程用例、全量回归用例的运行频率应该不同。冒烟用例每次构建都跑全量回归每天定时跑一次就够了。别把几百个用例不加区分地全部塞进每次构建那样既慢又容易因为个别非关键接口的波动导致构建一直红。最后说点掏心窝的话接口自动化本身是个工具真正的价值在于让你快速发现问题、准确定位问题。不要沉迷于花哨的框架和复杂的封装一套简单清晰、能持续维护的框架远比技术堆叠更实用。我在实际项目中见过太多因为过度设计导致框架没人敢动、最后废弃的例子。从最简单的脚本写起逐步迭代反而能走得更远。如果你是零基础建议先照着这篇文章把环境搭好写一个GET请求一个POST请求然后尝试用pytest管理两个用例再一步步加入Session、数据驱动、报告。等你把这条路走通之后再回头看那些复杂的自动化平台和框架你会发现所有东西都是在做同一件事发请求、验响应、做报告。抓住这个本质接口自动化就再也不会难住你。 
长河君 · 2026/9/7 23:12:22 · 阅读 1.2k Python+Requests接口自动化入门：从环境搭建到框架设计实战
前两天有个做测试的朋友问我“接口自动化到底怎么入门我看了一圈教程不是太理论就是太碎片看完还是不知道从哪下手。”这个问题我太熟了——五年前我刚开始接触接口自动化时也走过不少弯路。现在的教程铺天盖地但真正能把“Python Requests做接口自动化”这件事从环境搭建讲到框架设计、再到问题排查讲明白的其实不多。这篇文章就围绕这个题目把我这几年在实际项目中用Requests库做接口自动化的经验完整梳理一遍。不绕弯子不堆概念直接讲怎么落地。内容涵盖Requests库的核心用法、接口自动化的框架设计思路、pytest集成、数据驱动、以及我踩过的那些坑比如429限流、连接池、SSL报错。无论你是刚入门的小白还是已经在做功能测试想转自动化的同学这篇文章都能给你一条清晰可行的路径。1. 内容整体设计与思路拆解1.1 Requests凭什么成为接口自动化的首选先说结论在Python生态里做HTTP接口请求Requests库就是事实上的标准。它比urllib好用太多比aiohttp更贴近普通测试人员的认知模型而且安装简单、文档完善、社区庞大。为什么urllib不好用举个简单例子urllib处理Cookie要手动构建opener处理请求头要逐字段设置返回的响应对象操作起来也别扭。而Requests把这些全部封装好了一行代码发起请求一行的代码拿响应Cookie、Session、代理、证书校验、超时控制这些都是开箱即用。这些年我也见过不少做接口自动化的团队直接用Java、Go甚至Postman做集合测试。但Python Requests组合的优势非常明显代码量少、上手快、生态完善尤其是配合pytest这类测试框架后断言、参数化、固件、报告一整套都能无缝衔接。对于一个需要长期迭代的自动化测试项目来说可维护性和可扩展性才是关键而这一点Python生态几乎是无敌的。1.2 接口自动化到底在自动什么很多人一听“自动化”就想着把功能测试里的点点点变成脚本跑其实接口自动化的核心逻辑完全不同。接口自动化做的事情本质上是三件发请求、验响应、做报告。剥离掉复杂的业务场景任何一个接口自动化用例都逃不出这三步。你要做的就是把这三步变成可重复执行的代码然后把它挂到定时任务或CI流水线上让它自动回归、自动报警。这里有个很重要的观念转变接口自动化不是测试人员的独角戏它更多是技术保障体系里的一环。我参与过的几个项目里接口自动化用例跑得好的往往是测试和开发一起维护的开发提供接口文档和Mock服务测试负责编写用例和断言运维负责CI编排。想清楚这一点你在设计用例时就会有意识地考虑稳定性、可维护性和报告清晰度而不是一口气写几百个跑完就扔的死脚本。2. 环境准备与Requests核心用法2.1 环境搭建的正确姿势先说安装。Python的安装本身不复杂但有个细节很容易踩坑环境变量。Windows下安装Python时记得勾选“Add Python to PATH”否则在命令行里输入python会提示找不到命令。macOS和Linux一般自带Python但版本可能偏旧建议安装Python 3.8以上的版本。装好Python之后强烈建议用虚拟环境管理项目的依赖。我见过太多人把所有包一股脑装到全局环境里最后依赖冲突让人崩溃。推荐用Python自带的venv模块或者直接用pipenv、poetry这类工具也行。# 创建虚拟环境 python -m venv myApiTestEnv # 激活虚拟环境 # Windows: myApiTestEnv\Scripts\activate # macOS/Linux: source myApiTestEnv/bin/activate # 安装Requests pip install requests # 安装pytest和报告插件 pip install pytest pytest-html装完验证一下import requests print(requests.__version__)能正常输出版本号环境就算OK了。这里再推荐一个小工具——Postman或Apifox用来调试接口、查看响应结构非常直观能极大提升你编写测试脚本的效率。2.2 Requests最常用的7个方法Requests库的请求方法很简单和HTTP协议一一对应。日常接口自动化脚本里你最常用的就是get和post但put和delete也偶尔会用到先把全部掌握顺手。方法对应HTTP方法用途requests.get()GET查询资源requests.post()POST创建资源/提交数据requests.put()PUT更新资源requests.delete()DELETE删除资源requests.patch()PATCH部分更新资源requests.head()HEAD获取响应头requests.options()OPTIONS获取服务器支持的HTTP方法每个方法都有几个通用参数你几乎在每次请求中都会用到url请求地址paramsURL查询参数字典格式headers请求头字典格式data表单格式的请求体jsonJSON格式的请求体timeout超时时间单位秒proxies代理设置verifySSL证书校验开关2.3 发起第一个GET请求先来一个最简单的例子请求一个公开接口看下结构import requests url https://httpbin.org/get params {page: 1, size: 10} headers {User-Agent: Mozilla/5.0} resp requests.get(url, paramsparams, headersheaders, timeout10) # 响应状态码 print(resp.status_code) # 200 # 响应URL注意看这里params参数已经在URL里了 print(resp.url) # 响应内容JSON格式直接使用 .json() data resp.json() # 文本格式使用 .text print(resp.text) # 响应字节内容下载场景使用 print(resp.content)这里有几个关键点要讲清楚第一params参数传入的字典Requests会自动帮你拼接到URL上你不用手动去拼接?page1size10而且它会自动处理URL编码问题。第二resp.json()是接口自动化里最常用的方法它内部会先尝试把响应体解析成JSON解析失败就抛异常。第三务必设置timeout参数如果接口卡住脚本会一直等下去严重影响测试效率。2.4 POST请求的三种Body格式POST请求几乎是所有业务系统的核心操作而POST的请求体格式有讲究我在这里踩过不少坑。第一种JSON格式现在的接口大部分都是这种。用json参数传字典Requests会自动把字典序列化成JSON字符串并且设置Content-Type为application/json。url https://httpbin.org/post payload {username: testuser, password: 123456} resp requests.post(url, jsonpayload)第二种表单格式一些老的接口在用。用data参数传字典Requests会自动编码成key1value1key2value2的格式并且设置Content-Type为application/x-www-form-urlencoded。resp requests.post(url, data{key1: value1, key2: value2})第三种字符串格式少见但偶尔会遇到。直接传字符串然后手动指定Content-Type。比如传XML格式请求体xml_body usernametest/name/user headers {Content-Type: application/xml} resp requests.post(url, dataxml_body, headersheaders)这里有个经典坑如果你用data参数传一个字典但服务端需要的是JSON格式接口会报参数解析错误反过来你用json参数传数据但服务端需要的是表单格式也会出问题。对接接口前一定要看清楚接口文档里要求的Content-Type。我在项目里就遇到过后端同学把接口写成了JSON接收前端表单却一直提交成功的情况——这种情况测试时最容易误导人。3. 进阶核心细节与常见机制解析3.1 Session与会话保持接口自动化里有个必须理解的概念——会话。很多系统需要登录后才能访问业务接口登录之后服务端会下发一个Cookie或Token通常是Set-Cookie头后续请求必须带上这个凭证才能正常访问。如果每次请求都新建一个requests调用那Cookie就带不过去每次都要重新登录。正确的做法是用requests.Session()import requests session requests.Session() # 登录接口获取Cookie login_data {username: admin, password: 123456} resp session.post(https://your-api.com/login, jsonlogin_data) # 后续请求自动带上登录后的Cookie resp2 session.get(https://your-api.com/user/info)Session对象还有一个好处它内部维护了连接池多次请求可以复用底层的TCP连接性能上有明显提升。我在一次巡检类接口的测试里对比过用Session比每次新建请求快30%到50%。3.2 Token鉴权怎么处理现在的主流后端架构基本都转向了Token鉴权尤其是JWT。处理方式和Cookie不同Token一般不会自动带上需要你手动从登录接口的响应里提取再设置到后续请求的Header里。import requests BASE_URL https://your-api.com # 第一步登录获取Token login_resp requests.post(f{BASE_URL}/login, json{username: admin, password: 123456}) token login_resp.json()[data][token] # 第二步后续请求手动带上Token headers {Authorization: fBearer {token}} resp requests.get(f{BASE_URL}/user/info, headersheaders)这里推荐一个写法把获取Token的逻辑封装成一个函数用模块级的全局变量缓存Token避免每个用例都调用一次登录接口。Token有过期时间我一般还会判断Token的剩余有效期如果快过期了就先重新登录再拿新Token这样整套用例跑起来既稳定又高效。3.3 超时、重试与异常处理接口自动化最怕什么最怕线上接口突然变慢脚本超时挂掉还可以排查问题更怕接口直接返回一堆错误码然后脚本就报错把本来能用的用例也弄红了。超时设置一定要加。我习惯统一设置timeout(3, 10)第一个数字是连接超时时间第二个是读取超时时间。连接超时表示TCP握手过程的最大等待时间读取超时表示接收响应数据的最大等待时间分别控制能够快速定位是哪一步出现了问题。try: resp requests.get(url, timeout(3, 10)) resp.raise_for_status() # 状态码非2xx时抛出异常 except requests.Timeout: print(请求超时请检查网络或接口响应时间) except requests.ConnectionError: print(连接失败请检查服务是否存活) except requests.HTTPError as e: print(fHTTP错误{e})注意raise_for_status()这个方法它会在状态码为4xx或5xx时主动抛出异常方便你把错误路径统一交给异常处理逻辑。自动化的用例里我一般会区分“断言失败”业务逻辑不对和“请求异常”环境/网络/服务有问题这两类问题混在一起时排查效率极低。4. 搭建一个可落地的接口自动化测试框架4.1 框架分层设计从零搭建接口自动化框架别一上来就追求复杂先理解分层思想。我用的最多、最推荐的结构是这样的api_test_project/ ├── api/ # 接口封装层 │ ├── user_api.py │ └── order_api.py ├── test_cases/ # 测试用例层 │ ├── test_user.py │ └── test_order.py ├── conftest.py # pytest固件 ├── config.py # 配置信息 ├── utils/ # 工具类 │ ├── client.py # 请求封装 │ ├── log.py # 日志封装 │ └── assert_utils.py # 断言工具 ├── data/ # 测试数据excel或yaml │ └── user_data.yaml ├── reports/ # 测试报告 └── requirements.txt这个分层的核心逻辑是接口封装层负责定义接口的调用方式测试用例层负责描述测试场景并写断言数据层负责管理测试数据工具层提供通用的能力。各层之间单向依赖互不交叉。我见过很多失败的自动化项目问题几乎都出在同一处用例直接裸调requests.get每个用例里写死URL、请求头、参数一旦接口地址变更几百个用例要同时改。有了接口封装层你只改一处所有用例自动生效。这个前期设计带来的维护成本差异我印象太深了。4.2 用pytest组织和管理用例pytest是Python生态里最强大的测试框架之一和Requests是天作之合。它天然支持测试固件、参数化、插件扩展而且断言写法非常简洁。先看一个最直接的例子import pytest import requests # conftest.py中定义一个session级别的fixture pytest.fixture(scopesession) def session(): s requests.Session() yield s s.close() def test_get_user_info(session): resp session.get(https://your-api.com/user/1) assert resp.status_code 200 assert resp.json()[code] 0 assert resp.json()[data][name] 张三pytest规范下测试文件必须以test_开头函数名以test_开头这样pytest才能自动发现这些用例。命令也很简单pytest -v test_cases/加-v可以输出每个用例的执行结果-k可以按表达式筛选用例-m可以按标记执行分组用例。这套组合拳足够覆盖日常绝大多数场景。4.3 数据驱动用YAML管理测试用例接口自动化做到一定程度你会发现用例结构高度相似一样的URL不一样的数据不一样的断言。这时候就该引入数据驱动了。我推荐用YAML来管理接口测试数据因为它的格式可读性好嵌套结构也清晰。下面是一个例子# user_data.yaml test_get_user: - name: 正常查询用户 url: /user/1 expect_status: 200 expect_code: 0 expect_name: 张三 - name: 用户不存在 url: /user/99999 expect_status: 200 expect_code: 1001 expect_msg: 用户不存在然后在用例里用pytest的pytest.mark.parametrize装饰器结合YAML读取的结果做参数化import pytest import yaml import requests with open(data/user_data.yaml, encodingutf-8) as f: test_data yaml.safe_load(f) pytest.mark.parametrize(case, test_data[test_get_user], ids[case[name] for case in test_data[test_get_user]]) def test_get_user(case, session): resp session.get(fhttps://your-api.com{case[url]}) assert resp.status_code case[expect_status] body resp.json() assert body[code] case[expect_code] if expect_name in case: assert body[data][name] case[expect_name]这样加新用例时只需要在YAML里加一组数据就行完全不用改代码。我参与的支付项目里对接活动营销接口的用例大概有100多条用这种方式维护下来成本极低。4.4 断言与报告的最佳实践断言这块有个原则尽量断言“业务状态码”而不是只断言HTTP状态码。很多接口即使业务处理失败HTTP状态码也是200只是响应体里的code字段变了。如果只断言HTTP 200接口逻辑错了测试照样通过那这用例写了一票白写。def assert_success(resp, expect_code0): assert resp.status_code 200 body resp.json() assert body[code] expect_code, f业务状态码异常: {body} assert body[msg] success if msg in body else True报告方面pytest-html是最常用的方案pytest -v --htmlreports/result.html --self-contained-html--self-contained-html这个参数很实用它会把CSS和JS全部内嵌到HTML文件里方便直接发给其他人查看不会因为样式文件缺失而乱码。我还有个小习惯给自动化脚本加日志记录。用Python自带的logging模块把每次请求的URL、请求头、响应状态码、响应时间记录下来。接口出问题时日志是排查的第一手资料比看测试报告快得多。5. 踩坑实录接口自动化常见问题排查技巧5.1 “429 Too Many Requests”限流问题解析前阵子有同学在群里发了个报错“exceeded retry limit, last status: 429 too many requests”问这是什么情况。这就是典型的接口限流——你在一段时间内请求次数太多服务端直接不给你返回数据了而是返回429状态码。429的含义是“请求过多”它本质上是服务端的保护机制。遇到429手动重复重试没有意义必须从策略层面解决降低请求频率在循环请求之间time.sleep()一下比如每次间隔0.5秒到1秒。设置重试退避策略遇到429时等待一段时间比如30秒后再重试而不是立即高频重试。使用带鉴权的请求很多服务对匿名请求和认证请求的限流阈值不一样用了合法的Token后上限会显著提高。这个教训我记得特别深那时跑一批批量数据接口大概200个请求没有控制频率跑到第50个就触发了429脚本报错后我手动又从第1个开始跑结果又触发了一次。后来改成每请求间隔0.3秒整体跑完不仅没触发限流耗时反而能接受。接口自动化的间隔设计不能拍脑袋要结合服务端的限流阀值来定。5.2 SSL证书报错verify参数的正确用法内网测试环境经常遇到SSL证书问题报错长这样requests.exceptions.SSLError: HTTPSConnectionPool(...): Max retries exceeded with url: ... (Caused by SSLError(SSLCertVerificationError(1, [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed))原因很简单测试环境的证书不在系统的受信任证书列表里。解决办法有两个第一临时关闭证书验证仅限测试环境requests.get(url, verifyFalse)同时关掉InsecureRequestWarning告警否则控制台会一直刷warningimport urllib3 urllib3.disable_warnings(urllib3.exceptions.InsecureRequestWarning)第二给请求指定一个受信任的CA证书requests.get(url, verify/path/to/ca.crt)我个人建议即使是内网测试环境也尽量用第二种方式。verifyFalse确实方便但养成这个习惯后一旦切换到生产环境的巡检脚本忘了开证书验证安全问题就很难受了。5.3 连接池与Keep-Alive的影响Requests底层依赖urllib3的连接池。我在实际项目中发现大量短连接并发时偶尔会出现“Connection pool is full, discarding connection”的日志。这个有两个原因连接池默认大小是10并发太高时池子满了或者你的请求涉及跨域跳转连接没有有效复用。解决办法是把连接池调大from requests.adapters import HTTPAdapter session requests.Session() adapter HTTPAdapter(pool_connections10, pool_maxsize30) session.mount(http://, adapter) session.mount(https://, adapter)再说一个有关Keep-Alive的坑Session默认启用连接复用这对重复请求是好事但如果服务端有连接空闲回收机制长时间空闲的连接可能已被服务端断开客户端还不知道继续用旧连接发请求就会报ConnectionError: RemoteDisconnected或[Errno 104] Connection reset by peer。遇到这种场景要么在重试逻辑里重建连接要么适当调低连接的复用策略。5.4 接口参数类型的坑这部分是我最想说的。接口自动化的报错里有相当大比例不是代码问题是参数类型不对。举个典型例子很多后端接口要求id参数是Long类型但你在测试数据里写成了字符串1001。某些后端语言比如Java在序列化时会把字符串自动转成Long这种情况下测试能通过但如果框架严格一些直接返回参数类型错误。这类问题在本地联调时不容易暴露因为Postman会自动处理类型脚本里却往往传的是字符串。我的做法是写请求数据时明确区分字段类型。比如在YAML数据文件里给整型字段直接写数字不给引号test_order: - name: 创建订单 item_id: 1001 # 数字 quantity: 2 # 数字 remark: 自动测试 # 字符串在Python字典里也一样数字字段不要写成1001直接写1001。这个细节看起来很小但能帮你节省大量排查时间。前端传布尔值时也有类似的坑有些接口要求flag: true布尔类型但前端呼声很高的写法是flag: true字符串。Requests会把Python的True序列化成JSON的true把true序列化成字符串true如果后端对类型较敏感这两种传法的结果完全不同。5.5 编码与乱码问题接口返回的响应内容如果包含中文经常会遇到resp.text输出乱码。原因是响应头里的charset字段和服务端实际编码不一致或者干脆没声明。直接给一个稳妥方案resp.encoding resp.apparent_encoding # 从响应内容中自动检测编码 resp session.get(url) resp.encoding utf-8 # 或者根据文档明确指定 data resp.json() # JSON方法不受影响类似的请求数据本身有中文时requests会自动进行URL编码GET请求的params参数或字符串编码POST请求的data参数。如果手动拼URL时里面带了中文参数建议先用urllib.parse.quote处理一下避免编码不一致导致的404。5.6 重定向与文件下载的两个细节有的接口会做重定向比如301或302。Requests默认会自动跟随重定向你拿到的响应可能是最终页面。如果业务需要获取重定向后的URL可以通过resp.history查看跳转历史resp requests.get(url, allow_redirectsTrue) if resp.history: print(重定向了) for r in resp.history: print(r.status_code, r.headers.get(Location)) print(最终URL, resp.url)文件下载是另一个常见场景尤其适合用resp.content直接保存不要用resp.text因为文本解码会破坏二进制文件resp requests.get(file_url, streamTrue) with open(output.pdf, wb) as f: for chunk in resp.iter_content(chunk_size8192): if chunk: f.write(chunk)streamTrue的意义在于响应内容不会一次性全部读入内存特别适合下载大文件时防止内存被打爆。6. 我的体会接口自动化进阶方向与最后建议把上面这些内容跑通你已经能独立搭建一套好用的接口自动化框架了。但实际投入项目以后你还会遇到几个进阶问题。第一是接口依赖管理。下单接口通常要依赖登录接口的Token检测结果的接口可能又依赖下单接口生成的订单号。我一般用一个全局缓存字典来管理这些上下文数据在fixture里先跑前置接口保存关键数据后续用例直接从缓存里取。代码虽简单但用例间的顺序依赖很容易让框架变得脆弱——尽量用“每个用例独立准备数据”的思路来设计而不是依赖别人的执行结果。第二是结合CI/CD。理想状态是每个提交commit或每个合并merge之后自动触发接口测试任务。推荐用Jenkins或GitLab CI把pytest命令配好失败时自动发邮件或推送企业微信/钉钉消息这样接口问题能在几分钟内被发现而不是等到测试阶段才暴露。第三是用例分层。冒烟用例、业务主流程用例、全量回归用例的运行频率应该不同。冒烟用例每次构建都跑全量回归每天定时跑一次就够了。别把几百个用例不加区分地全部塞进每次构建那样既慢又容易因为个别非关键接口的波动导致构建一直红。最后说点掏心窝的话接口自动化本身是个工具真正的价值在于让你快速发现问题、准确定位问题。不要沉迷于花哨的框架和复杂的封装一套简单清晰、能持续维护的框架远比技术堆叠更实用。我在实际项目中见过太多因为过度设计导致框架没人敢动、最后废弃的例子。从最简单的脚本写起逐步迭代反而能走得更远。如果你是零基础建议先照着这篇文章把环境搭好写一个GET请求一个POST请求然后尝试用pytest管理两个用例再一步步加入Session、数据驱动、报告。等你把这条路走通之后再回头看那些复杂的自动化平台和框架你会发现所有东西都是在做同一件事发请求、验响应、做报告。抓住这个本质接口自动化就再也不会难住你。