★ FEATURED ARTICLE 简介这是一份基于 pythonpytestyamlddtallure 技术栈的接口自动化测试框架源代码主要面向需要开展接口测试与自动化转型的测试工程师。框架源自码尚 VIP 课程学习成果经公司实际项目改造升级后实测可用使用者只需录入自己项目的接口用例数据即可快速运行既适合企业内部测试提效也适合作为自学进阶的落地参考。压缩包内含 126 个文件类型涵盖 Python 脚本、YAML 用例配置、JSON 数据文件以及 allure 报告所需的 JS/CSS/HTML 等静态资源可支撑数据驱动执行、用例管理与测试报告输出另附接口自动化测试 yaml 用例规范文档便于团队统一编写格式。资源包整体约 1.02MB轻量、易部署。目前已有 4341 人学习下载。借助这套框架读者可以深入理解 pytest 收集机制、ddt 数据驱动思路与 allure 报告集成方式同时借鉴来自真实项目的目录结构与排错经验显著降低从零搭建接口自动化框架的时间成本。框架内还包含实用的用例模板、配置示例与目录组织方式allure 报告模块已按项目实践调通可直观呈现执行结果与失败原因便于团队协作排查问题。1. 为什么是 python pytest yaml ddt allure接口自动化的一个务实组合接手某公司的接口回归任务时我落地的框架就是标题里这套python 写逻辑pytest 管用例收集与夹具yaml 存接口数据ddt 做数据驱动allure 出报告。当时的现场很典型几百个接口靠人对着 Postman 手动点一轮回归要一整天还不敢保证每个参数都覆盖到。这套组合解决的问题很具体——写用例的人不用碰代码改接口的人不用翻代码报告里能直接定位是参数问题还是服务问题。如果你正要搭接口自动化框架或者现在用的是 unittest 加一堆 if-else 拼出来的脚本这篇能帮你少走一段弯路。2. 先把框架分层想清楚pytest 钩子、yaml 数据边界和目录结构标题里的几个组件不是硬拼在一起的它们各自负责一个层级pytest 管执行和夹具yaml 管测试数据ddt 或参数化管数据展开allure 管结果展示。我接到需求后的第一个动作不是写用例而是先把分层和目录定死。框架不分层用例超过五十条就会变成黑匣子改一条数据牵扯一堆代码加一个接口要复制粘贴两个文件最后没人敢动这个框架。2.1 pytest 的 fixture 与钩子函数比 unittest 强在哪接口自动化里 pytest 相对 unittest 的核心优势有三个fixture 的作用域复用、参数化机制、钩子函数。unittest 的套路是 setUp/tearDown 在每个测试方法前后执行跨用例共享的初始化比如登录 token得自己写类变量或者模块级缓存代码像拼积木。pytest 的 fixture 通过 scope 声明生命周期一次 session 级的登录 fixture 能被整个项目共享fixture 里 return 任意对象用例直接当参数接收。fixture 的 scope 是第一个要理解透的参数。我把常用作用域整理成了一张表给团队新来的测试同事看scope执行时机适合放什么sessionpytest 进程启动后只执行一次登录 token、全局配置、requests.Sessionclass每个测试类执行前一次类级别共享的数据比如一批测试账号function每条测试用例执行前一次独立参数、临时数据、mock 开关不要一上来什么都用 sessionsession 级 fixture 一旦内部出错影响的是整个进程的所有用例。我一般只在确定这个对象可以全局复用时才升到 session比如 token 和连接池其他一律 function 级保证用例之间的隔离性。fixture 还有个容易被忽略的功能yield 之后的部分会在作用域结束时执行相当于自带清理逻辑。比如建了一个临时订单用例跑完自动发起删除请求不用写 tearDown 也不怕用例中途抛异常导致清理逻辑被跳过。这在接口自动化里非常实用因为造数据是常态清数据往往被忘掉。再往下的钩子函数是 pytest 比 unittest 高级的地方。pytest_collection_modifyitems 可以在收集阶段按你的规则调整用例顺序pytest_addoption 可以加命令行参数比如 --env 切换环境pytest_runtest_makereport 能在每条用例结束后拿到 pass/fail 结果失败时补附件。这三个钩子分别对应第 4 章的报告快照和第 5 章的环境切换。unittest 要做同样的事只能改框架源码pytest 只要在 conftest.py 里写同名函数。最后是参数化。unittest 的 subTest 在报告里看不出第几条数据挂了而且断言失败后还会继续跑后面的数据掩盖连锁问题pytest.mark.parametrize 把每条数据展开成独立用例失败一条不影响其他报告里还能用 ids 显示中文标题。这一块的完整写法在第 3 章。2.2 yaml 存什么、代码里写什么数据驱动的边界数据驱动这个词被很多文章讲虚了落地时最常见的误区是把所有东西都塞进 yaml。我见过一个项目把断言用的 Python 表达式也写进 yaml最后数据文件里全是 eval比代码还难读。我的边界划分很简单yaml 只放跟业务相关、测试人员需要维护的东西接口路径、请求方法、headers、params、body、预期状态码、预期关键字段代码里放跟逻辑相关、需要调试的东西请求发送封装、接口鉴权、断言方法、日志、重试。判断标准是换一个新来的测试同学她打开 yaml 能不能直接改一条用例换一个接口类型打开代码能不能只做小改动就适配。如果两边模糊比如 yaml 里出现了 base_url、token、环境变量的占位那就是放错位置了。base_url 属于环境配置token 属于运行期数据都不该写进用例数据文件。另外一个边界是数据文件的生命周期。登录、下单这类单接口用例用 yaml 数据驱动没问题跨接口的流程用例先登录拿 token、带 token 下单、再查订单天然是代码里的 fixture 或步骤。硬拆进 yaml 会变成伪数据驱动yaml 里写一行注释表示 token 需先登录获取执行逻辑全在代码里这种拆法维护成本反而更高。2.3 一版可扩展的目录结构从 config 到 report按上面的边界我一般会搭这样一版目录api_test/ ├── config/ │ ├── __init__.py │ └── settings.py # 环境配置聚合读取 env.yaml ├── data/ │ ├── __init__.py │ └── login.yaml # 每个业务模块一个 yaml 数据文件 ├── common/ │ ├── __init__.py │ ├── read_yaml.py # yaml 读取封装 │ ├── request.py # requests.Session 封装与 token 管理 │ ├── assert_util.py # 断言工具 │ └── log.py # 日志配置 ├── testcases/ │ ├── __init__.py │ ├── conftest.py # 全局 fixture 和钩子函数 │ ├── test_login.py │ └── test_order.py ├── report/ │ ├── results/ # allure 原始结果目录 │ └── html/ # allure 生成的 HTML 报告 ├── requirements.txt └── pytest.ini几个关键约定。config/settings.py 只聚合环境配置不写任何测试数据data 和 testcases 平级因为同一份登录数据可能被登录模块和全流程模块同时引用common 里的代码禁止 import testcases 下的任何东西否则会出现循环依赖改一个文件带崩一片report 目录进 .gitignoreresults 和 html 每次执行重生成。testcases/conftest.py 是整个项目的核心配置点session 级 token fixture、allure 失败快照钩子、环境参数注册都放这里。以后团队扩大可以在 testcases 下按业务建子目录每个子目录再放自己的 conftest.pypytest 会从项目根逐级加载 fixture子目录的同名 fixture 可以覆盖全局逻辑不会互相污染。这个目录不是标准答案它是经过几个项目验证的底线数据、逻辑、报告三层分离新人进来基本不用问太多就能找到要改的文件。后面所有代码都按这个结构组织。3. 从零跑通最小框架yaml 读取、ddt 数据驱动和断言日志封装分层定好之后就可以动手了。这一章的目标很明确装好依赖写一个读取 yaml 的工具写一组数据驱动用例把断言和日志做成公共能力。跑通这一版框架的骨架就立住了。3.1 依赖安装与 pytest.ini版本别乱装先用一份 requirements.txt 固定依赖。以下是我在一套 Python 3.11 环境里验证过的组合版本号仅供参考按你实际环境的稳定版本锁定pytest7.0 allure-pytest2.13 PyYAML6.0 requests2.31 ddt1.6 pytest-rerunfailures11.0安装阶段有一个非常典型的翻车点allure-pytest 和 pytest-allure-adaptor 是两个完全不同的包。后者是很多年前针对 pytest 2.x 写的插件早就停止维护装上之后 pytest 启动直接报插件冲突。认准 allure-pytest 这个包名。ddt 这个库本身没有复杂依赖但它不是 pytest 项目的必需品装它只有一种情况团队里有历史遗留的 unittest 风格测试类不想重写。选型细节在 3.3 节展开。pip install -r requirements.txt项目根目录放 pytest.ini这是 pytest 的配置入口[pytest] testpaths testcases addopts -v -s --alluredirreport/results --clean-allurediraddopts 里的 --alluredir 指定 allure 原始结果的输出目录--clean-alluredir 在每次执行前清空旧结果避免上一次失败运行残留的半截 JSON 混进新报告。testpaths 限定 pytest 只收集 testcases 目录否则 common 下的工具函数也可能被当成测试收集进去。注意-v 在用例数少于 300 条时建议保留接口用例的报错信息在终端里多打几行远比只看进度点有用用例量上来之后再换 -q 配合报告定位。3.2 封装 yaml 读取层safe_load 与编码的两个细节data 目录的读取逻辑放在 common/read_yaml.py全项目只有这一个文件允许直接操作 yamlfrom pathlib import Path import yaml # 项目根目录common 的上一级 BASE_DIR Path(__file__).parent.parent def load_yaml(path: str): 读取 data 目录下的 yaml 文件返回 Python 对象 path 是相对于项目根目录的路径例如 data/login.yaml file_path BASE_DIR / path with open(file_path, r, encodingutf-8) as f: return yaml.safe_load(f)两个细节值得说透。第一是必须用 yaml.safe_load 而不是 yaml.load。yaml.load 在没有显式 Loader 参数时会用全功能 Loader允许反序列化任意 Python 对象数据文件一旦出现意外标签就是隐患。safe_load 只反序列化基本类型对测试数据完全够用。第二是 open 时固定 encodingutf-8不加这个参数Windows 平台上会按系统默认编码GBK去读含中文的 yaml 文件直接报 UnicodeDecodeError。这是国内团队搭这套框架时最常遇到的第一个报错。读取时机也要清楚上面的代码在模块 import 阶段执行也就是 pytest 收集用例时就完成了 yaml 解析。好处是数据文件语法错误能尽早暴露坏处是收集阶段崩溃会让整个运行都起不来。所以 yaml 文件结构尽量保持简单不要用别名、不要写多文档流多个 --- 分隔嵌套过深的锚点语法在编辑器校验和报错信息上都不友好。3.3 用 pytest 参数化实现数据驱动ddt 库在 pytest 里怎么摆先看 data/login.yaml。我习惯一个文件放一个业务接口的所有正向、反向用例每条用例是顶层列表的一个元素- case_name: 正确账号密码登录 method: post url: /api/v1/login headers: Content-Type: application/json body: username: admin password: 123456 expected: code: 200 msg: success - case_name: 密码错误 method: post url: /api/v1/login headers: Content-Type: application/json body: username: admin password: wrongpass expected: code: 200 msg: password error注意 password 字段我加了引号。yaml 会自动做类型推断纯数字不写引号会被解析成 int传过去服务端大概率拒收这个坑在第 5 章专门展开。expected 里只放必要的字段不要整段响应都写成预期否则接口新增一个返回字段你的用例就无意义地失败。pytest 侧的标准写法import allure import pytest from common.read_yaml import load_yaml from common.request import http_client # 模块收集时读取一次参数化的数据源 cases load_yaml(data/login.yaml) pytest.mark.parametrize(case, cases, ids[c.get(case_name) for c in cases]) def test_login(case): with allure.step(发送登录请求): resp http_client.send(case) with allure.step(校验响应状态码): assert resp.status_code case[expected][code] with allure.step(校验关键字段): assert resp.json().get(msg) case[expected][msg]parametrize 会把 yaml 里的每条数据展开成独立用例ids 参数生成用例标题在终端和报告里一眼能看出是哪个场景挂了。第二个参数是数据源列表第三个 ids 必须和数据源长度一致否则 pytest 会报收集错误。标题里提到的 ddt 对应的是另一种写法适用于 unittest 风格的历史测试类import ddt import unittest from common.read_yaml import load_yaml cases load_yaml(data/login.yaml) ddt.ddt class TestLoginDDT(unittest.TestCase): ddt.data(*cases) def test_login(self, case): resp http_client.send(case) self.assertEqual(resp.status_code, case[expected][code])ddt 和 parametrize 都能跑区别在细节ddt 展开出来的用例在 pytest 收集器里是 test_login_1、test_login_2 这种自动编号没有 ids 机制几乎对应不上 case_nameparametrize 则天然融入 pytest 的生态allure 报告、重试插件、失败快照全部兼容。提示标题里的 ddt 在纯 pytest 项目里我更建议用 parametrize 替代。ddt 官方就是为 unittest.TestCase 设计的硬套在 pytest 原生测试类上会有收集行为不一致的问题。我一般只在迁移存量 unittest 用例、想最小化改动时保留 ddt。3.4 断言与日志封装排错时最值钱的资产接口自动化的断言不能写成清一色的 assert resp.json() expected。响应里的时间戳、traceId、随机字符串每次都在变整段对比等于给自己埋雷。我按三层来封装断言。第一层是状态码只能说明 HTTP 层通了第二层是关键字段把业务 code 和核心字段取出来对比封装在 common/assert_util.pydef assert_contains(resp_json: dict, expected: dict): 校验 expected 中的每个 key 都存在且值相等 for key, value in expected.items(): assert key in resp_json, f响应缺少字段 {key} assert resp_json[key] value, f字段 {key} 期望 {value}实际 {resp_json[key]}第三层是格式校验适合校验订单号、手机号这类动态值比如断言 order_no 是否匹配 ^ORD\d{12}$避免服务端返回空字符串也被当成成功。日志是接口自动化里最容易被省掉、排错时又最值钱的部分。common/log.py 里做一次基础配置import logging logging.basicConfig( levellogging.INFO, format%(asctime)s %(name)s [%(levelname)s] %(message)s, ) logger logging.getLogger(api_test)在请求封装里用 logger.info 打印请求方法和响应摘要而不是打印完整响应体。完整响应体在用例多的时候会刷爆终端而且敏感信息可能泄露。打印状态码、耗时和响应里的一两个业务字段就够了完整内容留给 allure 附件这一点在第 4 章展开。4. 集成 allure把执行结果变成能交付的测试报告框架跑通只是第一步报告才是让团队愿意用起来的动力。allure 集成到位之后测试结果可以直接扔给开发和产品看不用再解释这个红的是不是环境挂了。4.1 allure-pytest 插件与 allure 命令行先分清这两个东西allure 在实际落地时要装两个独立的组件pytest 插件和 allure 命令行工具。allure-pytest 是 pip 包负责在测试执行过程中把用例结果、步骤、附件写进 report/results 目录生成的是 JSON 格式的原始结果allure 命令行是一个单独的 Java 程序负责把这个 results 目录渲染成 HTML 报告。只装插件不装命令行跑完测试你会发现 results 下全是 JSON根本没有可看的报告。命令行工具装好之后生成报告的固定命令是allure generate report/results -o report/html --clean allure open report/htmlgenerate 把 results 聚合到 html 目录--clean 先清空旧报告open 会起一个本地服务并在浏览器打开。持续集成场景下不需要 opengenerate 完之后把 html 目录作为构建产物归档就行。还有一个 allure generate --single-file 参数会生成单文件报告方便直接发出去但用例多、附件多的时候单文件会非常大酌情使用。pytest.ini 里已经配了 --alluredir所以执行 pytest 之后 results 目录会自动生成。一个容易忽略的点如果手动删除过 results 目录记得先创建它否则 allure-pytest 会报目录不存在。本地反复调试时--clean-alluredir 会清掉旧结果这是符合预期的别以为是数据丢了。4.2 用例标注、动态标题和步骤附件报告不再是一堆函数名默认情况下 allure 报告里的用例名是 test_login[0]、test_login[1] 这种格式人肉对应 case_name 很痛苦。通过 allure 的标注体系可以把报告变得可读。在 3.3 节的用例基础上补全import allure import pytest from common.read_yaml import load_yaml from common.request import http_client cases load_yaml(data/login.yaml) allure.feature(账号体系) allure.story(登录) pytest.mark.parametrize(case, cases, ids[c.get(case_name) for c in cases]) def test_login(case): # 运行期覆盖参数化标题否则报告里只有 test_login[0] allure.dynamic.title(case.get(case_name)) with allure.step(发送登录请求): resp http_client.send(case) with allure.step(校验响应状态码): assert resp.status_code case[expected][code] with allure.step(校验关键字段): assert resp.json().get(msg) case[expected][msg] allure.attach(resp.text, 登录接口响应, allure.attachment_type.TEXT)feature 和 story 是报告里的两级分类feature 对应业务模块story 对应功能点。dynamic.title 在运行时把用例标题改成 yaml 里的 case_name这一步是关键——ids 参数在参数化展开时就固定了没法引用运行时数据所以在函数体内用 dynamic 覆盖。with allure.step 把用例拆成步骤报告里展开能看到发送请求和校验响应两个子步骤失败时直接定位到失败在哪一步。attach 是给用例挂附件的入口TEXT、JSON、HTML 都支持。接口自动化里最实用的附件是响应文本和完整请求体。注意 attach 要在断言执行之前把 resp 存好否则断言抛异常时后面的行不会执行失败现场就丢了。更稳妥的做法是把响应快照放在 4.3 节的失败钩子里统一处理。4.3 失败自动快照用 pytest_runtest_makereport 生成可定位的失败现场用例断言失败时仅凭 traceback 在接口自动化里往往不够你看不到请求发了什么、服务端回了什么。我在 conftest.py 里用 pytest_runtest_makereport 钩子统一打快照这样就不用在每条用例里手动写 attachimport allure import pytest from common.request import http_client pytest.hookimpl(hookwrapperTrue) def pytest_runtest_makereport(item, call): # 先执行用例结束后才能拿到 report 对象 outcome yield report outcome.get_result() if report.when call and report.failed: last_resp http_client.last_response if last_resp is not None: allure.attach(last_resp.text, 失败响应体, allure.attachment_type.TEXT)这段代码的思路是钩子在每条用例执行完后触发通过 report.failed 判断是否失败然后从 common.request 里的全局 http_client 读取最近一次请求的响应挂到失败用例上。前提是请求封装里每次 send 都更新 last_response即使断言失败这个值也不会丢。这样报告里每个失败用例都有完整响应体不需要用例本身写任何 attach 代码。注意快照不要做得太重。请求摘要、响应体、状态码三样足够定位绝大多数接口问题。如果某些接口响应达到几 MB全部挂上去会让报告打开很慢可以在快照里截断只保留前 2000 个字符。5. 这套框架的 5 个常见坑从 yaml 类型转换到 token 失效的排查路径这一章的每条坑都是我在实际项目里踩过或者帮团队排过的。每条按现象、原因、解决三步写遇到类似问题可以直接照着排查。5.1 yaml 类型自动转换密码 123456 为什么变成了数字现象yaml 里写的登录密码是 123456请求发出去服务端一直报密码格式错误代码里 print 出来发现 password 的值是 int 而不是字符串。原因yaml 规范自带类型推断。纯数字解析成 int形如 0123 的会被按八进制解析true/false/yes/no 会被解析成布尔值。测试数据一旦被转换接口收到的就是完全不同的类型。解决给可能产生歧义的字符串加引号写成 password: 123456 是标准做法。更保险的是在 read_yaml 封装里对读取结果做递归类型检查把 int 自动转 str但这样会把本来希望是数字的字段也转掉所以按字段加引号更可控。另外带前导零的字符串比如 001 不写引号会变成整数 1这种掉得无声无息排查起来最费时间。5.2 ddt 与 pytest 参数化重复执行用例跑了两遍现象测试类上加了 ddt.ddt方法上又用了 pytest.mark.parametrize跑 pytest 发现同一条用例的日志出现两次。原因ddt 在类加载阶段通过包装init生成新的测试方法test_login_1、test_login_2pytest 的参数化是另一套独立的展开机制两套叠加等于数据被展开两遍。更隐蔽的是另一个方向用了 ddt.data 但类上没加 ddt.ddt或者类不继承 unittest.TestCaseddt 不会报错但数据完全没有展开用例只跑一次你以为覆盖了多条数据实际只跑了一条。解决二选一。新代码一律用 pytest.mark.parametrize存量 unittest 类用 ddt 就不要再加 parametrize。如果测试类继承 unittest.TestCasepytest 会把整类按 unittest 模式收集ddt 展开的方法名是 test_login_1 这种报告可读性差长期维护建议逐步迁移到 parametrize。5.3 token 过期导致批量失败session 级 fixture 的续期方案现象用例在一开始全过跑到第 30 条左右开始集中出现 401单独重跑挂掉的那条又是正常的。原因接口鉴权 token 有有效期。如果每条用例都重新登录取 token要么频繁刷新触发单点限流要么拿到的是刚过期的一批 token如果多条用例并发执行时同时刷新 token还会出现用 A 的 token 跑 B 用例的串号问题。解决token 放在 session 级 fixture 里整个 pytest 进程只取一次再在请求封装里做自动续期——请求返回 401 时用账号重新登录更新全局 token 后重放当前请求。续期逻辑必须加锁防止两条用例同时续期产生竞争。具体实现见第 6 章。5.4 allure 报告乱码与附件打不开编码和清理问题现象allure 报告打开后用例名或步骤里的中文显示成乱码附件里的 JSON 双击打开是乱码。原因乱码大多出在执行环境——yaml 或代码文件读取时没有显式指定编码Windows 下走了 GBK或者 allure 命令行渲染时用的系统默认编码不是 UTF-8。附件打不开则多为 results 目录残留上一次运行写到一半的 JSON 文件没被清掉allure generate 解析到半截文件直接跳过甚至卡住。解决所有涉及文件读写的代码统一传 encodingutf-8包括 open、yaml、csv 读取。执行命令固定为 pytest --alluredirreport/results --clean-alluredir生成报告固定为 allure generate report/results -o report/html --clean两处 --clean 一个清结果一个清报告。如果还乱码检查 allure 命令行工具版本旧版本对中文字体的渲染有已知问题升级到较新版本即可。5.5 环境切换时 base_url 漂移数据文件里不该写 host现象同一套用例在测试环境全过切到预发环境跑大量用例 ConnectionError。排查发现 yaml 里接口地址写的是带具体域名的完整 URL换环境只换了测试工具的 host框架里没换。原因把环境相关的信息写进了用例数据。base_url 属于环境配置不属于测试意图yaml 一旦包含完整 URL就做不到一套数据跑多套环境。解决yaml 里只写相对路径比如 url: /api/v1/login请求封装里用全局配置的 base_url 拼接。环境切换通过命令行参数实现conftest.py 里用 pytest_addoption 注册 --envsettings 模块读取后拼进请求地址。这样同一个 yaml 可以在测试、预发、生产三套环境跑只需要指定 --env。6. 进阶把 token 会话、失败重试和轮询断言做成公共能力框架跑顺之后稳定性就是下一步要解决的。这一章把 5.3 的 token 续期、偶发网络失败重试、异步接口轮询断言沉淀成公共层避免每个业务用例各写一套。6.1 conftest.py 里维护 session 级 token 与 requests.Sessiontoken 的获取放在 conftest.py 的 session 级 fixture 里续期逻辑收进 common/request.py# testcases/conftest.py import pytest from common.request import http_client pytest.fixture(scopesession) def login_token(): # 整个 pytest 进程只触发一次登录 return http_client.ensure_token()# common/request.py import requests import threading class HttpClient: def __init__(self): self.session requests.Session() self.lock threading.Lock() self._token None def ensure_token(self): if self._token is not None: return self._token with self.lock: if self._token is None: # 账号信息从 config.settings 读取这里不硬编码 resp self.session.post(LOGIN_URL, jsonLOGIN_BODY) self._token resp.json()[token] return self._tokenensure_token 的双重判断加锁保证并发用例同时调用时只触发一次登录。requests.Session 会复用连接池几十条用例共用一个 session比每条用例新建 requests 实例省掉大量 TCP 握手。注意 Session 对象不是线程安全的多进程执行时每个进程要单独实例化一个 HttpClient不能序列化共享。6.2 请求级重试与轮询断言接口自动化最后的稳定性拼图接口自动化最容易被偶发失败搞崩。网络抖动、服务启动中的瞬时 502、异步任务还没就绪就断言都会让凌晨的定时任务跑挂。请求级重试要对着状态码做而不是盲目重试一切失败def send_with_retry(self, case, retries3, timeout10): 只对网关类状态码重试4xx 属于业务决策错误不重试 url BASE_URL case[url] for attempt in range(retries): resp self.session.request(case[method], url, headerscase.get(headers), jsoncase.get(body), timeouttimeout) if resp.status_code not in {502, 503, 504}: return resp return resp轮询断言适用于订单状态、支付回调这类异步场景发送请求后轮询查询接口直到目标状态出现或超时再把断言放在轮询循环外部。把这两个能力做成公共方法而不是每个用例自己写循环是框架走向稳定的关键。我吃过一次教训把重试逻辑写在业务用例里结果每条用例都有一段 while True日志混乱、超时不可控最后花两个晚上重构回公共层。公共能力越早沉淀框架的使用成本越低。希望帮到你。本文还有配套的精品资源点击获取
阅读完成 · 觉得有帮助？
