尧图网站建设 
做接口自动化测试这几年我前后折腾过好几套方案最后真正沉淀下来、还在持续维护的就是 Python pytest requests 这套组合。它不算什么花哨的技术选型网上到处能看到类似的关键词但要是真把它搭成一个能长期跑、能接 CI、能让不同水平的组员都上手写用例的框架里面的细节其实相当多。这篇文章我想把整套框架的设计思路、请求封装、用例组织、测试数据管理、报告集成完整梳理一遍重点记录参数怎么定、分层怎么切、哪些坑我已经替大家踩过了。无论你是刚接触接口测试的测试开发还是想把手头零散脚本整理成正式框架的在职 QA这篇都能给你一条直接照着做就能跑的路径。1. 这套框架到底在解决什么问题整体设计思路1.1 为什么是 pytest requests而不是其他组合先说选型。接口自动化测试的常见方案其实不少unittest、pytest、Robot Framework、再加上各种二次封装平台选哪个都有理由。我的判断标准很简单团队里写用例的人不一定都是资深开发框架必须够轻、够直观、问题在网上有大量现成答案。requests 这个库其实是 Python 社区里做 HTTP 请求的事实标准很多人第一反应是它常用于爬虫这话没错但它作为接口测试的客户端同样合适。requests 对 HTTP 协议封装得足够高级get、post、put、delete 都是直接可读的语义化方法session 会自动管理 Cookie超时、重试、SSL 校验这些也都能通过参数控制。对比 urllib 和 http.client代码量少一半可读性高一个量级。pytest 这边相比 unittest 最大的优势是写用例不需要继承某个类一个普通函数加 test_ 前缀就是用例。fixture 机制更是把 setup/teardown 玩出了花scope 可以控制到模块级、类级、函数级甚至 session 级。再加上 pytest 的插件生态pytest-html、pytest-xdist、pytest-ordering、pytest-rerunfailures、allure-pytest几乎你能想到的测试场景都有对应的扩展。Robot Framework 本身也很强大但关键字和变量层的抽象对纯接口项目来说稍显笨重而且写复杂断言时反而绕。1.2 目录结构怎么分层框架搭起来之后第一个要解决的就是代码组织问题。我见过很多测试脚本功能没问题但一百个用例全塞在一个文件里维护的人想死的心都有。所以工程一上来就要把目录结构定清楚这是整个框架的地基。我用的是这样的结构api_test_framework/ ├── config/ │ ├── __init__.py │ ├── config.py # 环境、base_url、超时默认值 │ └── pytest.ini ├── common/ │ ├── __init__.py │ ├── http_client.py # requests 请求封装 │ ├── logger.py # 日志封装 │ └── assert_utils.py # 断言方法封装 ├── data/ │ ├── user_data.json # 测试数据文件 │ └── login_cases.yaml ├── testcases/ │ ├── __init__.py │ ├── conftest.py # 全局 fixture │ ├── test_user_login.py │ └── test_order_flow.py ├── reports/ │ ├── logs/ │ └── allure-results/ ├── requirements.txt └── conftest.py为什么这么分核心思想是“配置、公共能力、测试数据、测试用例”四层完全解耦。cases 里只关心“我要测什么、断言什么结果”不关心请求细节common 里只提供“怎么做请求、怎么打日志”的通用能力config 和 data 放可变内容环境切换、用例数据调整都不需要动代码。这样新同学接手一个模块打开对应 test_*.py 文件就能看懂逻辑不用去翻底层的网络实现。1.3 分层之后带来的实际收益这套结构最直接的收益就是“加新接口”和“换环境”这两个高频操作成本极低。加新接口时只需要在 testcases 下新增一个测试文件用 common 里的 client 发请求用 config 里的地址拼接 URL用 data 下的 json 文件管理参数组合。不会出现复制粘贴几十行请求代码、然后不小心改错 header 的情况。换环境时改 config.py 里一个环境变量所有用例的 base_url 自动切换不需要在整个工程里搜 IP 端口字符串再逐个替换。扩展到多端时比如同一套用例要跑 Android 和 iOS 两种后端配置config 里再做一层多环境映射就行。另外还有一个隐藏收益方便生成统计和报表。因为所有请求都走同一个封装入口日志、耗时、状态码这些指标统一采集后面接 Allure 或自己写统计脚本都很自然。如果每个用例手写 requests 调用日志格式五花八门到了分析阶段全是眼泪。2. 环境搭建和工程初始化先把地基打牢2.1 Python 版本与虚拟环境框架虽说是轻量组合但环境这块还是建议一次配好。Python 版本我推荐 3.8 或更高原因不是 3.7 跑不了而是 pytest 和 requests 的新版本已经开始放弃对老版本的支持用 3.8 以上能省掉不少依赖冲突的麻烦。另一个强烈建议是使用虚拟环境。Python 项目最头疼的问题就是全局环境被不同项目的依赖搞乱今天给 A 项目装了个旧版本明天 B 项目就跑不起来。用 venv 创建独立环境是成本最低的隔离方案python -m venv venv source venv/bin/activate # Windows 下是 venv\Scripts\activate这一步做完后面所有 pip install 都只会装进这个 venv 目录里即使安装失败、依赖冲突把整个目录删掉重建就行系统 Python 不会受影响。2.2 依赖安装与 requirements.txt核心依赖其实只有两个pytest 和 requests。但实际项目里通常还需要更多辅助库比如 pytest-html 生成 HTML 报告、allure-pytest 接 Allure、pyyaml 读取 YAML 配置、openpyxl 读取 Excel 测试数据。安装命令如下pip install pytest requests pytest-html allure-pytest pyyaml openpyxl如果不想手动一个个装就把依赖写进 requirements.txtpytest7.4.0 requests2.31.0 pytest-html4.1.0 allure-pytest2.13.2 PyYAML6.0 openpyxl3.1.0然后一行命令搞定pip install -r requirements.txt这里想特别提醒一点很多新同学遇到“No module named requests”报错第一反应是代码写错了其实绝大多数情况是当前解释器不是装了依赖的那个解释器。尤其是 PyCharm 和 VSCode 都支持多解释器切换跑代码之前先确认底部的解释器路径是不是指向 venv 里的那个。2.3 pytest.ini 里的关键配置pytest 的配置可以写在命令行参数里但更推荐写进 pytest.ini。一是配置随工程走不用每个人记住一长串参数二是团队约定固化下来谁执行都一样。一份最小但完整的 pytest.ini 长这样[pytest] testpaths testcases addopts -v -s --tbshort log_cli true log_cli_level INFO log_cli_format %(asctime)s [%(levelname)s] %(name)s: %(message)s markers smoke: 冒烟测试用例 p0: 高优用例 p1: 中优用例逐项解释一下testpaths 指定 pytest 发现用例的目录避免它跑到 venv 或者 reports 里去找 test_*.py。addopts 是默认追加的命令行参数-v 打印每个用例执行结果-s 让 print 输出显示出来--tbshort 出错时只打印简短回溯日志不会刷屏。log_cli 系列是让日志直接输出到控制台调试的时候特别有用。markers 用来声明自定义标签。如果不声明pytest 执行时会提示 warning声明之后再用 -m smoke 筛选执行就非常干净。2.4 PyCharm / VSCode 里的 pytest 配置IDE 里的配置坑值得单独说因为太常见了。PyCharm 默认的测试运行器可能还是 unittest这样跑 pytest 用例的时候会报 “no tests were found” 或者运行方式不对。设置路径File - Settings - Tools - Python Integrated Tools - Testing - Default test runner改成 pytest。改完之后右键测试函数就能直接以 pytest 方式运行。VSCode 则要走 Python 扩展面板。项目打开后打开一条测试文件VSCode 会提示配置测试框架选择 pytest然后在 settings.json 里指定 pytest 参数{ python.testing.pytestEnabled: true, python.testing.pytestArgs: [-s, -v] }还有一个最容易踩的坑VSCode 选的 Python 解释器不对。命令面板搜 “Python: Select Interpreter”选择刚才建好的 venv 路径下的 python否则依赖和代码都对得上就是跑不起来。3. requests 请求封装把接口调用收拢到一个入口3.1 为什么先把 requests 基础用法过一遍requests 虽然简单但有几个基础点如果理解不到位封装后面容易出错。先说最核心的三个参数timeout 控制等待响应的秒数不设 timeout 的后果是请求可能会卡住很长时间才报错verify 控制是否校验 SSL 证书测试环境常用自签名证书需要传 verifyFalse但到生产环境必须恢复校验headers 里 Content-Type 和 User-Agent 经常是后端校验的隐形条件。一段最基础的 GET 和 POST 长这样import requests # GET 请求 resp requests.get( https://api.example.com/v1/user/info, params{user_id: 1001}, headers{Authorization: Bearer token123}, timeout10, verifyFalse ) print(resp.status_code) print(resp.json()) # POST 请求 resp requests.post( https://api.example.com/v1/user/login, json{username: admin, password: 123456}, timeout10 ) print(resp.json())这里有个小细节POST 传参建议用 json 而不是 data。json 参数会自动帮你把字典序列化成 JSON 字符串并设置 Content-Type: application/json。用 data 传 dict 时requests 会按表单格式编码后端如果按 JSON 解析就取不到值了。3.2 封装一个 HttpUtils把通用逻辑收进来为什么不建议在用例里直接调 requests因为真实项目中每个接口都要处理 base_url 拼接、统一超时、统一 header、登录态注入、日志记录、异常重试。这些逻辑如果散落在每个用例里一是重复代码爆炸二是要改一个全局策略的时候得全项目搜索替换。我封装了一个最简的 HttpUtils核心思路是“配置默认值 session 复用 统一日志”import requests import time import logging from config.config import BASE_URL, DEFAULT_TIMEOUT, TOKEN logger logging.getLogger(__name__) class HttpUtils: def __init__(self, base_urlBASE_URL, timeoutDEFAULT_TIMEOUT): self.base_url base_url.rstrip(/) self.timeout timeout self.session requests.Session() self.session.verify False self.session.headers.update({ Content-Type: application/json, User-Agent: ApiAutoTest/1.0 }) self.session.headers[Authorization] fBearer {TOKEN} def request(self, method, url, **kwargs): url f{self.base_url}{url} kwargs.setdefault(timeout, self.timeout) start time.time() logger.info(f请求: {method.upper()} {url} params{kwargs.get(params)} json{kwargs.get(json)}) try: resp self.session.request(method, url, **kwargs) except requests.Timeout as e: logger.error(f请求超时: {url}) raise except requests.RequestException as e: logger.error(f请求异常: {url}, {e}) raise cost (time.time() - start) * 1000 logger.info(f响应: {resp.status_code} 耗时{cost:.0f}ms body{resp.text[:500]}) return resp def get(self, url, **kwargs): return self.request(GET, url, **kwargs) def post(self, url, **kwargs): return self.request(POST, url, **kwargs)注意几个设计点session 不是每次新建requests.Session 会复用底层 TCP 连接连续调用性能提升非常明显。base_url 只拼一次用例里写相对路径换环境不用改用例。每条请求和响应都记日志排查问题时候不靠猜直接看日志就能还原现场。verifyFalse 是测试环境的应对方案正式框架里这个开关建议做成可配置而不是写死。3.3 登录态与 Token 自动续期接口测试中登录态管理是绕不开的坎。常见做法是登录接口返回 token后续接口在请求头里带 Authorization。但很多项目的 token 有时效比如 30 分钟过期用例一跑久后半段全部 401。比较实用的方案是“前置 token 遇到 401 刷新一次”。先用一个 session 级 fixture 登录拿到 token 写入环境变量普通接口直接用如果请求返回 401就在异常处理的钩子里调用 refresh_token 刷新然后重放一次请求。def request(self, method, url, **kwargs): url f{self.base_url}{url} kwargs.setdefault(timeout, self.timeout) resp self.session.request(method, url, **kwargs) if resp.status_code 401 and self._refresh_token(): self.session.headers[Authorization] fBearer {self.token} resp self.session.request(method, url, **kwargs) return resp这里的关键是业务方必须提供刷新 token 的接口而不是每次都重新登录。刷新逻辑只做一次避免死循环。把鉴权收进封装层之后用例作者完全不用关心 token 怎么来这是框架体验上很重要的一环。3.4 从请求封装到测试框架的边界有一点容易混淆requests 负责的只是“发请求、收响应”它本身不具备测试用例管理、断言、报告生成这些能力。所以框架里 requests 的角色是“网络客户端”pytest 负责的是“测试编排”。很多人看网上博客把 requests 和“爬虫”联系在一起其实底层逻辑一样都是构造 HTTP 请求拿数据区别只是目标——爬虫是抓取数据接口测试是验证服务端行为是否符合预期。我在封装层不会让代码和具体业务强耦合保持 requests 的通用性这样以后哪怕做数据采集工具这套 HttpUtils 直接复用也没问题。4. pytest 用例编写与数据驱动用例越写越省力4.1 fixture 处理前置条件pytest 的 fixture 是这套框架里最增值的部分。接口测试中大量前置条件是“需要登录”、“需要有一条已存在的订单”、“需要清理上次脏数据”这些如果用断言写在用例开头逻辑会非常恶心。fixture 可以完美解决。在 conftest.py 里定义好用例声明参数名即可自动注入import pytest from common.http_client import HttpUtils pytest.fixture(scopesession) def client(): 所有用例共用一个 client登录态只维护一份 return HttpUtils() pytest.fixture() def created_user(client): 创建测试用户用后清理 data {name: auto_user, source: pytest} resp client.post(/api/v1/users, jsondata) user_id resp.json()[id] yield user_id client.delete(f/api/v1/users/{user_id})fixture 里 yield 前面的代码是 setupyield 后面的代码是 teardown。scopesession 意味着整个测试会话只执行一次对于登录这种昂贵操作特别合适。scope 默认是 function也就是每个用例都跑一遍适合独立数据的准备和清理。用 fixture 的好处在于用例可以直接声明依赖写起来极其干净def test_get_user(client, created_user): resp client.get(f/api/v1/users/{created_user}) assert resp.status_code 200 assert resp.json()[name] auto_user4.2 参数化从一条用例变成一批用例接口测试最常做的事就是“同样的操作不同参数验证不同结果”。比如登录接口要测用户名错误、密码错误、账号锁定、参数缺失这些场景。不用参数化就是复制粘贴 N 份用 pytest 参数化一行就能解决import pytest pytest.mark.parametrize(username,password,expect_code, [ (admin, 123456, 200), (admin, wrong, 40001), (not_exist, 123456, 40002), (, 123456, 40003), ]) def test_login_cases(client, username, password, expect_code): resp client.post(/api/v1/auth/login, json{username: username, password: password}) assert resp.status_code 200 assert resp.json()[code] expect_code这样一条函数就覆盖了 4 个场景pytest 报告里会显示 4 条独立用例哪组参数挂了看 ID 就知道。多组参数时还可以叠加多个 parametrize 装饰器做笛卡尔积覆盖场景就更全面了。4.3 从 JSON / YAML / Excel 读取测试数据参数少的时候直接在装饰器里写没问题但一旦数据量大或者需要让非开发同事参与维护把数据写进代码就不合适了。我的习惯是普通组合用 JSON/YAML大量数据用 Excel。比如 data/login_cases.yaml- username: admin password: 123456 expect_code: 200 - username: admin password: wrong expect_code: 40001然后在测试文件里读取并参数化import yaml import pytest with open(data/login_cases.yaml, encodingutf-8) as f: cases yaml.safe_load(f) pytest.mark.parametrize(case, cases, idslambda c: c[username]) def test_login_by_yaml(client, case): resp client.post(/api/v1/auth/login, json{username: case[username], password: case[password]}) assert resp.json()[code] case[expect_code]注意 ids 参数它让每条用例在报告里显示成一个可读的名字否则就是 case0、case1跑挂了还得去对数据文件。数据外置之后维护成本和用例数量基本无关这是数据驱动最核心的价值。4.4 断言别只断言 200接口自动化最容易犯的错误就是只检查 status_code 200。200 只能说明 HTTP 层面请求成功了业务逻辑可能完全不对比如返回了错误码、返回了空数据。所以要增加多层断言。比较推荐的三层断言HTTP 状态码这个交给封装层判断一般不是 2xx 直接记为失败。业务 code 和 message判断服务端是否正确处理了请求。核心业务字段比如登录接口返回的 token 不能为空用户信息的 username 要和入参一致。响应时间的断言也不容忽视。接口性能恶化往往是一个渐变过程在测试框架里给关键接口加一个耗时阈值比如超过 2000ms 直接失败能在回归阶段提前暴露问题。还有一个进阶做法是引入 jsonpath 或者针对大响应做部分字段校验但起步阶段先吃透这三层就够用。5. 配置分离与数据管理换环境不折腾代码5.1 多环境 base_url 切换接口测试最典型的场景是同一套用例要跑多个环境开发联调环境、测试环境、预发布环境。如果 base_url 写在代码里换环境就得改代码改完还要担心没改干净。我用的是“环境变量 配置模块”方案。config/config.py 里定义一份映射表根据环境变量读取对应的配置import os ENV os.getenv(API_TEST_ENV, test).lower() CONFIG { dev: { base_url: http://10.0.0.12:8080, timeout: 15, }, test: { base_url: http://test.api.example.com, timeout: 10, }, prod: { base_url: https://api.example.com, timeout: 10, }, } BASE_URL CONFIG[ENV][base_url] DEFAULT_TIMEOUT CONFIG[ENV][timeout]运行时只要设一个环境变量export API_TEST_ENVtest pytest如果接 CI不同流水线设置不同的环境变量即可。这样 base_url 只在配置层维护用例代码零改动。5.2 测试数据的准备与清理没有数据准备的接口测试只能测“查空数据”和“报错”这显然不够。工业级方案是前置准备数据 - 执行测试 - 后置清理数据。清理尤其重要否则跑一轮留下一堆脏数据下一轮用例就会因为数据冲突失败。fixture 的 teardown 机制正好干这个。比如测“创建订单 - 支付订单 - 查询订单状态”我需要保证订单初始状态是待支付pytest.fixture() def order_pending(client): resp client.post(/api/v1/orders, json{ goods_id: 1, quantity: 2 }) order_id resp.json()[order_id] yield order_id client.delete(f/api/v1/orders/{order_id})清理动作可以通过 API 做也可以通过直连数据库删除后者更彻底但侵入性更强需要看团队的基建能力。一个经验是尽量用“接口 数据库兜底”的组合。接口能删就用接口删接口删不掉或删除是逻辑删除时数据库兜底保证环境干净。5.3 敏感信息别写进代码自动化测试工程往往要提交到代码仓库如果里面硬编码了明文密码、token、签名密钥那就是潜在的安全事故。正确做法是敏感信息从环境变量或单独的本地配置文件中读取本地配置文件加 .gitignore不提交进仓库。import os USERNAME os.getenv(TEST_USERNAME, ) PASSWORD os.getenv(TEST_PASSWORD, )在本地跑的时候可以把测试账号写进一个不提交的 local_config.py 或者 .env 文件在 CI 里由流水线的 Secret 变量注入。还有一个细节日志里千万不要打印请求体中的 password 字段。我之前见过一版框架日志什么都好就是把登录密码跟着 JSON body 一起打出来了直接暴露在 CI 日志里这属于要尽早杜绝的低级问题。6. 日志、报告和持续集成让测试结果自己“说话”6.1 日志体系怎么搭接口测试的日志要解决的核心问题是“测试失败时对后端和开发还原现场”。所以日志至少要包含请求方法、完整 URL、请求参数、请求体、响应状态码、耗时、响应体片段。如果敏感字段和安全相关只打脱敏之后的内容。我习惯在工程里放一个 logger.py统一日志格式和输出到文件import logging from logging.handlers import RotatingFileHandler def setup_logger(nameapitest, log_filereports/logs/apitest.log): logger logging.getLogger(name) logger.setLevel(logging.DEBUG) handler RotatingFileHandler(log_file, maxBytes10*1024*1024, backupCount5) fmt %(asctime)s [%(levelname)s] %(name)s:%(lineno)d - %(message)s handler.setFormatter(logging.Formatter(fmt)) logger.addHandler(handler) return loggerRotatingFileHandler 的好处是日志文件到 10MB 自动切割保留最近 5 份不会把磁盘撑爆。日志有了之后请求多的项目还可以做慢接口统计一段时间的日志拉下来哪些接口平均耗时高、哪些偶发 5xx一目了然。6.2 Allure 报告集成pytest 自带的终端输出适合开发阶段给领导或团队看还是要有个像样的报告。Allure 是目前测试报告里的标配支持历史趋势、失败分类、用例层级展示。先装 allure-pytest 和 allure 命令行工具然后执行pytest --alluredirreports/allure-results allure serve reports/allure-resultsserve 命令会本地起一个服务打开浏览器看报告。想在 CI 里出静态报告用 allure generate 生成 HTML 目录。要让报告更可读可以在 conftest.py 里加 hook把请求和响应信息挂到失败用例上import pytest import allure pytest.hookimpl(hookwrapperTrue) def pytest_runtest_makereport(item, call): outcome yield report outcome.get_result() if report.when call and report.failed: client item.funcargs.get(client) if client and hasattr(client, last_response): with allure.attach(client.last_response.text, 响应, allure.attachment_type.TEXT): pass这样开发看到报错就知道请求发出去后实际返回了什么不用再跑一遍复现。我在团队里推行这套之后开发提 bug 的效率高了很多。6.3 Jenkins / GitLab CI 接入用例能本地跑只是第一步真正产生价值是把它接到持续集成里让每次代码提交后自动跑回归。以 GitLab CI 为例一个最简流水线文件stages: - test api-test: stage: test script: - pip install -r requirements.txt - python -m pytest --alluredirreports/allure-results artifacts: paths: - reports/allure-results only: - main再配合定时任务每天早上跑一次全量接口回归晚上跑重点冒烟。只要出现环境异常还能在流水线里做通知。这里要提醒一句上线 CI 之前先把用例的稳定性调好否则因网络波动、测试数据冲突导致的失败会把团队的信任消耗光。宁可先少跑几条核心用例也不要第一次就跑出大量红灯。7. 遇到最多的几个问题排查实录与避坑建议7.1 “429 too many requests”和重试策略很多刚用 requests 写接口自动化的人都会遇到这个报错“exceeded retry limit, last status: 429 too many requests”。这个问题的背景是服务端做了限流单位时间内同一个来源的请求超过阈值就返回 429。如果你在代码里配置过 urllib3 的 Retry重试到上限之后就会把最后一次失败状态抛出来表现形式就是上面那串英文。遇到 429 先别急着改框架一步步排查确认是否真的触发了服务端限流看服务端日志或响应头里的 RateLimit-Remaining 字段。看一下自己的用例里有没有短时间大量并发请求尤其是加了 pytest-xdist 并发执行的时候。分析是不是数据准备或清理阶段重复调用高频接口比如每个用例都登录一次。处理方式也有几种如果业务允许降低请求频率在用例间加 time.sleep(0.1~1)。如果并发是必须的调整 pytest-xdist 的进程数不要开太多。请求封装里配置合理的重试策略。配置重试时要用心from urllib3.util.retry import Retry from requests.adapters import HTTPAdapter session requests.Session() retry Retry( total3, backoff_factor0.5, status_forcelist[429, 500, 502, 503], allowed_methods[GET, POST] ) adapter HTTPAdapter(max_retriesretry) session.mount(http://, adapter) session.mount(https://, adapter)backoff_factor 是退避系数请求失败后按 0.5s、1s、2s 的间隔重试避免重试反而加重服务端压力。但这里有个重要提醒自动化测试中不是所有请求都适合自动重试POST 类请求重试可能会造成重复下单、重复创建数据所以在框架里我通常只给 GET 和幂等请求重试其他请求失败直接抛异常。7.2 requests 连接池与并发请求报错另一个高频问题是并发量一上来控制台报 “connection pool is full, discarding connection” 或者奇怪的连接断开报错。这是 requests 底层连接池的默认限制导致的。requests 用的是 urllib3 的 PoolManager默认连接池只能容纳固定数量的连接。解决方式是在创建 session 时给 HTTPAdapter 增大连接池容量adapter HTTPAdapter( pool_connections20, # 缓存连接数 pool_maxsize20 # 每个 host 最大连接池大小 ) session.mount(https://, adapter) session.mount(http://, adapter)这个配置开了之后并发场景的稳定性会上来很多。另外还有一种“too many concurrent requests”报错通常是框架内部用了多线程并发请求但线程数没控制导致连接池被打满。测试框架里没有绝对必要并发就别并发接口自动化讲究稳定优先少一个并发就少一类环境问题。7.3 用例执行顺序与依赖问题接口测试中经常有“先创建订单再支付再查询”的顺序依赖。pytest 默认按文件内定义顺序执行但跨文件之间不保证顺序。很多人第一反应是给所有用例排一个全局顺序这种做法维护成本极高加一个用例就要重排一遍。我推荐的做法是不要依赖“执行顺序”而是把依赖数据通过 fixture 显式传递。比如支付接口需要 order_id就在 fixture 里创建订单并返回 id支付用例直接拿这个 id 执行case 之间不存在隐式顺序问题。如果真的要测一条完整业务链路那就把整条链路写成一个用例函数用中间变量串联而不是拆成多个互相依赖的测试函数。如果你确实需要控制顺序可以用 pytest-ordering 插件标记 pytest.mark.run(order1)但这更适合冒烟环境里有明确先后依赖的少量用例不适合作为全项目的编码习惯。7.4 IDE 里跑 pytest 各种不生效最后一个很常见的问题是“代码在命令行跑没问题但在 IDE 里一跑就报错”。绝大多数字面原因不是代码问题而是 IDE 用的 Python 解释器不是装 pytest 的那个。PyCharm 里如果提示 pytest 未找到检查 File - Settings - Project - Python Interpreter 是否选中了 venv 路径。VSCode 里则是右下角解释器选择错误配合前面说的 “Python: Select Interpreter” 重新选一次。这个问题我见过太多了每次都能看到“新同学折腾一上午环境最后发现只是解释器选错位”。另外 Windows 下如果直接在终端敲 pytest 显示不是内部或外部命令通常是 scripts 目录没加到 PATH解决办法是使用 python -m pytest 执行这样不管你 PATH 怎么配只要 Python 本身能用pytest 就能跑起来。最后聊点框架之外的东西。我维护这套框架时间越长越觉得选型不是重点稳定性和可维护性才是重点。实际跑接口自动化最大的敌人往往不是断言逻辑而是测试环境不稳定、数据互相污染、限流超时这些看似很小的事。所以我的建议是先跑通一个最小闭环比如登录接口的 10 条用例再逐步加日志、加报告、加 CI、加数据驱动。与其一开始就设计一个特别宏大的框架不如让它长在真实业务上遇到问题再针对性完善。如果这篇文章能让你把第一版快速搭起来那我在这里写的这些细节就值了。 Python+pytest+requests接口自动化测试框架搭建全指南
做接口自动化测试这几年我前后折腾过好几套方案最后真正沉淀下来、还在持续维护的就是 Python pytest requests 这套组合。它不算什么花哨的技术选型网上到处能看到类似的关键词但要是真把它搭成一个能长期跑、能接 CI、能让不同水平的组员都上手写用例的框架里面的细节其实相当多。这篇文章我想把整套框架的设计思路、请求封装、用例组织、测试数据管理、报告集成完整梳理一遍重点记录参数怎么定、分层怎么切、哪些坑我已经替大家踩过了。无论你是刚接触接口测试的测试开发还是想把手头零散脚本整理成正式框架的在职 QA这篇都能给你一条直接照着做就能跑的路径。1. 这套框架到底在解决什么问题整体设计思路1.1 为什么是 pytest requests而不是其他组合先说选型。接口自动化测试的常见方案其实不少unittest、pytest、Robot Framework、再加上各种二次封装平台选哪个都有理由。我的判断标准很简单团队里写用例的人不一定都是资深开发框架必须够轻、够直观、问题在网上有大量现成答案。requests 这个库其实是 Python 社区里做 HTTP 请求的事实标准很多人第一反应是它常用于爬虫这话没错但它作为接口测试的客户端同样合适。requests 对 HTTP 协议封装得足够高级get、post、put、delete 都是直接可读的语义化方法session 会自动管理 Cookie超时、重试、SSL 校验这些也都能通过参数控制。对比 urllib 和 http.client代码量少一半可读性高一个量级。pytest 这边相比 unittest 最大的优势是写用例不需要继承某个类一个普通函数加 test_ 前缀就是用例。fixture 机制更是把 setup/teardown 玩出了花scope 可以控制到模块级、类级、函数级甚至 session 级。再加上 pytest 的插件生态pytest-html、pytest-xdist、pytest-ordering、pytest-rerunfailures、allure-pytest几乎你能想到的测试场景都有对应的扩展。Robot Framework 本身也很强大但关键字和变量层的抽象对纯接口项目来说稍显笨重而且写复杂断言时反而绕。1.2 目录结构怎么分层框架搭起来之后第一个要解决的就是代码组织问题。我见过很多测试脚本功能没问题但一百个用例全塞在一个文件里维护的人想死的心都有。所以工程一上来就要把目录结构定清楚这是整个框架的地基。我用的是这样的结构api_test_framework/ ├── config/ │ ├── __init__.py │ ├── config.py # 环境、base_url、超时默认值 │ └── pytest.ini ├── common/ │ ├── __init__.py │ ├── http_client.py # requests 请求封装 │ ├── logger.py # 日志封装 │ └── assert_utils.py # 断言方法封装 ├── data/ │ ├── user_data.json # 测试数据文件 │ └── login_cases.yaml ├── testcases/ │ ├── __init__.py │ ├── conftest.py # 全局 fixture │ ├── test_user_login.py │ └── test_order_flow.py ├── reports/ │ ├── logs/ │ └── allure-results/ ├── requirements.txt └── conftest.py为什么这么分核心思想是“配置、公共能力、测试数据、测试用例”四层完全解耦。cases 里只关心“我要测什么、断言什么结果”不关心请求细节common 里只提供“怎么做请求、怎么打日志”的通用能力config 和 data 放可变内容环境切换、用例数据调整都不需要动代码。这样新同学接手一个模块打开对应 test_*.py 文件就能看懂逻辑不用去翻底层的网络实现。1.3 分层之后带来的实际收益这套结构最直接的收益就是“加新接口”和“换环境”这两个高频操作成本极低。加新接口时只需要在 testcases 下新增一个测试文件用 common 里的 client 发请求用 config 里的地址拼接 URL用 data 下的 json 文件管理参数组合。不会出现复制粘贴几十行请求代码、然后不小心改错 header 的情况。换环境时改 config.py 里一个环境变量所有用例的 base_url 自动切换不需要在整个工程里搜 IP 端口字符串再逐个替换。扩展到多端时比如同一套用例要跑 Android 和 iOS 两种后端配置config 里再做一层多环境映射就行。另外还有一个隐藏收益方便生成统计和报表。因为所有请求都走同一个封装入口日志、耗时、状态码这些指标统一采集后面接 Allure 或自己写统计脚本都很自然。如果每个用例手写 requests 调用日志格式五花八门到了分析阶段全是眼泪。2. 环境搭建和工程初始化先把地基打牢2.1 Python 版本与虚拟环境框架虽说是轻量组合但环境这块还是建议一次配好。Python 版本我推荐 3.8 或更高原因不是 3.7 跑不了而是 pytest 和 requests 的新版本已经开始放弃对老版本的支持用 3.8 以上能省掉不少依赖冲突的麻烦。另一个强烈建议是使用虚拟环境。Python 项目最头疼的问题就是全局环境被不同项目的依赖搞乱今天给 A 项目装了个旧版本明天 B 项目就跑不起来。用 venv 创建独立环境是成本最低的隔离方案python -m venv venv source venv/bin/activate # Windows 下是 venv\Scripts\activate这一步做完后面所有 pip install 都只会装进这个 venv 目录里即使安装失败、依赖冲突把整个目录删掉重建就行系统 Python 不会受影响。2.2 依赖安装与 requirements.txt核心依赖其实只有两个pytest 和 requests。但实际项目里通常还需要更多辅助库比如 pytest-html 生成 HTML 报告、allure-pytest 接 Allure、pyyaml 读取 YAML 配置、openpyxl 读取 Excel 测试数据。安装命令如下pip install pytest requests pytest-html allure-pytest pyyaml openpyxl如果不想手动一个个装就把依赖写进 requirements.txtpytest7.4.0 requests2.31.0 pytest-html4.1.0 allure-pytest2.13.2 PyYAML6.0 openpyxl3.1.0然后一行命令搞定pip install -r requirements.txt这里想特别提醒一点很多新同学遇到“No module named requests”报错第一反应是代码写错了其实绝大多数情况是当前解释器不是装了依赖的那个解释器。尤其是 PyCharm 和 VSCode 都支持多解释器切换跑代码之前先确认底部的解释器路径是不是指向 venv 里的那个。2.3 pytest.ini 里的关键配置pytest 的配置可以写在命令行参数里但更推荐写进 pytest.ini。一是配置随工程走不用每个人记住一长串参数二是团队约定固化下来谁执行都一样。一份最小但完整的 pytest.ini 长这样[pytest] testpaths testcases addopts -v -s --tbshort log_cli true log_cli_level INFO log_cli_format %(asctime)s [%(levelname)s] %(name)s: %(message)s markers smoke: 冒烟测试用例 p0: 高优用例 p1: 中优用例逐项解释一下testpaths 指定 pytest 发现用例的目录避免它跑到 venv 或者 reports 里去找 test_*.py。addopts 是默认追加的命令行参数-v 打印每个用例执行结果-s 让 print 输出显示出来--tbshort 出错时只打印简短回溯日志不会刷屏。log_cli 系列是让日志直接输出到控制台调试的时候特别有用。markers 用来声明自定义标签。如果不声明pytest 执行时会提示 warning声明之后再用 -m smoke 筛选执行就非常干净。2.4 PyCharm / VSCode 里的 pytest 配置IDE 里的配置坑值得单独说因为太常见了。PyCharm 默认的测试运行器可能还是 unittest这样跑 pytest 用例的时候会报 “no tests were found” 或者运行方式不对。设置路径File - Settings - Tools - Python Integrated Tools - Testing - Default test runner改成 pytest。改完之后右键测试函数就能直接以 pytest 方式运行。VSCode 则要走 Python 扩展面板。项目打开后打开一条测试文件VSCode 会提示配置测试框架选择 pytest然后在 settings.json 里指定 pytest 参数{ python.testing.pytestEnabled: true, python.testing.pytestArgs: [-s, -v] }还有一个最容易踩的坑VSCode 选的 Python 解释器不对。命令面板搜 “Python: Select Interpreter”选择刚才建好的 venv 路径下的 python否则依赖和代码都对得上就是跑不起来。3. requests 请求封装把接口调用收拢到一个入口3.1 为什么先把 requests 基础用法过一遍requests 虽然简单但有几个基础点如果理解不到位封装后面容易出错。先说最核心的三个参数timeout 控制等待响应的秒数不设 timeout 的后果是请求可能会卡住很长时间才报错verify 控制是否校验 SSL 证书测试环境常用自签名证书需要传 verifyFalse但到生产环境必须恢复校验headers 里 Content-Type 和 User-Agent 经常是后端校验的隐形条件。一段最基础的 GET 和 POST 长这样import requests # GET 请求 resp requests.get( https://api.example.com/v1/user/info, params{user_id: 1001}, headers{Authorization: Bearer token123}, timeout10, verifyFalse ) print(resp.status_code) print(resp.json()) # POST 请求 resp requests.post( https://api.example.com/v1/user/login, json{username: admin, password: 123456}, timeout10 ) print(resp.json())这里有个小细节POST 传参建议用 json 而不是 data。json 参数会自动帮你把字典序列化成 JSON 字符串并设置 Content-Type: application/json。用 data 传 dict 时requests 会按表单格式编码后端如果按 JSON 解析就取不到值了。3.2 封装一个 HttpUtils把通用逻辑收进来为什么不建议在用例里直接调 requests因为真实项目中每个接口都要处理 base_url 拼接、统一超时、统一 header、登录态注入、日志记录、异常重试。这些逻辑如果散落在每个用例里一是重复代码爆炸二是要改一个全局策略的时候得全项目搜索替换。我封装了一个最简的 HttpUtils核心思路是“配置默认值 session 复用 统一日志”import requests import time import logging from config.config import BASE_URL, DEFAULT_TIMEOUT, TOKEN logger logging.getLogger(__name__) class HttpUtils: def __init__(self, base_urlBASE_URL, timeoutDEFAULT_TIMEOUT): self.base_url base_url.rstrip(/) self.timeout timeout self.session requests.Session() self.session.verify False self.session.headers.update({ Content-Type: application/json, User-Agent: ApiAutoTest/1.0 }) self.session.headers[Authorization] fBearer {TOKEN} def request(self, method, url, **kwargs): url f{self.base_url}{url} kwargs.setdefault(timeout, self.timeout) start time.time() logger.info(f请求: {method.upper()} {url} params{kwargs.get(params)} json{kwargs.get(json)}) try: resp self.session.request(method, url, **kwargs) except requests.Timeout as e: logger.error(f请求超时: {url}) raise except requests.RequestException as e: logger.error(f请求异常: {url}, {e}) raise cost (time.time() - start) * 1000 logger.info(f响应: {resp.status_code} 耗时{cost:.0f}ms body{resp.text[:500]}) return resp def get(self, url, **kwargs): return self.request(GET, url, **kwargs) def post(self, url, **kwargs): return self.request(POST, url, **kwargs)注意几个设计点session 不是每次新建requests.Session 会复用底层 TCP 连接连续调用性能提升非常明显。base_url 只拼一次用例里写相对路径换环境不用改用例。每条请求和响应都记日志排查问题时候不靠猜直接看日志就能还原现场。verifyFalse 是测试环境的应对方案正式框架里这个开关建议做成可配置而不是写死。3.3 登录态与 Token 自动续期接口测试中登录态管理是绕不开的坎。常见做法是登录接口返回 token后续接口在请求头里带 Authorization。但很多项目的 token 有时效比如 30 分钟过期用例一跑久后半段全部 401。比较实用的方案是“前置 token 遇到 401 刷新一次”。先用一个 session 级 fixture 登录拿到 token 写入环境变量普通接口直接用如果请求返回 401就在异常处理的钩子里调用 refresh_token 刷新然后重放一次请求。def request(self, method, url, **kwargs): url f{self.base_url}{url} kwargs.setdefault(timeout, self.timeout) resp self.session.request(method, url, **kwargs) if resp.status_code 401 and self._refresh_token(): self.session.headers[Authorization] fBearer {self.token} resp self.session.request(method, url, **kwargs) return resp这里的关键是业务方必须提供刷新 token 的接口而不是每次都重新登录。刷新逻辑只做一次避免死循环。把鉴权收进封装层之后用例作者完全不用关心 token 怎么来这是框架体验上很重要的一环。3.4 从请求封装到测试框架的边界有一点容易混淆requests 负责的只是“发请求、收响应”它本身不具备测试用例管理、断言、报告生成这些能力。所以框架里 requests 的角色是“网络客户端”pytest 负责的是“测试编排”。很多人看网上博客把 requests 和“爬虫”联系在一起其实底层逻辑一样都是构造 HTTP 请求拿数据区别只是目标——爬虫是抓取数据接口测试是验证服务端行为是否符合预期。我在封装层不会让代码和具体业务强耦合保持 requests 的通用性这样以后哪怕做数据采集工具这套 HttpUtils 直接复用也没问题。4. pytest 用例编写与数据驱动用例越写越省力4.1 fixture 处理前置条件pytest 的 fixture 是这套框架里最增值的部分。接口测试中大量前置条件是“需要登录”、“需要有一条已存在的订单”、“需要清理上次脏数据”这些如果用断言写在用例开头逻辑会非常恶心。fixture 可以完美解决。在 conftest.py 里定义好用例声明参数名即可自动注入import pytest from common.http_client import HttpUtils pytest.fixture(scopesession) def client(): 所有用例共用一个 client登录态只维护一份 return HttpUtils() pytest.fixture() def created_user(client): 创建测试用户用后清理 data {name: auto_user, source: pytest} resp client.post(/api/v1/users, jsondata) user_id resp.json()[id] yield user_id client.delete(f/api/v1/users/{user_id})fixture 里 yield 前面的代码是 setupyield 后面的代码是 teardown。scopesession 意味着整个测试会话只执行一次对于登录这种昂贵操作特别合适。scope 默认是 function也就是每个用例都跑一遍适合独立数据的准备和清理。用 fixture 的好处在于用例可以直接声明依赖写起来极其干净def test_get_user(client, created_user): resp client.get(f/api/v1/users/{created_user}) assert resp.status_code 200 assert resp.json()[name] auto_user4.2 参数化从一条用例变成一批用例接口测试最常做的事就是“同样的操作不同参数验证不同结果”。比如登录接口要测用户名错误、密码错误、账号锁定、参数缺失这些场景。不用参数化就是复制粘贴 N 份用 pytest 参数化一行就能解决import pytest pytest.mark.parametrize(username,password,expect_code, [ (admin, 123456, 200), (admin, wrong, 40001), (not_exist, 123456, 40002), (, 123456, 40003), ]) def test_login_cases(client, username, password, expect_code): resp client.post(/api/v1/auth/login, json{username: username, password: password}) assert resp.status_code 200 assert resp.json()[code] expect_code这样一条函数就覆盖了 4 个场景pytest 报告里会显示 4 条独立用例哪组参数挂了看 ID 就知道。多组参数时还可以叠加多个 parametrize 装饰器做笛卡尔积覆盖场景就更全面了。4.3 从 JSON / YAML / Excel 读取测试数据参数少的时候直接在装饰器里写没问题但一旦数据量大或者需要让非开发同事参与维护把数据写进代码就不合适了。我的习惯是普通组合用 JSON/YAML大量数据用 Excel。比如 data/login_cases.yaml- username: admin password: 123456 expect_code: 200 - username: admin password: wrong expect_code: 40001然后在测试文件里读取并参数化import yaml import pytest with open(data/login_cases.yaml, encodingutf-8) as f: cases yaml.safe_load(f) pytest.mark.parametrize(case, cases, idslambda c: c[username]) def test_login_by_yaml(client, case): resp client.post(/api/v1/auth/login, json{username: case[username], password: case[password]}) assert resp.json()[code] case[expect_code]注意 ids 参数它让每条用例在报告里显示成一个可读的名字否则就是 case0、case1跑挂了还得去对数据文件。数据外置之后维护成本和用例数量基本无关这是数据驱动最核心的价值。4.4 断言别只断言 200接口自动化最容易犯的错误就是只检查 status_code 200。200 只能说明 HTTP 层面请求成功了业务逻辑可能完全不对比如返回了错误码、返回了空数据。所以要增加多层断言。比较推荐的三层断言HTTP 状态码这个交给封装层判断一般不是 2xx 直接记为失败。业务 code 和 message判断服务端是否正确处理了请求。核心业务字段比如登录接口返回的 token 不能为空用户信息的 username 要和入参一致。响应时间的断言也不容忽视。接口性能恶化往往是一个渐变过程在测试框架里给关键接口加一个耗时阈值比如超过 2000ms 直接失败能在回归阶段提前暴露问题。还有一个进阶做法是引入 jsonpath 或者针对大响应做部分字段校验但起步阶段先吃透这三层就够用。5. 配置分离与数据管理换环境不折腾代码5.1 多环境 base_url 切换接口测试最典型的场景是同一套用例要跑多个环境开发联调环境、测试环境、预发布环境。如果 base_url 写在代码里换环境就得改代码改完还要担心没改干净。我用的是“环境变量 配置模块”方案。config/config.py 里定义一份映射表根据环境变量读取对应的配置import os ENV os.getenv(API_TEST_ENV, test).lower() CONFIG { dev: { base_url: http://10.0.0.12:8080, timeout: 15, }, test: { base_url: http://test.api.example.com, timeout: 10, }, prod: { base_url: https://api.example.com, timeout: 10, }, } BASE_URL CONFIG[ENV][base_url] DEFAULT_TIMEOUT CONFIG[ENV][timeout]运行时只要设一个环境变量export API_TEST_ENVtest pytest如果接 CI不同流水线设置不同的环境变量即可。这样 base_url 只在配置层维护用例代码零改动。5.2 测试数据的准备与清理没有数据准备的接口测试只能测“查空数据”和“报错”这显然不够。工业级方案是前置准备数据 - 执行测试 - 后置清理数据。清理尤其重要否则跑一轮留下一堆脏数据下一轮用例就会因为数据冲突失败。fixture 的 teardown 机制正好干这个。比如测“创建订单 - 支付订单 - 查询订单状态”我需要保证订单初始状态是待支付pytest.fixture() def order_pending(client): resp client.post(/api/v1/orders, json{ goods_id: 1, quantity: 2 }) order_id resp.json()[order_id] yield order_id client.delete(f/api/v1/orders/{order_id})清理动作可以通过 API 做也可以通过直连数据库删除后者更彻底但侵入性更强需要看团队的基建能力。一个经验是尽量用“接口 数据库兜底”的组合。接口能删就用接口删接口删不掉或删除是逻辑删除时数据库兜底保证环境干净。5.3 敏感信息别写进代码自动化测试工程往往要提交到代码仓库如果里面硬编码了明文密码、token、签名密钥那就是潜在的安全事故。正确做法是敏感信息从环境变量或单独的本地配置文件中读取本地配置文件加 .gitignore不提交进仓库。import os USERNAME os.getenv(TEST_USERNAME, ) PASSWORD os.getenv(TEST_PASSWORD, )在本地跑的时候可以把测试账号写进一个不提交的 local_config.py 或者 .env 文件在 CI 里由流水线的 Secret 变量注入。还有一个细节日志里千万不要打印请求体中的 password 字段。我之前见过一版框架日志什么都好就是把登录密码跟着 JSON body 一起打出来了直接暴露在 CI 日志里这属于要尽早杜绝的低级问题。6. 日志、报告和持续集成让测试结果自己“说话”6.1 日志体系怎么搭接口测试的日志要解决的核心问题是“测试失败时对后端和开发还原现场”。所以日志至少要包含请求方法、完整 URL、请求参数、请求体、响应状态码、耗时、响应体片段。如果敏感字段和安全相关只打脱敏之后的内容。我习惯在工程里放一个 logger.py统一日志格式和输出到文件import logging from logging.handlers import RotatingFileHandler def setup_logger(nameapitest, log_filereports/logs/apitest.log): logger logging.getLogger(name) logger.setLevel(logging.DEBUG) handler RotatingFileHandler(log_file, maxBytes10*1024*1024, backupCount5) fmt %(asctime)s [%(levelname)s] %(name)s:%(lineno)d - %(message)s handler.setFormatter(logging.Formatter(fmt)) logger.addHandler(handler) return loggerRotatingFileHandler 的好处是日志文件到 10MB 自动切割保留最近 5 份不会把磁盘撑爆。日志有了之后请求多的项目还可以做慢接口统计一段时间的日志拉下来哪些接口平均耗时高、哪些偶发 5xx一目了然。6.2 Allure 报告集成pytest 自带的终端输出适合开发阶段给领导或团队看还是要有个像样的报告。Allure 是目前测试报告里的标配支持历史趋势、失败分类、用例层级展示。先装 allure-pytest 和 allure 命令行工具然后执行pytest --alluredirreports/allure-results allure serve reports/allure-resultsserve 命令会本地起一个服务打开浏览器看报告。想在 CI 里出静态报告用 allure generate 生成 HTML 目录。要让报告更可读可以在 conftest.py 里加 hook把请求和响应信息挂到失败用例上import pytest import allure pytest.hookimpl(hookwrapperTrue) def pytest_runtest_makereport(item, call): outcome yield report outcome.get_result() if report.when call and report.failed: client item.funcargs.get(client) if client and hasattr(client, last_response): with allure.attach(client.last_response.text, 响应, allure.attachment_type.TEXT): pass这样开发看到报错就知道请求发出去后实际返回了什么不用再跑一遍复现。我在团队里推行这套之后开发提 bug 的效率高了很多。6.3 Jenkins / GitLab CI 接入用例能本地跑只是第一步真正产生价值是把它接到持续集成里让每次代码提交后自动跑回归。以 GitLab CI 为例一个最简流水线文件stages: - test api-test: stage: test script: - pip install -r requirements.txt - python -m pytest --alluredirreports/allure-results artifacts: paths: - reports/allure-results only: - main再配合定时任务每天早上跑一次全量接口回归晚上跑重点冒烟。只要出现环境异常还能在流水线里做通知。这里要提醒一句上线 CI 之前先把用例的稳定性调好否则因网络波动、测试数据冲突导致的失败会把团队的信任消耗光。宁可先少跑几条核心用例也不要第一次就跑出大量红灯。7. 遇到最多的几个问题排查实录与避坑建议7.1 “429 too many requests”和重试策略很多刚用 requests 写接口自动化的人都会遇到这个报错“exceeded retry limit, last status: 429 too many requests”。这个问题的背景是服务端做了限流单位时间内同一个来源的请求超过阈值就返回 429。如果你在代码里配置过 urllib3 的 Retry重试到上限之后就会把最后一次失败状态抛出来表现形式就是上面那串英文。遇到 429 先别急着改框架一步步排查确认是否真的触发了服务端限流看服务端日志或响应头里的 RateLimit-Remaining 字段。看一下自己的用例里有没有短时间大量并发请求尤其是加了 pytest-xdist 并发执行的时候。分析是不是数据准备或清理阶段重复调用高频接口比如每个用例都登录一次。处理方式也有几种如果业务允许降低请求频率在用例间加 time.sleep(0.1~1)。如果并发是必须的调整 pytest-xdist 的进程数不要开太多。请求封装里配置合理的重试策略。配置重试时要用心from urllib3.util.retry import Retry from requests.adapters import HTTPAdapter session requests.Session() retry Retry( total3, backoff_factor0.5, status_forcelist[429, 500, 502, 503], allowed_methods[GET, POST] ) adapter HTTPAdapter(max_retriesretry) session.mount(http://, adapter) session.mount(https://, adapter)backoff_factor 是退避系数请求失败后按 0.5s、1s、2s 的间隔重试避免重试反而加重服务端压力。但这里有个重要提醒自动化测试中不是所有请求都适合自动重试POST 类请求重试可能会造成重复下单、重复创建数据所以在框架里我通常只给 GET 和幂等请求重试其他请求失败直接抛异常。7.2 requests 连接池与并发请求报错另一个高频问题是并发量一上来控制台报 “connection pool is full, discarding connection” 或者奇怪的连接断开报错。这是 requests 底层连接池的默认限制导致的。requests 用的是 urllib3 的 PoolManager默认连接池只能容纳固定数量的连接。解决方式是在创建 session 时给 HTTPAdapter 增大连接池容量adapter HTTPAdapter( pool_connections20, # 缓存连接数 pool_maxsize20 # 每个 host 最大连接池大小 ) session.mount(https://, adapter) session.mount(http://, adapter)这个配置开了之后并发场景的稳定性会上来很多。另外还有一种“too many concurrent requests”报错通常是框架内部用了多线程并发请求但线程数没控制导致连接池被打满。测试框架里没有绝对必要并发就别并发接口自动化讲究稳定优先少一个并发就少一类环境问题。7.3 用例执行顺序与依赖问题接口测试中经常有“先创建订单再支付再查询”的顺序依赖。pytest 默认按文件内定义顺序执行但跨文件之间不保证顺序。很多人第一反应是给所有用例排一个全局顺序这种做法维护成本极高加一个用例就要重排一遍。我推荐的做法是不要依赖“执行顺序”而是把依赖数据通过 fixture 显式传递。比如支付接口需要 order_id就在 fixture 里创建订单并返回 id支付用例直接拿这个 id 执行case 之间不存在隐式顺序问题。如果真的要测一条完整业务链路那就把整条链路写成一个用例函数用中间变量串联而不是拆成多个互相依赖的测试函数。如果你确实需要控制顺序可以用 pytest-ordering 插件标记 pytest.mark.run(order1)但这更适合冒烟环境里有明确先后依赖的少量用例不适合作为全项目的编码习惯。7.4 IDE 里跑 pytest 各种不生效最后一个很常见的问题是“代码在命令行跑没问题但在 IDE 里一跑就报错”。绝大多数字面原因不是代码问题而是 IDE 用的 Python 解释器不是装 pytest 的那个。PyCharm 里如果提示 pytest 未找到检查 File - Settings - Project - Python Interpreter 是否选中了 venv 路径。VSCode 里则是右下角解释器选择错误配合前面说的 “Python: Select Interpreter” 重新选一次。这个问题我见过太多了每次都能看到“新同学折腾一上午环境最后发现只是解释器选错位”。另外 Windows 下如果直接在终端敲 pytest 显示不是内部或外部命令通常是 scripts 目录没加到 PATH解决办法是使用 python -m pytest 执行这样不管你 PATH 怎么配只要 Python 本身能用pytest 就能跑起来。最后聊点框架之外的东西。我维护这套框架时间越长越觉得选型不是重点稳定性和可维护性才是重点。实际跑接口自动化最大的敌人往往不是断言逻辑而是测试环境不稳定、数据互相污染、限流超时这些看似很小的事。所以我的建议是先跑通一个最小闭环比如登录接口的 10 条用例再逐步加日志、加报告、加 CI、加数据驱动。与其一开始就设计一个特别宏大的框架不如让它长在真实业务上遇到问题再针对性完善。如果这篇文章能让你把第一版快速搭起来那我在这里写的这些细节就值了。