做接口自动化测试这几年我踩过不少坑也看过很多团队从 Postman 手动点点到 unittest 脚本堆砌最后无一例外都走向了同一个答案Python pytest requests这套组合。不是说它有多花哨而是它足够工程化——pytest 负责用例组织、断言、夹具和报告requests 负责发 HTTP 请求两者一拼再加上数据驱动和环境管理基本就是中小团队能落地的接口自动化测试框架完整形态。这篇文章我会从一个可复现的角度把这套框架从目录结构、核心封装、数据驱动到限流重试、测试报告完整拆开讲一遍。如果你是刚接触接口自动化或者正在从手工测试往自动化转按这个思路搭起来至少能省两周的弯路。1. 先把结构搭明白为什么偏偏是 pytest requests1.1 这个组合解决了什么问题接口自动化测试本质上就三件事发起请求、校验结果、组织报告。看起来简单但真做起来会撞上很多现实问题用例多了怎么分类、接口依赖怎么处理、不同环境怎么切换、数据怎么维护、失败了怎么定位、报告怎么给团队看。pytest requests之所以能成为主流就是因为这两个库各自把问题解决了一半。requests 是 Python 里最成熟的 HTTP 客户端库API 设计非常人性化。requests.get(url)、requests.post(url, jsondata)这类写法几乎不用查文档就能上手。它把连接池、SSL 校验、代理、超时、会话保持这些底层细节全部封装好了我们只需要关心业务参数。pytest 解决的则是“框架”层面的问题。它有一个非常灵活的夹具机制fixture可以用pytest.fixture把登录获取 token、初始化测试数据、清理脏数据这些“前置动作”抽出来复用它的参数化pytest.mark.parametrize天然适合数据驱动它的插件生态pytest-html、pytest-rerunfailures、pytest-ordering几乎覆盖了测试报告、失败重试、执行顺序这些刚需。这两个库配合起来的直接效果是写测试用例的人只需要关心“接口怎么调、期望是什么”而不需要关心“测试平台怎么写、报告怎么生成、依赖怎么管理”。这就是框架的意义——把复杂度收走把重复度降到最低。1.2 技术选型对比为什么不用 unittest、Robot Framework很多初学者会问Python 内置了 unittest为什么还要额外装 pytest这个问题我当年也纠结过后来在团队里做了几次对比结论非常明确。unittest 是 Python 自带的标准库稳定但偏“重”。它要求测试类必须继承unittest.TestCase断言方式是自己那套assertEqual、assertTrue用例必须写在类里面启动方式用unittest.main()。写几个用例没问题但一旦到了几百上百个用例你就会发现这套 API 有点笨重参数化要自己写、夹具要自己造、报告要自己拼。pytest 则完全不同。它的用例可以是普通函数断言直接用 Python 原生的assert关键字支持类但不强制用类层层推进的项目里可以灵活混用。pytest 的夹具通过参数自动注入比 setUp/tearDown 那种“函数名约定”要直观得多。最关键是 pytest 的插件生态和社区活跃度unittest 拍马也赶不上。至于 Robot Framework它主打关键字驱动学习曲线在“写关键字”而不是“写 Python”。对于业务人员友好但一旦遇到复杂断言、复杂数据处理还是得回到 Python 本身。我觉得它更适合偏业务验收的团队而对纯技术型的测试开发来说pytest 更轻、更灵活、更容易和 CI/CD 集成。1.3 框架目录设计与分层思想框架好不好用目录结构直接决定了一半。我见过很多人把几十个接口的测试代码全部塞进两三个文件里跑是能跑但维护起来像在玩扫雷。这里给出一个经过多次项目验证的推荐结构api_test_framework/ ├── common/ # 公共模块 │ ├── __init__.py │ ├── base_request.py # requests 基础封装 │ ├── assert_utils.py # 断言封装 │ ├── log_utils.py # 日志封装 │ ├── read_data.py # 数据文件读取 │ └── env_config.py # 环境配置读取 ├── config/ # 配置文件 │ ├── __init__.py │ ├── dev.yaml # 开发环境配置 │ ├── test.yaml # 测试环境配置 │ └── prod.yaml # 生产环境配置谨慎使用 ├── data/ # 测试数据 │ ├── login_test.json │ └── user_test.json ├── testcases/ # 测试用例 │ ├── __init__.py │ ├── conftest.py # 当前目录 fixtures │ ├── test_login.py │ └── test_user.py ├── reports/ # 报告输出 ├── logs/ # 日志输出 ├── requirements.txt ├── pytest.ini ├── conftest.py # 全局 fixtures └── run.py # 一键执行入口这套结构的核心思想是三层分离common负责底层能力config管环境差异testcases只写业务用例。同一个接口要测 20 条数据用例文件里只需要 20 行参数化用例没必要重复写请求逻辑。谁负责哪一块边界一眼就能看清楚。2. 环境准备与基础配置别在第一步翻车2.1 Python 版本与虚拟环境我建议使用 Python 3.8 以上的版本。原因很简单pytest 新版本和 requests 的新版本都在持续提升对 Python 3.8 的支持3.6 及以下的版本已经逐渐被各种依赖库抛弃比如pyyaml的高版本就要求 Python 3.8。如果你所在公司还在用老版本 Python至少保证 3.7 以上否则后面装依赖会有很多莫名奇妙的报错。项目级别的依赖隔离是必须的。千万别把这套框架直接装进系统 Python否则项目换个依赖版本系统里其他脚本可能就崩了。常规做法是给项目建独立的虚拟环境python -m venv venvWindows 激活命令venv\Scripts\activatemacOS / Linux 激活命令source venv/bin/activate激活后可以看到命令行前面多了(venv)前缀这时候pip安装的所有包都只会进入当前项目环境。团队新成员拿到项目第一件事就是创建虚拟环境、安装依赖而不是自己茫茫然去全局装包。2.2 requirements.txt 与依赖安装常见坑依赖管理直接用requirements.txt把关键包写清楚并锁定主版本号pytest8.2.0 requests2.32.3 PyYAML6.0.1 pytest-html4.1.0 pytest-rerunfailures14.0 pytest-ordering0.6 allure-pytest2.13.5安装直接用pip install -r requirements.txt这里有个经验之谈不要贪图方便用pip install pytest requests一把梭然后pip freeze requirements.txt。pip freeze会把当前环境里所有间接依赖都锁进去文件又长又乱而且不同系统间的兼容锁可能互相冲突。更稳妥的做法是手动维护顶层依赖列表每个包写清用途和主版本范围。另一个常见的坑是安装pytest-rerunfailures时版本不兼容。这个插件对 pytest 版本的匹配比较敏感如果装完后 pytest 直接启动报错多半是版本对不上解决方案是查看插件的官方文档找到与你 pytest 版本匹配的插件版本。2.3 pytest.ini 配置项逐行解读pytest 的配置可以放在pytest.ini、pyproject.toml或者setup.cfg里。我用得最多的是pytest.ini简单直接不会被现代工具链的其他配置干扰。一个典型的配置如下[pytest] testpaths testcases python_files test_*.py python_classes Test* python_functions test_* addopts -v -s --htmlreports/report.html --self-contained-html markers smoke: 冒烟测试 p0: 核心用例 p1: 重要用例testpaths指定了用例搜索目录python_files指定了哪些文件会被识别为测试文件python_functions指定了哪些函数会被认为是测试用例。这三个配置限定了搜索范围避免 pytest 一堆没用的脚本也扫进去重复收集。addopts是每次执行默认追加的命令行参数。-v是详细输出-s是关闭 stdout 捕获这样代码里的print可以直接打到控制台调试时非常有用。--html指定报告输出路径--self-contained-html会把 CSS/JS 都内嵌到 HTML 文件里发邮件或上传文件时一个文件就够不会出现样式丢失问题。markers定义的是用例标记。写完标记后执行时可以按标记筛选用例比如跑冒烟用例就只需要加-m smoke参数。需要注意不在markers里先声明就使用pytest.mark.smokepytest 会给出 PytestUnknownMarkWarning 警告所以提前声明是常规操作。2.4 conftest.py 的全局能力fixture 与钩子函数conftest.py是 pytest 里的“魔法文件”它可以在不用 import 的情况下把自己的 fixture、插件、钩子函数自动应用到同级及以下目录的所有测试文件。我一般会在项目根目录放一个全局conftest.py处理所有用例通用的夹具比如环境选择、会话创建、全局日志初始化。一个最简单的全局 fixture 示例import pytest import requests from common.base_request import BaseRequest pytest.fixture(scopesession) def session(): 全局会话夹具整个测试过程只创建一次 s requests.Session() yield s s.close() pytest.fixture(scopesession) def base_url(envtest): 根据环境参数返回基准地址 from common.env_config import get_env_config return get_env_config(env).get(base_url)scopesession代表整个测试会话只执行一次对于 token 复用、连接复用这类场景特别有用。注意 fixture 里用yield而不是returnyield前后的代码分别代表“前置动作”和“后置清理”这种写法在测试结束时可以自动完成资源释放。conftest.py 里还可以定义命令行选项。比如我想在跑用例时用--envtest指定环境就可以在conftest.py里写pytest_addoption钩子def pytest_addoption(parser): parser.addoption(--env, actionstore, defaulttest, helpchoose env: dev / test / prod) pytest.fixture(scopesession) def env(request): return request.config.getoption(--env)这样执行pytest --envdev testcases/test_login.py时框架就会自动切到开发环境的地址。多环境切换的核心问题就这么解决了后面会单独展开讲。3. 核心封装请求层、配置层与数据驱动3.1 用 Session 封装底层请求而不是裸用 requests很多新手写接口测试喜欢直接requests.get()、requests.post()每次调用都独立发请求。短时间看没问题但一旦接口多起来你会发现自己重复写 URL 拼接、超时设置、请求头拼接而且完全没有连接复用性能很差。我的做法是封装一个BaseRequest类内部使用requests.Session()。Session 在同一个实例里可以保持 Cookies自动复用底层 TCP 连接还能统一设置 headers。代码如下import requests import time from common.log_utils import get_logger from common.env_config import get_env_config logger get_logger(__name__) class BaseRequest: def __init__(self, base_url, headersNone): self.session requests.Session() self.base_url base_url if headers: self.session.headers.update(headers) def request(self, method, url, retry2, **kwargs): full_url self.base_url url logger.info(f请求地址: {full_url}) logger.info(f请求方法: {method}) logger.info(f请求参数: {kwargs}) for attempt in range(retry 1): try: resp self.session.request(method, full_url, **kwargs) logger.info(f状态码: {resp.status_code}) logger.info(f响应内容: {resp.text}) return resp except requests.RequestException as e: logger.warning(f第 {attempt 1} 次请求失败: {e}) if attempt retry: time.sleep(1) else: raise e def get(self, url, **kwargs): return self.request(GET, url, **kwargs) def post(self, url, **kwargs): return self.request(POST, url, **kwargs) def put(self, url, **kwargs): return self.request(PUT, url, **kwargs)这层封装有几个关键点。第一所有请求日志统一记录路径、方法、参数、状态码、响应内容都打出来后面排查问题能省一半时间。第二内置了简易重试机制网络抖动时自动重试两次再抛异常。第三统一拼接 URL业务层不用再写完整的https://xxx/api/login只传路径即可。关于重试这里多说几句。requests 本身有适配器层面的重试机制我还会在后面讲 HTTPAdapter 的用法但封装层的重试属于更精细的一层它是在业务逻辑层掌控的重试可以针对特定异常、特定状态码定制策略两者并不冲突。3.2 业务接口层封装登录、用户模块怎么写有了BaseRequest之后我们还需要再往上走一层把业务接口封装成类每个接口一个方法。为什么要这么做因为接口自动化要应对的不只是单个接口还有接口之间的调用关系。比如查询用户列表前可能需要先登录拿 token这个前置逻辑如果散落各个用例文件里后面改一处要全局找。一个典型的业务封装长这样from common.base_request import BaseRequest class UserApi(BaseRequest): def __init__(self, base_url, tokenNone): headers {Authorization: fBearer {token}} if token else {} super().__init__(base_url, headers) def login(self, username, password): payload {username: username, password: password} return self.post(/api/login, jsonpayload) def get_user_info(self, user_id): return self.get(f/api/user/{user_id}) def update_user(self, user_id, data): return self.put(f/api/user/{user_id}, jsondata) def create_user(self, data): return self.post(/api/user, jsondata)在这个类里接口路径、请求头、请求体都是私有细节用例层只关心“调用一个函数得到响应对象”。后面接口的 URL 变了只改一个地方鉴权逻辑变了只改构造方法。这其实就是最朴素的“分层”思想用例层永远不要直接操作 requests否则项目越大越失控。3.3 多环境切换YAML 配置与应用多环境切换是接口自动化绕不开的需求因为开发环境、测试环境、预发布环境的 base_url、账号、密钥大概率都不一样。用 YAML 做配置管理是最成熟的方案。打个比方config/dev.yamlbase_url: http://127.0.0.1:8000 accounts: admin: username: admin password: 123456 normal: username: user01 password: abc123 timeout: 10config/test.yaml同理只是base_url换成测试环境的地址。读取配置的封装如下import os import yaml _CONFIG_DIR os.path.join(os.path.dirname(os.path.dirname(__file__)), config) def get_env_config(env): file_path os.path.join(_CONFIG_DIR, f{env}.yaml) with open(file_path, r, encodingutf-8) as f: return yaml.safe_load(f)这样任何测试类都可以通过一行代码拿到当前环境的配置config get_env_config(test) base_url config[base_url]环境切换的本质就是把“环境相关”的东西从代码里剥离出去。只要代码里没有硬编码的 IP 地址和账号密码环境切换就是一个参数的问题。如果哪天上线的 CI 环境需要新加一个环境只需要在 config 目录里加一个 YAML不需要改动任何测试代码。3.4 数据驱动设计parametrize JSON 用例源数据驱动是接口自动化框架的“高级感”来源。同一个登录接口可能要测正确密码、错误密码、空用户名、特殊字符、超长字符串等十几种数据组合。如果每种组合写一个用例函数代码冗余会让人崩溃。pytest 的解决方案是pytest.mark.parametrize。它本身就是字符串元组列表驱动的可以组合出很多玩法。比如把测试数据放到外部的 JSON 文件里用读取函数加参数化器加载import json import pytest from common.base_request import BaseRequest from common.env_config import get_env_config def load_login_data(): with open(data/login_test.json, r, encodingutf-8) as f: return json.load(f)[cases] pytest.mark.parametrize(case, load_login_data(), idslambda c: c[title]) def test_login(case, base_url): api BaseRequest(base_url) resp api.post(/api/login, jsoncase[payload]) assert resp.status_code case[expected_status] if case.get(expected_msg): assert case[expected_msg] in resp.textlogin_test.json文件内容{ cases: [ { title: 正确账号密码登录, payload: {username: admin, password: 123456}, expected_status: 200, expected_msg: success }, { title: 错误密码登录, payload: {username: admin, password: wrong}, expected_status: 401, expected_msg: invalid credentials } ] }这里有个细节值得学习参数化用例的名字默认是一堆元组看不出场景。通过ids参数指定一个“取标题”的函数pytest 运行时每条用例就会显示成test_login[正确账号密码登录]这种可读性极高的名字报告里一眼能看出哪条数据挂了。4. 断言、日志与测试报告让失败看得见4.1 自定义断言把失败信息写到人话测试用例跑挂了不可怕可怕的是挂得莫名其妙。比如assert 200 500这种失败信息除了知道状态码不对什么都看不出来。我强烈建议封装一层断言工具函数把失败信息写得具体、可读。def assert_status_code(actual, expected): assert actual expected, ( f状态码校验失败: 期望 {expected}, 实际 {actual} ) def assert_in_text(text, content): assert content in text, ( f响应内容校验失败: 期望包含内容 {content}, f实际响应为 {text[:500]} )还有更复杂的 JSON Schema 断言和字段值断言都可以封进assert_utils.py。封装的目的不只是减少重复代码更是给所有断言统一“形象”——团队所有人看到的失败信息都是同样清晰、同样格式化的而不是每个人写的 assert 信息五花八门排查问题还得猜格式。有个重要的原则不要在用例里写大量裸的assert xxx yyy。裸断言在 pytest 下的失败信息其实已经很好了会显示左右两个值的 diff但它是“面向代码”的不是“面向业务”的。比如登录接口返回的 token 失效了裸断言只会告诉你None ! abc而封装后的断言可以明确告诉你“登录失败token为None请检查账号密码配置”。这两者的排查效率天差地别。4.2 日志体系requests 请求日志与 pytest 日志集成日志在接口自动化里特别容易被忽略但真正排查问题的时候日志就是救命稻草。我的习惯是所有请求和响应都必须打日志而且要用规范的时间格式、级别和模块名方便通过日志检索。log_utils.py的基础封装import logging import os from logging.handlers import RotatingFileHandler def get_logger(name, log_filelogs/run.log): logger logging.getLogger(name) logger.setLevel(logging.INFO) if not logger.handlers: file_handler RotatingFileHandler( log_file, maxBytes5 * 1024 * 1024, backupCount3 ) stream_handler logging.StreamHandler() formatter logging.Formatter( %(asctime)s - %(name)s - %(levelname)s - %(message)s ) file_handler.setFormatter(formatter) stream_handler.setFormatter(formatter) logger.addHandler(file_handler) logger.addHandler(stream_handler) return logger用RotatingFileHandler的好处是日志文件能自动切割单个文件达到设定大小就备份不会无限膨胀。pytest 本身的日志也可以和这个体系融合。在pytest.ini里加上日志配置pytest 的断言信息就能直接打进日志文件log_cli true log_cli_level INFO log_file logs/pytest.log log_file_level INFO log_file_format %(asctime)s %(levelname)s %(message)s log_file_date_format %Y-%m-%d %H:%M:%S这样跑完测试后logs/目录下既有请求日志又有 pytest 运行日志排查问题或者复盘失败原因都有了原始依据。4.3 测试报告pytest-html 与 Allure 的取舍测试报告是自动化框架对外展示的窗口。团队内部用pytest-html就够如果公司整体没有专门的测试平台又想让报告更专业Allure 是更好的选择。pytest-html 的优势是轻量一条命令就能生成pytest --htmlreports/report.html --self-contained-html它天然支持失败截图对接口测试意义不大、摘要信息、命令行参数记录基本满足“给团队看结果”的需求。它的样式是固定的定制能力有限也没有历史趋势追踪。Allure 则更强大生态也成熟。先生成测试结果数据再渲染报告pytest --alluredirreports/allure_results allure generate reports/allure_results -o reports/allure_report --cleanAllure 的优势有三个一是每个用例的步骤、参数、附件、关联链接都可以结构化展示二是历史执行记录能形成趋势图方便观测稳定性三是有环境信息、缺陷类别这些专业测试报告元素。代价是部署环境需要额外安装 allure 命令行工具CI 环境也要多配一步。我的建议是团队刚起步用 pytest-html跑一段稳定了再迁到 Allure 补上趋势分析和缺陷关联。4.4 失败重试与 429 限流场景处理自动化测试跑在测试环境最怕的不是业务 bug而是环境不稳定、网络抖动和接口限流。尤其很多后端服务会对单 IP 的并发请求做限流测试脚本跑得太快很容易撞上 429 Too Many Requests。requests 适配器提供了优雅的解决方案from requests.adapters import HTTPAdapter from urllib3.util.retry import Retry def create_session_with_retry( retry_total3, backoff_factor0.5, status_forcelist(429, 500, 502, 503, 504), ): session requests.Session() retry Retry( totalretry_total, backoff_factorbackoff_factor, status_forceliststatus_forcelist, allowed_methods[GET, POST, PUT, DELETE], raise_on_statusFalse, ) adapter HTTPAdapter(max_retriesretry) session.mount(http://, adapter) session.mount(https://, adapter) return session这里backoff_factor是退避系数urllib3 的退避时间按{backoff_factor} * (2 ** (retry_number - 1))计算第一次重试等 0.5 秒第二次等 1 秒第三次等 2 秒呈指数增长。这样遇到 429 限流时不会“冷启动猛冲”而是给服务端喘息时间。除了请求层重试pytest 层面也可以做用例级重试用pytest-rerunfailurespytest --reruns 2 --reruns-delay 3这两个机制各有适用场景。适配器重试解决“单次请求失败后立刻重发”的瞬时问题pytest 用例级重试解决“用例失败后重新跑一遍”的整体问题。注意组合使用时预期要设好如果一个接口连续多次重试都失败那就说明是真 bug不是环境抖动。5. 实战案例登录鉴权、token 管理与问题排查实录5.1 登录获取 token并在后续请求中自动携带现在很多后端系统采用的是 JWT 鉴权调用业务接口前必须在请求头里带Authorization: Bearer token。如果每个用例都自己登录一次既慢又容易触发限流。正确做法是只登录一次通过 fixture 把 token 自动注入到后续用例。fixture 方案我比较推荐用 session 级 fixture把登录和 token 管理放在conftest.py里import pytest from common.base_request import BaseRequest from common.env_config import get_env_config pytest.fixture(scopesession) def admin_token(base_url): api BaseRequest(base_url) resp api.post(/api/login, json{ username: admin, password: 123456 }) resp_json resp.json() assert resp.status_code 200, f登录失败: {resp.text} return resp_json[data][token] pytest.fixture(scopesession) def user_api(base_url, admin_token): from api.user_api import UserApi return UserApi(base_url, tokenadmin_token)这样任何测试函数只需要在参数列表里声明user_apipytest 就会自动触发登录流程拿到 token 后创建带鉴权的 API 对象。测试函数内部只需要调用user_api.get_user_info(1)完全不需要关心 token 是怎么来的、什么时候失效。需要注意token 有效期短于整个测试套件时长时session 级 fixture 就会出问题——后跑的用例可能拿着过期 token 请求返回 401。这种情况我的经验是写一个“token 自动刷新”的封装在 BaseRequest 内部监听 401 响应发现过期就自动重新登录然后重放原请求。代码会复杂一些但它的稳定性和易用性是巨大的提升。5.2 用例依赖与执行顺序不要迷信“从上到下”接口测试最容易踩的坑就是把用例写成“有状态”的——前一条用例创建了用户后一条用例依赖这个用户去查询、更新。pytest 默认的执行顺序是按照文件名字母序和函数定义顺序来的但它并不保证你依赖的先执行。如果确实存在依赖关系我建议用pytest-ordering插件显式控制顺序import pytest pytest.mark.run(order1) def test_create_user(user_api): resp user_api.create_user({name: zhangsan}) assert resp.status_code 201 return resp.json()[data][id] pytest.mark.run(order2) def test_get_created_user(user_api): user_id test_create_user.return_value # 不推荐仅示意但上面这种写法能不用就别用。关卡依赖会让一个用例的失败传导到后面所有用例导致排查问题时满屏红很难定位根因。更好的方案是用 fixture 的yield做“创建即清理”。业务接口创建数据的前置动作放到 fixture 里测试结束时自动删除或下线这些数据。用独立的造数脚本/接口来准备测试数据把“数据准备”从用例中剥离出来。查询类用例尽量使用当前环境的固定数据不要依赖“被前一个用例改过的数据”。接口自动化的目的是稳定高效地发现回归问题不是追求用例之间的“剧情连续”。我见过太多团队因为用例强依赖导致每次跑自动化都像开彩票这种框架跑起来比不跑更让人心累。5.3 常见问题速查表接口自动化框架跑起来之后最常遇到的问题大体可以归为下面几类我整理成一个速查表问题现象可能原因排查方向所有请求报 ConnectionError网络不通 / 代理拦截 / 服务未启动先用 curl 或 Postman 单独验证接口请求正常但响应和预期不符环境连错 / 测试数据被污染检查当前 base_url检查数据初始化时间返回 401 Unauthorizedtoken 过期 / 请求头未带 token看 logs 中的请求头确认 Authorization 字段返回 429 Too Many Requests请求频率过高触发限流使用重试 退避策略降低并发或增加 sleep多个用例同时失败公共 fixture 出错单独跑一个用例看是否 fixture 初始化失败JSON 解析报错响应不是合法 JSON打印响应原文服务端可能返回了 HTML 错误页并发执行时数据互相覆盖用了相同的测试账号按用例 ID 或随机数区分测试数据这张表也是我实际工作中最常使用的三张表之一另外两张一张是“环境配置对照表”一张是“接口权限矩阵”。团队刚接手一个项目的自动化时先把这三张表整理出来比盲目写用例要有用得多。5.4 框架还能往哪走CI 集成与持续优化方向当本地跑稳定后下一步自然是把它接到 CI 平台里。以最常见的方案为例代码仓库用 GitLabCI 工具用 GitLab CI 或者 Jenkins触发时机是定时任务或代码提交后自动执行。GitLab CI 的流水线配置可以是这样stages: - test api-test: stage: test script: - python -m venv venv - source venv/bin/activate - pip install -r requirements.txt - pytest testcases --env$TEST_ENV --htmlreports/report.html --self-contained-html artifacts: paths: - reports/ expire_in: 7 days only: - schedules - main定时跑可以设置成每天凌晨自动跑一遍全量用例早上团队上班前邮件或企微通知推送结果。这样任何后端改动导致接口回归团队在几小时内就能发现而不是等业务人员用的时候才爆雷。框架的持续优化方向我建议按这几个优先级推进把请求和断言封装得更细让用例层越来越像“业务描述”而不是“代码实现”。把测试数据从“硬编码在用例里”逐步迁移到“通过造数接口或数据库初始化”实现真正的数据隔离。引入 Allure 报告和 CI 产物归档把测试结果沉淀为团队的质量数据而不只是一次性的运行记录。对耗时长的接口做性能基线记录虽然这不是功能测试框架的本职但顺手记录响应时间对发现环境劣化很有帮助。这套框架我用了几年最大的体会是pytest requests 本身不难难的是一开始就规划好分层边界不让接口测试退化成一堆 requests 脚本的堆砌。很多团队把框架做得越来越大各种平台、各种分布式执行、各种平台集成结果真正落地的时候反而被复杂度拖垮。我的建议很朴素先跑通一条业务链路再逐步往里加东西。每加一个能力先问自己“它是不是真的能降低维护成本”。接口自动化的核心目标从来不是代码量多好看而是让团队对回归有底气。这一点pytest requests 这套组合完全够用关键看你怎么组织。