如果你每天的工作里有大半时间是在Postman里把接口挨个点一遍复制响应结果去对字段再切到Excel里记一笔那我接下来说的这套东西应该能帮你从这种重复劳动里解放出来。用Python加requests写接口自动化测试并不是什么高深的技术但它能解决的问题非常具体让机器替你反复验证接口的返回值、状态码、业务逻辑是否符合预期把回归测试的时间从几个小时压缩到几分钟而且每次跑完都有清晰的结果记录可以追溯。这篇文章我会从方案选型开始讲为什么大家都选requests而不是Java或者Postman脚本然后一步步拆解requests请求对象、会话保持、断言体系、数据驱动再到用pytest把散落的脚本串成一套能跑、能出报告、能接入CI的框架最后把我这些年踩过的坑整理成一份排查清单。适合两种人看一种是有Python基础但没系统写过接口自动化的测试同学另一种是手工测试想转自动化、但对框架设计没什么概念的工程师。看完你至少能独立搭出一个可复用的接口测试项目而不是停留在“会用requests发个get请求”的层面。1. 方案设计为什么选requests而不是“全家桶”1.1 接口自动化到底在测什么很多新手会把接口自动化和UI自动化搞混觉得都是在页面上点点点。但实际上接口自动化测的是客户端与服务端的“通信协议”也就是HTTP请求和响应本身。你要验证的是请求参数传对了没有、鉴权信息带上没有、服务端返回的状态码对不对、关键字段的值是否符合预期、异常参数下服务端是否做了正确的拦截。这些校验点全部发生在“页面渲染之前”所以根本不需要浏览器一个能发HTTP请求的库就够了。用requests做这件事核心优势是它把HTTP协议里那些繁琐的底层细节封装得恰到好处。你不用手动拼接请求行、自己处理TCP连接只需要调用get、post、put这些方法传入url、参数、headersrequests就会帮你把请求发出去把响应解析成一个response对象。这个对象的status_code、text、json()方法覆盖了接口测试90%以上的断言需求”。相比你去解析原始报文再自己写校验逻辑节省的精力是肉眼可见的。1.2 市面上那么多工具为什么单选requests我见过不少团队在接口自动化选型时纠结Postman有Collection和Runner跑起来也能看报告JMeter能做压测顺便测接口Java那边有HttpClient和RestAssuredPython这边除了requests还有httpx。每个工具都有它的适用场景但如果你要的是一个“轻量、易维护、能和现有代码/CI深度整合”的方案requests几乎是目前综合成本最低的。拿Postman来说单次调试接口它确实方便可视化交互对新手很友好。但Postman脚本的断言语言偏向于“配置式”复杂逻辑写起来很别扭而且用例一多Collection的管理、环境变量的传递就容易乱成一团。PostmanNewman也能跑自动化可你很难在脚本里集成复杂的业务逻辑比如加解密、数据库校验、调用别的服务获取动态参数。一旦测试场景复杂起来它的天花板就很明显。JMeter的优势在于压测能力它做接口功能测试也可以但录制和维护jmx文件对测试人员的门槛比写Python脚本高得多。团队里随便一个新人都能用requests读一遍代码看懂逻辑但换到JMeter就得学习它的组件模型、监听器、配置元件那一整套东西。至于JavaHttpClient如果你团队本身就是Java技术栈、又需要跟Spring生态深度整合比如直接连公司的注册中心拿服务地址那选Java没问题但单纯为了接口自动化去维护一个Java工程编译、打包、依赖管理的成本会比Python高一个量级。所以我给团队定的方案一直很明确日常接口功能回归用Pythonrequests压测单独上JMeter或后续引入专业压测工具两者职责分开不需要一个东西扛所有任务。1.3 一个最小可用框架的构成当你只写一两个接口的验证脚本时requests直接能上但当你手上有几十上百个接口用例时必须考虑结构化。我推荐的最小框架包含四层用例管理层、请求发送层、断言校验层、报告执行层。用例管理层用YAML、JSON或Excel管理测试数据把“请求参数”和“预期结果”从代码里抽出来请求发送层封装统一的requests调用入口处理超时、重试、日志记录断言校验层抽象出公共的校验器统一处理状态码、字段值、业务码等断言报告执行层用pytest收集用例、执行并生成报告再配合定时任务或CI触发。这四层各自独立改用例不用动代码改请求封装不影响用例数据新增断言方式也不影响其他两层。后面我写的每一节基本都是围绕把这四层逐步搭出来的过程展开的。2. 环境搭建与requests核心用法2.1 开发环境准备Python、虚拟环境、pip安装如果你机器上还没装Python去官网下载对应操作系统的安装包即可装的时候记得勾选“Add Python to PATH”这个选项不然后续在命令行里敲python会提示找不到命令。建议直接用Python 3.8以上的版本我目前项目里用的3.10和3.11都很稳定requests对版本要求不苛刻只要不是太老的Python 2系就行Python 2官方都停止维护了新项目别碰。装完Python之后第一件事是建一个虚拟环境。这个步骤在你只有一个项目的时候看起来多余但当你同时维护多个项目、每个项目依赖的包版本还不一样时虚拟环境能救你的命。命令行里执行python -m venv venvWindows下激活命令是venv\Scripts\activateLinux/Mac是source venv/bin/activate。激活后命令行前面会出现一个(venv)前缀之后你安装的包都会进这个独立的虚拟环境不会污染全局。然后安装requests直接执行pip install requests有些人会遇到输出一段提示大意是“defaulting to user installation because normal site-packages is not writeable”这个不算报错意思是当前Python环境没有写权限所以pip把包装到了当前用户目录下。它能用但容易造成不同项目之间包混乱实际上反而说明你没用虚拟环境或者当前环境的site-packages权限有问题。建议先确认一下自己是不是在venv里如果在venv里还出现这个提示检查下虚拟环境有没有正确激活。装完之后验证一下版本python -c import requests; print(requests.__version__)能打出类似2.31.0这样的版本号环境就算通了。2.2 最常用的几个请求写法get、post与关键参数requests最迷人的地方就在于常用的请求真的只需要几行代码。比如一个最简单的get请求import requests resp requests.get( https://api.example.com/api/order/1001, headers{Authorization: Bearer xxxxx}, timeout10, verifyFalse ) print(resp.status_code) print(resp.text)这里面我想重点讲两个参数很多人会忽略但实际非常重要timeout和verify。timeout是请求超时时间单位是秒。如果你不设置它requests理论上会一直等下去直到TCP层自己超时这在自动化测试里是件很恐怖的事——一个接口挂了测试脚本可能卡在那里十几分钟不报错整个测试套件被拖死。所以我在代码里强制要求所有请求必须显式传timeout一般连通性测试给10秒涉及上传下载的大报文给30秒到60秒。verify是SSL证书校验开关默认是True也就是requests会校验HTTPS证书的合法性。如果你测试环境用的是自签名证书或者内网环境的证书链不完整requests会直接抛requests.exceptions.SSLError。遇到这种情况临时把verifyFalse关掉校验是一种常见做法但我建议你在关掉的同时加上urllib3的警告屏蔽不然每次请求控制台都会刷黄色的InsecureRequestWarning警告很干扰日志排错。后面排错章节我会专门贴这段代码。post请求传参有两种主流姿势data和json。很多新手特别容易搞混data传的是表单编码格式也就是application/x-www-form-urlencoded相当于你在网页上提交表单时浏览器发的那种bodyjson传的是JSON字符串Content-Type自动变成application/json。接口的Content-Type要求哪种你就用哪种参数不是想用哪个用哪个。如果接口定义的是JSON格式你用data传会让后端解析不到参数返回参数缺失之类的错误。# 表单格式 resp requests.post( https://api.example.com/api/login, data{username: admin, password: 123456}, timeout10 ) # JSON格式 resp requests.post( https://api.example.com/api/login, json{username: admin, password: 123456}, timeout10 )2.3 session会话保持登录态的正确管理方式接口测试里绕不开的一个问题是登录态管理。大多数业务接口都需要你先登录拿到token或cookie后续请求再带上这个凭证去访问。很多人第一次写自动化时是这么干的调登录接口从响应里解析token然后复制到下面每个请求的headers里。这样能跑但极其脆弱——token一旦过期你就要手动去改脚本而且一个个请求复制粘贴代码可维护性为零。正确做法是用requests的Session对象。Session可以理解成你和服务器之间的一条“持久连接通道”它会自动帮你保存服务端下发的cookie并且在同一个session实例发出的后续请求里自动带上这些cookie。你只需要做一次登录之后所有用session发的请求都会共享登录态。我举个例子模拟一个电商系统的登录和查询订单流程import requests session requests.Session() # 第一步登录 login_resp session.post( https://api.example.com/api/login, json{username: admin, password: 123456}, timeout10 ) print(登录响应:, login_resp.json()) # 第二步查询订单cookie/登录态自动携带 order_resp session.get( https://api.example.com/api/order/1001, timeout10 ) print(订单结果:, order_resp.json())对于前后端分离的项目登录后返回的不是cookie而是token那Session的cookie自动携带机制就派不上用场了。这种情况可以封装一个请求工具类在构造请求时自动把token塞进headers。我一般用一个模块级的全局变量保存token登录接口成功后在内存里更新它其他地方发起请求时统一从这个地方取。TOKEN def set_token(token): global TOKEN TOKEN token def auth_headers(): return {Authorization: fBearer {TOKEN}} if TOKEN else {}还有一种更稳妥的做法是把token持久化到文件或配置中心程序启动时先加载发现失效再重新登录获取。这样即使测试进程重启token还在能少一次登录请求。不过token的安全性要注意不要硬编码进代码仓库尤其是会推送到远端仓库的项目。2.4 文件上传下载与二进制流处理接口自动化不只测JSON接口文件上传和下载也是常见场景。上传接口一般用files参数传一个字典key是表单字段名value是文件对象。要注意的是如果你既传files又传datarequests会把它们组合成multipart/form-data格式发送。with open(test_report.pdf, rb) as f: resp requests.post( https://api.example.com/api/upload, files{file: (test_report.pdf, f, application/pdf)}, data{description: 月度测试报告}, timeout30 )下载接口则要关注stream参数。如果你直接resp.contentrequests会把整个响应体加载到内存里大文件容易把内存打爆。正确做法是设置streamTrue然后分块写入磁盘resp requests.get( https://api.example.com/api/download/20240101_report, streamTrue, timeout30 ) with open(report.zip, wb) as f: for chunk in resp.iter_content(chunk_size8192): if chunk: f.write(chunk)这里iter_content是按固定字节流式读取加上chunk的判断防止有些响应没有实际数据时写空块。这段代码在下载几十上百MB的文件时内存占用基本是稳定在几MB以内性能上完全够用。3. 断言体系与数据驱动设计3.1 断言不是只查状态码抽象出公共校验器我见过太多接口自动化用例断言就写一个status_code 200然后就算通过。这种断言基本等于摆设。一个登录接口返回200但业务数据里可能写着“密码错误”一个订单查询接口返回200但订单列表可能是个空数组。HTTP状态码只代表“请求被服务器正常接收并处理了”完全不代表“业务逻辑正确”。所以断言必须分层第一层校验HTTP状态码第二层校验业务状态码很多企业级接口会在响应体里再包一层code字段比如code0表示成功code1表示业务异常第三层校验关键业务字段的具体值。为了方便维护我会把断言封装成一个公共校验器类所有用例调用它来校验而不是各写各的。class ResponseChecker: staticmethod def assert_status(resp, expected_code200): assert resp.status_code expected_code, \ fHTTP状态码异常期望{expected_code}实际{resp.status_code}响应内容{resp.text[:500]} staticmethod def assert_business_code(data, expected_code0): actual_code data.get(code) assert actual_code expected_code, \ f业务状态码异常期望{expected_code}实际{actual_code}错误信息{data.get(message)} staticmethod def assert_field(data, field_path, expected_value): # field_path 支持点号路径例如 data.order.id keys field_path.split(.) node data for key in keys: if not isinstance(node, dict) or key not in node: raise AssertionError(f字段路径{field_path}不存在当前节点{node}) node node[key] assert node expected_value, \ f字段{field_path}断言失败期望{expected_value}实际{node}把断言抽象出来有两大好处一是格式统一出错信息好看能直接定位到具体哪个字段出了问题二是后续想增加断言类型比如校验字段类型、校验数组长度、校验正则匹配只需要在这个类里加方法所有用例自动获得新能力不用回头改历史用例。3.2 用例数据与代码分离用YAML管测试数据当你有100个用例时如果每个用例都是写死的Python函数维护成本会高得离谱。接口参数稍微调整一下你得翻遍代码改几十处。所以我强烈建议把用例数据从代码里抽出来放到YAML、JSON或者Excel里Python代码只负责读取数据、执行请求、调用断言。我比较偏好YAML原因很简单它支持注释层级结构清晰比JSON少了那些繁琐的引号和括号。下面是一个典型的用例文件结构- name: 正常登录 request: method: POST url: /api/login json: username: admin password: 123456 expect: status_code: 200 code: 0 data: token_type: Bearer - name: 密码错误登录 request: method: POST url: /api/login json: username: admin password: wrong expect: status_code: 200 code: 10001 message: 用户名或密码错误这里的url我会写成相对路径base_url统一在配置里维护这样测试环境切换时只需要改一个变量不用动所有用例。加载YAML的代码也很简单import yaml def load_cases(file_path): with open(file_path, r, encodingutf-8) as f: return yaml.safe_load(f)yaml.safe_load解析出来的就是一个列表每个元素是一个dict直接交给通用请求执行器去跑。执行器读取request字段判断method是GET还是POST以及有没有data、json、params、headers这些子字段然后动态拼参数调用requests响应再用expect字段中的期望值去断言。整套逻辑对数据是零依赖的新增用例只改文件不碰代码。这种数据驱动的方式对测试同学非常友好即使不太懂Python的人只要会按模板填YAML也能参与写用例。3.3 环境配置分离dev、test、prod一键切换接口自动化项目最怕硬编码URL。今天在Dev环境调的接口明天要跑Test环境的回归你发现代码里写死了“https://dev-api.example.com”只能手动全局替换改完还可能漏。正确做法是环境配置单独存文件代码在运行时加载。我喜欢用config.yaml管理环境配置dev: base_url: https://dev-api.example.com username: dev_tester password: dev123 test: base_url: https://test-api.example.com username: test_tester password: test123代码里维护一个配置加载模块用一个全局变量记住当前选中的环境。怎么选环境我用最简单粗暴的方式读环境变量环境变量没有就用默认值。import os import yaml with open(config.yaml, r, encodingutf-8) as f: CONFIG yaml.safe_load(f) ENV os.getenv(TEST_ENV, test) CURRENT_CONFIG CONFIG[ENV] BASE_URL CURRENT_CONFIG[base_url]这样你在命令行跑测试的时候加一个TEST_ENVdev参数就能切换环境CI里不同的流水线也可以设不同的环境变量代码一行不用改。4. 组装框架pytest集成、报告输出、CI落地4.1 为什么测试执行器用pytestrequests解决的是“单个接口怎么请求”的问题但自动化测试项目和普通脚本最大的区别在于你需要一套机制来收集用例、执行用例、统计通过率、输出报告、支持前置后置处理。这些能力requests本身不提供需要测试框架来补充。Python生态里pytest是绕不开的选择。pytest的优势有几个非常契合接口测试的点第一用例收集规则简单py文件名以test_开头、函数名以test_开头就能被自动发现第二自带断言机制直接用Python原生的assert就可以不像unittest那样强制用self.assertEqual写起来少一层包装第三fixture机制非常好用可以搞定登录前置、数据库清理、环境准备这类依赖第四插件生态成熟报告、重试、耗时统计、多进程执行都有现成的轮子。如果要用unittest也不说不行但你在参数化、fixture、失败重跑这些高级机制上都会明显感觉pytest更顺滑。尤其是pytest.mark.parametrize做数据驱动比unittest的ddt库不知道好用多少倍。4.2 fixture实现登录前置session级别只登一次接口测试里70%的用例都依赖登录态。如果用普通条件每个用例都先调一次登录接口跑一百个用例就要登录一百次白白增加执行时间而且有的服务端会对高频登录做风控限制。pytest的fixture作用域可以有效解决这个问题。我在conftest.py里定义一个session级别的fixture让整个测试过程中只登录一次后续所有用例共享这个登录态。conftest.py是pytest的特殊文件pytest会自动加载它里面定义的fixture你不需要显式import它在用例函数里直接写参数名就能用。import pytest import requests pytest.fixture(scopesession) def api_session(): session requests.Session() # 先拿token resp session.post( f{BASE_URL}/api/login, json{username: CURRENT_CONFIG[username], password: CURRENT_CONFIG[password]}, timeout10 ) data resp.json() assert data.get(code) 0, f登录失败{data} token data[data][token] session.headers.update({Authorization: fBearer {token}}) return session这里scopesession很关键它告诉pytest这个fixture在整个测试session里只初始化一次返回的session对象会被所有用例共享。如果写成默认的function作用域每个用例都会重新登录一次性能差别很大。测试用例里只需要在参数列表里加上api_session就能拿到登录后的session然后直接用def test_get_order_info(api_session): resp api_session.get(f{BASE_URL}/api/order/1001, timeout10) ResponseChecker.assert_status(resp, 200) ResponseChecker.assert_business_code(resp.json(), 0) ResponseChecker.assert_field(resp.json(), data.order.status, PAID)看起来非常清爽用例函数里几乎没有跟登录相关的代码只关注自己真正要验证的业务点。4.3 从YAML用例到pytest参数化执行前面我讲了用YAML管理用例数据那怎么让pytest把每个YAML里的用例转成一条条测试用例呢答案就是parametrize。import pytest from utils import load_cases, execute_case CASES load_cases(cases/login_cases.yaml) pytest.mark.parametrize(case, CASES, ids[c[name] for c in CASES]) def test_login_cases(case, api_session): execute_case(api_session, case)执行器execute_case的逻辑在前面的章节已经讲过读取case里的request字段组装参数发请求然后用expect字段做断言。这样做的好处是你在YAML里每加一条用例pytest自动生成一条新的测试记录用ids参数把用例的中文名称显示在报告里失败的时候一眼就能看到是哪条业务规则出了问题。这里要注意一个细节parametrize里的ids要和用例列表长度一致如果不传pytest默认显示case编号可读性会差很多。传了ids之后报告里显示的测试ID就是YAML里你写的用例名称比如“正常登录”、“密码错误登录”排错效率直接翻倍。4.4 报告输出、失败重跑与告警通知测试跑完没有报告等于白跑。pytest生态里最常用的报告插件是pytest-html它会生成一个独立的HTML文件包含每个用例的执行状态、耗时、错误信息可以直接扔给团队其他成员看也可以归档供后续追溯。安装和使用的命令如下pip install pytest-html pytest -v --htmlreport.html --self-contained-html--self-contained-html的意思是报告要用到CSS和JS样式都内嵌到一个HTML文件里方便直接分发不会出现打开报告缺失样式的情况。接口测试还有一个痛点偶发性的网络抖动导致请求失败用例本身逻辑没问题白白红了一片。这种时候引入pytest-rerunfailures插件给用例设置重试策略可以显著降低假失败率。pip install pytest-rerunfailures pytest --reruns 2 --reruns-delay 2这个命令的意思是失败用例自动重跑2次每次间隔2秒。如果重跑后通过了报告里会标记为RERUN不算是失败失败连续3次都失败才算真正失败。要注意区分重试机制解决的是“环境抖动”问题如果你的断言逻辑本身有bug重试一百次也一样失败。所以定位问题的时候首先查的是业务逻辑而不是重试配置。更进一步的告警通知我一般写一个conftest里的pytest_terminal_summary钩子在测试结束后汇总结果并调用企业微信机器人或者飞书机器人的Webhook发送消息。代码不复杂核心就两步从test_report对象里读统计数据然后requests.post到Webhook地址。def pytest_terminal_summary(terminalreporter, exitstatus, config): passed terminalreporter.stats.get(passed, []) failed terminalreporter.stats.get(failed, []) rerun terminalreporter.stats.get(rerun, []) total len(passed) len(failed) len(rerun) text f接口自动化执行完成总用例{total}通过{len(passed)}失败{len(failed)}重跑通过{len(rerun)} requests.post(WEBHOOK_URL, json{msgtype: text, text: {content: text}}, timeout5)团队里大家不用天天蹲在Jenkins上看结果消息推送主动把结论摆到每个人面前。谁改的代码导致接口挂了EMBA群里直接点名比什么都好使。4.5 接入CI在Jenkins/GitLab CI里定时跑接口回归本地能跑通只是第一步真正让接口自动化发挥价值的是把它接入持续集成。最简单的用法是搞一台定时任务机器在Jenkins里新建一个Pipeline任务构建脚本大概就是拉代码、装依赖、跑测试、归档报告这几步python -m venv venv source venv/bin/activate pip install -r requirements.txt pytest -v --htmlreport.html --self-contained-htmlCI服务器上要提前装好Python环境每次构建从Git仓库拉最新代码然后跑全量回归。执行结果和报告作为构建产物归档失败了构建就被标记为失败相关负责人会收到通知。这整个流程跑通之后团队每个人提交代码前都会主动看一眼接口回归结果很多联调阶段才能发现的接口问题在提交阶段就被拦截了。GitLab CI的配置思路一样在仓库根目录放一个.gitlab-ci.yml文件里面定义test阶段的任务用官方python镜像运行同样的命令。关键点是恢复环境时记得把缓存和镜像加速配置好不然每次构建光装依赖就要好几分钟。5. 常见问题与排错技巧实录5.1 超时与重试机制从Timeout异常到429限流接口自动化跑起来之后你遇到的最常见的异常大概率是requests.exceptions.ConnectTimeout或者ReadTimeout。前者是TCP连接建立阶段超时后者是服务器接受连接后迟迟不给响应。解决超时问题的第一道关口就是我在前面强调过的每个请求显式传timeout。但光设timeout还不够网络环境复杂时一个正常的接口偶尔也会因为瞬时拥塞导致超时。这时候需要引入重试机制。最稳妥的方案是用urllib3的Retry对象配合requests的HTTPAdapterfrom requests.adapters import HTTPAdapter from urllib3.util.retry import Retry session requests.Session() retry Retry( total3, connect3, read3, backoff_factor1, status_forcelist[500, 502, 503, 504], allowed_methods[GET, POST, PUT, DELETE] ) adapter HTTPAdapter(max_retriesretry) session.mount(http://, adapter) session.mount(https://, adapter)Retry里的backoff_factor是重试退避时间公式是{backoff_factor} * (2 ** retry_num)第一次重试等待1秒第二次2秒第三次4秒。这个递增的等待策略很重要如果三次重试都立即发出等于给已经拥堵的服务器再补三刀反而更容易引发雪崩。我还遇到过一种特有意思的情况日志里出现“exceeded retry limit, last status: 429 too many requests”。429是HTTP的状态码意思是请求发得太频繁被服务端限流了。这种一般不是你代码出错而是你跑的用例量太大、频率太高触发了网关或者业务方的频控策略。解决思路有几种一是把并发调整成串行二是调用之间加个短暂延时三是联系服务端同学确认限流阈值在阈值范围内设定测试节奏。如果是接入第三方开放平台的接口对方限流很严就要在测试数据里严格控制调用总量必要时跑低峰时段。5.2 证书校验失败的两种应对方案自签名HTTPS证书是测试环境的老大难。requests在默认情况下会校验证书链而内网环境的证书往往是自签的没有权威CA签名于是请求直接抛SSLError。这时候最简单的方法就是全局关掉校验并屏蔽警告import requests import urllib3 urllib3.disable_warnings(urllib3.exceptions.InsecureRequestWarning) resp requests.get(url, verifyFalse, timeout10)但是“能跑通”和“安全地跑通”是两码事。如果你只是对内网测试环境临时关校验问题不大如果你长期关掉校验跑生产环境的接口那就要小心了——中间人攻击的风险真实存在你无法确认响应数据是不是被篡改过。更稳妥的替代方案是把测试环境的证书下载下来在代码里通过verify参数指定证书文件路径resp requests.get(url, verify/path/to/test_env_cert.pem, timeout10)这种方式既不会对真实证书链路做妥协又能绕过自签名报错。注意证书文件路径不要硬编码在代码里放到配置项里跟环境切换走同一套机制。5.3 中文乱码与响应编码判断接口返回里带中文是常态但有时候你会发现resp.text打印出来是一堆乱码比如\u5f00\u59cb或者类似于“ç”开头的怪字符。原因在于requests对响应体的编码判断不够智能。HTTP响应头通常会带Content-Type里的charset字段requests优先使用这个编码来解码但如果服务端没在响应头里声明charsetrequests会fallback到ISO-8859-1不认UTF-8的中文字符。解决方法是主动让requests去猜测编码resp requests.get(url, timeout10) if resp.encoding is None or resp.encoding.lower() iso-8859-1: resp.encoding resp.apparent_encoding data resp.textapparent_encoding是requests基于响应内容字节流分析出来的编码对中文网页/接口的识别准确率很高。我一般会在所有请求封装的通用入口里加上这段逻辑保证下游解析resp.text时拿到的都是正确解码后的内容。另外要提醒一点resp.text和resp.content要分清楚。text是对content按编码解码后的字符串content是原始字节流。有时候你要做sign签名校验必须用content拿原始字节去算用text转来转去反而容易出偏差。5.4 接口依赖与前后置数据处理动态参数怎么取接口之间普遍存在依赖关系。最典型的是A接口返回一个idB接口要用这个id去查详情。你不能手动把这个id硬编码到用例里因为每次测试数据可能都不一样。这时候就需要在用例执行过程中动态提取中间参数。我的做法是在YAML用例格式里增加一个extract字段支持从响应里提取数据保存到上下文环境后续用例再从上下文取值拼到请求里。用例数据长这样- name: 创建订单 request: method: POST url: /api/order/create json: product_id: 1001 extract: order_id: data.order_id expect: status_code: 200 code: 0 - name: 查询新建订单 request: method: GET url: /api/order/{order_id} expect: status_code: 200 code: 0执行器的逻辑就变成了两步发送请求后先看有没有extract字段有就从响应体里按点号路径取值存进一个全局上下文dict构造请求前把URL里的{variable}和json里的{variable}替换成当前上下文里对应的值。这个机制解决了接口自动化里最核心的用例关联问题也让用例文件在维护时看起来非常直观。实现思路不复杂核心代码就是把字符串里的占位符做一次格式化替换。依赖顺序执行还有一个容易被忽略的问题如果创建订单的前置用例失败了后续依赖它的用例全都会失败。所以我在报告里会特别关注依赖链最开头的用例一旦它挂了后面红一片很可能只是连锁反应不一定是这些用例本身的逻辑问题。排查时要顺着依赖链从前往后看而不是盯着最后一条失败用例猜原因。最后分享几个小经验这套框架我从最开始的几十行脚本一路演进到现在接近上千条用例最大的体会就是接口自动化最怕的不是requests用不熟而是架构一开始就没想清楚导致后面每加一个用例都要改代码。所以强烈建议你把用例数据、请求封装、断言逻辑、执行调度这四层拆开哪怕前期会多写一点代码后续的维护成本会指数级下降。还有一个小建议新项目不要一上来就追求“框架化”。先拿requests把几个核心接口的自动化脚本写出来跑通一个完整的业务链路验证这个方向在你的项目里确实能落地然后再逐步引入数据驱动、pytest、CI这些偏工程化的能力。大多数接口自动化项目死掉不是技术问题而是因为搭建和学习成本太高团队根本维护不起来。先跑起来再慢慢变重是我踩过很多坑之后最想提醒你的一件事。
如果你每天的工作里有大半时间是在Postman里把接口挨个点一遍复制响应结果去对字段再切到Excel里记一笔那我接下来说的这套东西应该能帮你从这种重复劳动里解放出来。用Python加requests写接口自动化测试并不是什么高深的技术但它能解决的问题非常具体让机器替你反复验证接口的返回值、状态码、业务逻辑是否符合预期把回归测试的时间从几个小时压缩到几分钟而且每次跑完都有清晰的结果记录可以追溯。这篇文章我会从方案选型开始讲为什么大家都选requests而不是Java或者Postman脚本然后一步步拆解requests请求对象、会话保持、断言体系、数据驱动再到用pytest把散落的脚本串成一套能跑、能出报告、能接入CI的框架最后把我这些年踩过的坑整理成一份排查清单。适合两种人看一种是有Python基础但没系统写过接口自动化的测试同学另一种是手工测试想转自动化、但对框架设计没什么概念的工程师。看完你至少能独立搭出一个可复用的接口测试项目而不是停留在“会用requests发个get请求”的层面。1. 方案设计为什么选requests而不是“全家桶”1.1 接口自动化到底在测什么很多新手会把接口自动化和UI自动化搞混觉得都是在页面上点点点。但实际上接口自动化测的是客户端与服务端的“通信协议”也就是HTTP请求和响应本身。你要验证的是请求参数传对了没有、鉴权信息带上没有、服务端返回的状态码对不对、关键字段的值是否符合预期、异常参数下服务端是否做了正确的拦截。这些校验点全部发生在“页面渲染之前”所以根本不需要浏览器一个能发HTTP请求的库就够了。用requests做这件事核心优势是它把HTTP协议里那些繁琐的底层细节封装得恰到好处。你不用手动拼接请求行、自己处理TCP连接只需要调用get、post、put这些方法传入url、参数、headersrequests就会帮你把请求发出去把响应解析成一个response对象。这个对象的status_code、text、json()方法覆盖了接口测试90%以上的断言需求”。相比你去解析原始报文再自己写校验逻辑节省的精力是肉眼可见的。1.2 市面上那么多工具为什么单选requests我见过不少团队在接口自动化选型时纠结Postman有Collection和Runner跑起来也能看报告JMeter能做压测顺便测接口Java那边有HttpClient和RestAssuredPython这边除了requests还有httpx。每个工具都有它的适用场景但如果你要的是一个“轻量、易维护、能和现有代码/CI深度整合”的方案requests几乎是目前综合成本最低的。拿Postman来说单次调试接口它确实方便可视化交互对新手很友好。但Postman脚本的断言语言偏向于“配置式”复杂逻辑写起来很别扭而且用例一多Collection的管理、环境变量的传递就容易乱成一团。PostmanNewman也能跑自动化可你很难在脚本里集成复杂的业务逻辑比如加解密、数据库校验、调用别的服务获取动态参数。一旦测试场景复杂起来它的天花板就很明显。JMeter的优势在于压测能力它做接口功能测试也可以但录制和维护jmx文件对测试人员的门槛比写Python脚本高得多。团队里随便一个新人都能用requests读一遍代码看懂逻辑但换到JMeter就得学习它的组件模型、监听器、配置元件那一整套东西。至于JavaHttpClient如果你团队本身就是Java技术栈、又需要跟Spring生态深度整合比如直接连公司的注册中心拿服务地址那选Java没问题但单纯为了接口自动化去维护一个Java工程编译、打包、依赖管理的成本会比Python高一个量级。所以我给团队定的方案一直很明确日常接口功能回归用Pythonrequests压测单独上JMeter或后续引入专业压测工具两者职责分开不需要一个东西扛所有任务。1.3 一个最小可用框架的构成当你只写一两个接口的验证脚本时requests直接能上但当你手上有几十上百个接口用例时必须考虑结构化。我推荐的最小框架包含四层用例管理层、请求发送层、断言校验层、报告执行层。用例管理层用YAML、JSON或Excel管理测试数据把“请求参数”和“预期结果”从代码里抽出来请求发送层封装统一的requests调用入口处理超时、重试、日志记录断言校验层抽象出公共的校验器统一处理状态码、字段值、业务码等断言报告执行层用pytest收集用例、执行并生成报告再配合定时任务或CI触发。这四层各自独立改用例不用动代码改请求封装不影响用例数据新增断言方式也不影响其他两层。后面我写的每一节基本都是围绕把这四层逐步搭出来的过程展开的。2. 环境搭建与requests核心用法2.1 开发环境准备Python、虚拟环境、pip安装如果你机器上还没装Python去官网下载对应操作系统的安装包即可装的时候记得勾选“Add Python to PATH”这个选项不然后续在命令行里敲python会提示找不到命令。建议直接用Python 3.8以上的版本我目前项目里用的3.10和3.11都很稳定requests对版本要求不苛刻只要不是太老的Python 2系就行Python 2官方都停止维护了新项目别碰。装完Python之后第一件事是建一个虚拟环境。这个步骤在你只有一个项目的时候看起来多余但当你同时维护多个项目、每个项目依赖的包版本还不一样时虚拟环境能救你的命。命令行里执行python -m venv venvWindows下激活命令是venv\Scripts\activateLinux/Mac是source venv/bin/activate。激活后命令行前面会出现一个(venv)前缀之后你安装的包都会进这个独立的虚拟环境不会污染全局。然后安装requests直接执行pip install requests有些人会遇到输出一段提示大意是“defaulting to user installation because normal site-packages is not writeable”这个不算报错意思是当前Python环境没有写权限所以pip把包装到了当前用户目录下。它能用但容易造成不同项目之间包混乱实际上反而说明你没用虚拟环境或者当前环境的site-packages权限有问题。建议先确认一下自己是不是在venv里如果在venv里还出现这个提示检查下虚拟环境有没有正确激活。装完之后验证一下版本python -c import requests; print(requests.__version__)能打出类似2.31.0这样的版本号环境就算通了。2.2 最常用的几个请求写法get、post与关键参数requests最迷人的地方就在于常用的请求真的只需要几行代码。比如一个最简单的get请求import requests resp requests.get( https://api.example.com/api/order/1001, headers{Authorization: Bearer xxxxx}, timeout10, verifyFalse ) print(resp.status_code) print(resp.text)这里面我想重点讲两个参数很多人会忽略但实际非常重要timeout和verify。timeout是请求超时时间单位是秒。如果你不设置它requests理论上会一直等下去直到TCP层自己超时这在自动化测试里是件很恐怖的事——一个接口挂了测试脚本可能卡在那里十几分钟不报错整个测试套件被拖死。所以我在代码里强制要求所有请求必须显式传timeout一般连通性测试给10秒涉及上传下载的大报文给30秒到60秒。verify是SSL证书校验开关默认是True也就是requests会校验HTTPS证书的合法性。如果你测试环境用的是自签名证书或者内网环境的证书链不完整requests会直接抛requests.exceptions.SSLError。遇到这种情况临时把verifyFalse关掉校验是一种常见做法但我建议你在关掉的同时加上urllib3的警告屏蔽不然每次请求控制台都会刷黄色的InsecureRequestWarning警告很干扰日志排错。后面排错章节我会专门贴这段代码。post请求传参有两种主流姿势data和json。很多新手特别容易搞混data传的是表单编码格式也就是application/x-www-form-urlencoded相当于你在网页上提交表单时浏览器发的那种bodyjson传的是JSON字符串Content-Type自动变成application/json。接口的Content-Type要求哪种你就用哪种参数不是想用哪个用哪个。如果接口定义的是JSON格式你用data传会让后端解析不到参数返回参数缺失之类的错误。# 表单格式 resp requests.post( https://api.example.com/api/login, data{username: admin, password: 123456}, timeout10 ) # JSON格式 resp requests.post( https://api.example.com/api/login, json{username: admin, password: 123456}, timeout10 )2.3 session会话保持登录态的正确管理方式接口测试里绕不开的一个问题是登录态管理。大多数业务接口都需要你先登录拿到token或cookie后续请求再带上这个凭证去访问。很多人第一次写自动化时是这么干的调登录接口从响应里解析token然后复制到下面每个请求的headers里。这样能跑但极其脆弱——token一旦过期你就要手动去改脚本而且一个个请求复制粘贴代码可维护性为零。正确做法是用requests的Session对象。Session可以理解成你和服务器之间的一条“持久连接通道”它会自动帮你保存服务端下发的cookie并且在同一个session实例发出的后续请求里自动带上这些cookie。你只需要做一次登录之后所有用session发的请求都会共享登录态。我举个例子模拟一个电商系统的登录和查询订单流程import requests session requests.Session() # 第一步登录 login_resp session.post( https://api.example.com/api/login, json{username: admin, password: 123456}, timeout10 ) print(登录响应:, login_resp.json()) # 第二步查询订单cookie/登录态自动携带 order_resp session.get( https://api.example.com/api/order/1001, timeout10 ) print(订单结果:, order_resp.json())对于前后端分离的项目登录后返回的不是cookie而是token那Session的cookie自动携带机制就派不上用场了。这种情况可以封装一个请求工具类在构造请求时自动把token塞进headers。我一般用一个模块级的全局变量保存token登录接口成功后在内存里更新它其他地方发起请求时统一从这个地方取。TOKEN def set_token(token): global TOKEN TOKEN token def auth_headers(): return {Authorization: fBearer {TOKEN}} if TOKEN else {}还有一种更稳妥的做法是把token持久化到文件或配置中心程序启动时先加载发现失效再重新登录获取。这样即使测试进程重启token还在能少一次登录请求。不过token的安全性要注意不要硬编码进代码仓库尤其是会推送到远端仓库的项目。2.4 文件上传下载与二进制流处理接口自动化不只测JSON接口文件上传和下载也是常见场景。上传接口一般用files参数传一个字典key是表单字段名value是文件对象。要注意的是如果你既传files又传datarequests会把它们组合成multipart/form-data格式发送。with open(test_report.pdf, rb) as f: resp requests.post( https://api.example.com/api/upload, files{file: (test_report.pdf, f, application/pdf)}, data{description: 月度测试报告}, timeout30 )下载接口则要关注stream参数。如果你直接resp.contentrequests会把整个响应体加载到内存里大文件容易把内存打爆。正确做法是设置streamTrue然后分块写入磁盘resp requests.get( https://api.example.com/api/download/20240101_report, streamTrue, timeout30 ) with open(report.zip, wb) as f: for chunk in resp.iter_content(chunk_size8192): if chunk: f.write(chunk)这里iter_content是按固定字节流式读取加上chunk的判断防止有些响应没有实际数据时写空块。这段代码在下载几十上百MB的文件时内存占用基本是稳定在几MB以内性能上完全够用。3. 断言体系与数据驱动设计3.1 断言不是只查状态码抽象出公共校验器我见过太多接口自动化用例断言就写一个status_code 200然后就算通过。这种断言基本等于摆设。一个登录接口返回200但业务数据里可能写着“密码错误”一个订单查询接口返回200但订单列表可能是个空数组。HTTP状态码只代表“请求被服务器正常接收并处理了”完全不代表“业务逻辑正确”。所以断言必须分层第一层校验HTTP状态码第二层校验业务状态码很多企业级接口会在响应体里再包一层code字段比如code0表示成功code1表示业务异常第三层校验关键业务字段的具体值。为了方便维护我会把断言封装成一个公共校验器类所有用例调用它来校验而不是各写各的。class ResponseChecker: staticmethod def assert_status(resp, expected_code200): assert resp.status_code expected_code, \ fHTTP状态码异常期望{expected_code}实际{resp.status_code}响应内容{resp.text[:500]} staticmethod def assert_business_code(data, expected_code0): actual_code data.get(code) assert actual_code expected_code, \ f业务状态码异常期望{expected_code}实际{actual_code}错误信息{data.get(message)} staticmethod def assert_field(data, field_path, expected_value): # field_path 支持点号路径例如 data.order.id keys field_path.split(.) node data for key in keys: if not isinstance(node, dict) or key not in node: raise AssertionError(f字段路径{field_path}不存在当前节点{node}) node node[key] assert node expected_value, \ f字段{field_path}断言失败期望{expected_value}实际{node}把断言抽象出来有两大好处一是格式统一出错信息好看能直接定位到具体哪个字段出了问题二是后续想增加断言类型比如校验字段类型、校验数组长度、校验正则匹配只需要在这个类里加方法所有用例自动获得新能力不用回头改历史用例。3.2 用例数据与代码分离用YAML管测试数据当你有100个用例时如果每个用例都是写死的Python函数维护成本会高得离谱。接口参数稍微调整一下你得翻遍代码改几十处。所以我强烈建议把用例数据从代码里抽出来放到YAML、JSON或者Excel里Python代码只负责读取数据、执行请求、调用断言。我比较偏好YAML原因很简单它支持注释层级结构清晰比JSON少了那些繁琐的引号和括号。下面是一个典型的用例文件结构- name: 正常登录 request: method: POST url: /api/login json: username: admin password: 123456 expect: status_code: 200 code: 0 data: token_type: Bearer - name: 密码错误登录 request: method: POST url: /api/login json: username: admin password: wrong expect: status_code: 200 code: 10001 message: 用户名或密码错误这里的url我会写成相对路径base_url统一在配置里维护这样测试环境切换时只需要改一个变量不用动所有用例。加载YAML的代码也很简单import yaml def load_cases(file_path): with open(file_path, r, encodingutf-8) as f: return yaml.safe_load(f)yaml.safe_load解析出来的就是一个列表每个元素是一个dict直接交给通用请求执行器去跑。执行器读取request字段判断method是GET还是POST以及有没有data、json、params、headers这些子字段然后动态拼参数调用requests响应再用expect字段中的期望值去断言。整套逻辑对数据是零依赖的新增用例只改文件不碰代码。这种数据驱动的方式对测试同学非常友好即使不太懂Python的人只要会按模板填YAML也能参与写用例。3.3 环境配置分离dev、test、prod一键切换接口自动化项目最怕硬编码URL。今天在Dev环境调的接口明天要跑Test环境的回归你发现代码里写死了“https://dev-api.example.com”只能手动全局替换改完还可能漏。正确做法是环境配置单独存文件代码在运行时加载。我喜欢用config.yaml管理环境配置dev: base_url: https://dev-api.example.com username: dev_tester password: dev123 test: base_url: https://test-api.example.com username: test_tester password: test123代码里维护一个配置加载模块用一个全局变量记住当前选中的环境。怎么选环境我用最简单粗暴的方式读环境变量环境变量没有就用默认值。import os import yaml with open(config.yaml, r, encodingutf-8) as f: CONFIG yaml.safe_load(f) ENV os.getenv(TEST_ENV, test) CURRENT_CONFIG CONFIG[ENV] BASE_URL CURRENT_CONFIG[base_url]这样你在命令行跑测试的时候加一个TEST_ENVdev参数就能切换环境CI里不同的流水线也可以设不同的环境变量代码一行不用改。4. 组装框架pytest集成、报告输出、CI落地4.1 为什么测试执行器用pytestrequests解决的是“单个接口怎么请求”的问题但自动化测试项目和普通脚本最大的区别在于你需要一套机制来收集用例、执行用例、统计通过率、输出报告、支持前置后置处理。这些能力requests本身不提供需要测试框架来补充。Python生态里pytest是绕不开的选择。pytest的优势有几个非常契合接口测试的点第一用例收集规则简单py文件名以test_开头、函数名以test_开头就能被自动发现第二自带断言机制直接用Python原生的assert就可以不像unittest那样强制用self.assertEqual写起来少一层包装第三fixture机制非常好用可以搞定登录前置、数据库清理、环境准备这类依赖第四插件生态成熟报告、重试、耗时统计、多进程执行都有现成的轮子。如果要用unittest也不说不行但你在参数化、fixture、失败重跑这些高级机制上都会明显感觉pytest更顺滑。尤其是pytest.mark.parametrize做数据驱动比unittest的ddt库不知道好用多少倍。4.2 fixture实现登录前置session级别只登一次接口测试里70%的用例都依赖登录态。如果用普通条件每个用例都先调一次登录接口跑一百个用例就要登录一百次白白增加执行时间而且有的服务端会对高频登录做风控限制。pytest的fixture作用域可以有效解决这个问题。我在conftest.py里定义一个session级别的fixture让整个测试过程中只登录一次后续所有用例共享这个登录态。conftest.py是pytest的特殊文件pytest会自动加载它里面定义的fixture你不需要显式import它在用例函数里直接写参数名就能用。import pytest import requests pytest.fixture(scopesession) def api_session(): session requests.Session() # 先拿token resp session.post( f{BASE_URL}/api/login, json{username: CURRENT_CONFIG[username], password: CURRENT_CONFIG[password]}, timeout10 ) data resp.json() assert data.get(code) 0, f登录失败{data} token data[data][token] session.headers.update({Authorization: fBearer {token}}) return session这里scopesession很关键它告诉pytest这个fixture在整个测试session里只初始化一次返回的session对象会被所有用例共享。如果写成默认的function作用域每个用例都会重新登录一次性能差别很大。测试用例里只需要在参数列表里加上api_session就能拿到登录后的session然后直接用def test_get_order_info(api_session): resp api_session.get(f{BASE_URL}/api/order/1001, timeout10) ResponseChecker.assert_status(resp, 200) ResponseChecker.assert_business_code(resp.json(), 0) ResponseChecker.assert_field(resp.json(), data.order.status, PAID)看起来非常清爽用例函数里几乎没有跟登录相关的代码只关注自己真正要验证的业务点。4.3 从YAML用例到pytest参数化执行前面我讲了用YAML管理用例数据那怎么让pytest把每个YAML里的用例转成一条条测试用例呢答案就是parametrize。import pytest from utils import load_cases, execute_case CASES load_cases(cases/login_cases.yaml) pytest.mark.parametrize(case, CASES, ids[c[name] for c in CASES]) def test_login_cases(case, api_session): execute_case(api_session, case)执行器execute_case的逻辑在前面的章节已经讲过读取case里的request字段组装参数发请求然后用expect字段做断言。这样做的好处是你在YAML里每加一条用例pytest自动生成一条新的测试记录用ids参数把用例的中文名称显示在报告里失败的时候一眼就能看到是哪条业务规则出了问题。这里要注意一个细节parametrize里的ids要和用例列表长度一致如果不传pytest默认显示case编号可读性会差很多。传了ids之后报告里显示的测试ID就是YAML里你写的用例名称比如“正常登录”、“密码错误登录”排错效率直接翻倍。4.4 报告输出、失败重跑与告警通知测试跑完没有报告等于白跑。pytest生态里最常用的报告插件是pytest-html它会生成一个独立的HTML文件包含每个用例的执行状态、耗时、错误信息可以直接扔给团队其他成员看也可以归档供后续追溯。安装和使用的命令如下pip install pytest-html pytest -v --htmlreport.html --self-contained-html--self-contained-html的意思是报告要用到CSS和JS样式都内嵌到一个HTML文件里方便直接分发不会出现打开报告缺失样式的情况。接口测试还有一个痛点偶发性的网络抖动导致请求失败用例本身逻辑没问题白白红了一片。这种时候引入pytest-rerunfailures插件给用例设置重试策略可以显著降低假失败率。pip install pytest-rerunfailures pytest --reruns 2 --reruns-delay 2这个命令的意思是失败用例自动重跑2次每次间隔2秒。如果重跑后通过了报告里会标记为RERUN不算是失败失败连续3次都失败才算真正失败。要注意区分重试机制解决的是“环境抖动”问题如果你的断言逻辑本身有bug重试一百次也一样失败。所以定位问题的时候首先查的是业务逻辑而不是重试配置。更进一步的告警通知我一般写一个conftest里的pytest_terminal_summary钩子在测试结束后汇总结果并调用企业微信机器人或者飞书机器人的Webhook发送消息。代码不复杂核心就两步从test_report对象里读统计数据然后requests.post到Webhook地址。def pytest_terminal_summary(terminalreporter, exitstatus, config): passed terminalreporter.stats.get(passed, []) failed terminalreporter.stats.get(failed, []) rerun terminalreporter.stats.get(rerun, []) total len(passed) len(failed) len(rerun) text f接口自动化执行完成总用例{total}通过{len(passed)}失败{len(failed)}重跑通过{len(rerun)} requests.post(WEBHOOK_URL, json{msgtype: text, text: {content: text}}, timeout5)团队里大家不用天天蹲在Jenkins上看结果消息推送主动把结论摆到每个人面前。谁改的代码导致接口挂了EMBA群里直接点名比什么都好使。4.5 接入CI在Jenkins/GitLab CI里定时跑接口回归本地能跑通只是第一步真正让接口自动化发挥价值的是把它接入持续集成。最简单的用法是搞一台定时任务机器在Jenkins里新建一个Pipeline任务构建脚本大概就是拉代码、装依赖、跑测试、归档报告这几步python -m venv venv source venv/bin/activate pip install -r requirements.txt pytest -v --htmlreport.html --self-contained-htmlCI服务器上要提前装好Python环境每次构建从Git仓库拉最新代码然后跑全量回归。执行结果和报告作为构建产物归档失败了构建就被标记为失败相关负责人会收到通知。这整个流程跑通之后团队每个人提交代码前都会主动看一眼接口回归结果很多联调阶段才能发现的接口问题在提交阶段就被拦截了。GitLab CI的配置思路一样在仓库根目录放一个.gitlab-ci.yml文件里面定义test阶段的任务用官方python镜像运行同样的命令。关键点是恢复环境时记得把缓存和镜像加速配置好不然每次构建光装依赖就要好几分钟。5. 常见问题与排错技巧实录5.1 超时与重试机制从Timeout异常到429限流接口自动化跑起来之后你遇到的最常见的异常大概率是requests.exceptions.ConnectTimeout或者ReadTimeout。前者是TCP连接建立阶段超时后者是服务器接受连接后迟迟不给响应。解决超时问题的第一道关口就是我在前面强调过的每个请求显式传timeout。但光设timeout还不够网络环境复杂时一个正常的接口偶尔也会因为瞬时拥塞导致超时。这时候需要引入重试机制。最稳妥的方案是用urllib3的Retry对象配合requests的HTTPAdapterfrom requests.adapters import HTTPAdapter from urllib3.util.retry import Retry session requests.Session() retry Retry( total3, connect3, read3, backoff_factor1, status_forcelist[500, 502, 503, 504], allowed_methods[GET, POST, PUT, DELETE] ) adapter HTTPAdapter(max_retriesretry) session.mount(http://, adapter) session.mount(https://, adapter)Retry里的backoff_factor是重试退避时间公式是{backoff_factor} * (2 ** retry_num)第一次重试等待1秒第二次2秒第三次4秒。这个递增的等待策略很重要如果三次重试都立即发出等于给已经拥堵的服务器再补三刀反而更容易引发雪崩。我还遇到过一种特有意思的情况日志里出现“exceeded retry limit, last status: 429 too many requests”。429是HTTP的状态码意思是请求发得太频繁被服务端限流了。这种一般不是你代码出错而是你跑的用例量太大、频率太高触发了网关或者业务方的频控策略。解决思路有几种一是把并发调整成串行二是调用之间加个短暂延时三是联系服务端同学确认限流阈值在阈值范围内设定测试节奏。如果是接入第三方开放平台的接口对方限流很严就要在测试数据里严格控制调用总量必要时跑低峰时段。5.2 证书校验失败的两种应对方案自签名HTTPS证书是测试环境的老大难。requests在默认情况下会校验证书链而内网环境的证书往往是自签的没有权威CA签名于是请求直接抛SSLError。这时候最简单的方法就是全局关掉校验并屏蔽警告import requests import urllib3 urllib3.disable_warnings(urllib3.exceptions.InsecureRequestWarning) resp requests.get(url, verifyFalse, timeout10)但是“能跑通”和“安全地跑通”是两码事。如果你只是对内网测试环境临时关校验问题不大如果你长期关掉校验跑生产环境的接口那就要小心了——中间人攻击的风险真实存在你无法确认响应数据是不是被篡改过。更稳妥的替代方案是把测试环境的证书下载下来在代码里通过verify参数指定证书文件路径resp requests.get(url, verify/path/to/test_env_cert.pem, timeout10)这种方式既不会对真实证书链路做妥协又能绕过自签名报错。注意证书文件路径不要硬编码在代码里放到配置项里跟环境切换走同一套机制。5.3 中文乱码与响应编码判断接口返回里带中文是常态但有时候你会发现resp.text打印出来是一堆乱码比如\u5f00\u59cb或者类似于“ç”开头的怪字符。原因在于requests对响应体的编码判断不够智能。HTTP响应头通常会带Content-Type里的charset字段requests优先使用这个编码来解码但如果服务端没在响应头里声明charsetrequests会fallback到ISO-8859-1不认UTF-8的中文字符。解决方法是主动让requests去猜测编码resp requests.get(url, timeout10) if resp.encoding is None or resp.encoding.lower() iso-8859-1: resp.encoding resp.apparent_encoding data resp.textapparent_encoding是requests基于响应内容字节流分析出来的编码对中文网页/接口的识别准确率很高。我一般会在所有请求封装的通用入口里加上这段逻辑保证下游解析resp.text时拿到的都是正确解码后的内容。另外要提醒一点resp.text和resp.content要分清楚。text是对content按编码解码后的字符串content是原始字节流。有时候你要做sign签名校验必须用content拿原始字节去算用text转来转去反而容易出偏差。5.4 接口依赖与前后置数据处理动态参数怎么取接口之间普遍存在依赖关系。最典型的是A接口返回一个idB接口要用这个id去查详情。你不能手动把这个id硬编码到用例里因为每次测试数据可能都不一样。这时候就需要在用例执行过程中动态提取中间参数。我的做法是在YAML用例格式里增加一个extract字段支持从响应里提取数据保存到上下文环境后续用例再从上下文取值拼到请求里。用例数据长这样- name: 创建订单 request: method: POST url: /api/order/create json: product_id: 1001 extract: order_id: data.order_id expect: status_code: 200 code: 0 - name: 查询新建订单 request: method: GET url: /api/order/{order_id} expect: status_code: 200 code: 0执行器的逻辑就变成了两步发送请求后先看有没有extract字段有就从响应体里按点号路径取值存进一个全局上下文dict构造请求前把URL里的{variable}和json里的{variable}替换成当前上下文里对应的值。这个机制解决了接口自动化里最核心的用例关联问题也让用例文件在维护时看起来非常直观。实现思路不复杂核心代码就是把字符串里的占位符做一次格式化替换。依赖顺序执行还有一个容易被忽略的问题如果创建订单的前置用例失败了后续依赖它的用例全都会失败。所以我在报告里会特别关注依赖链最开头的用例一旦它挂了后面红一片很可能只是连锁反应不一定是这些用例本身的逻辑问题。排查时要顺着依赖链从前往后看而不是盯着最后一条失败用例猜原因。最后分享几个小经验这套框架我从最开始的几十行脚本一路演进到现在接近上千条用例最大的体会就是接口自动化最怕的不是requests用不熟而是架构一开始就没想清楚导致后面每加一个用例都要改代码。所以强烈建议你把用例数据、请求封装、断言逻辑、执行调度这四层拆开哪怕前期会多写一点代码后续的维护成本会指数级下降。还有一个小建议新项目不要一上来就追求“框架化”。先拿requests把几个核心接口的自动化脚本写出来跑通一个完整的业务链路验证这个方向在你的项目里确实能落地然后再逐步引入数据驱动、pytest、CI这些偏工程化的能力。大多数接口自动化项目死掉不是技术问题而是因为搭建和学习成本太高团队根本维护不起来。先跑起来再慢慢变重是我踩过很多坑之后最想提醒你的一件事。
