1. 项目概述为什么选择Requests做接口自动化测试在软件测试领域接口自动化测试是保障服务稳定性和交付效率的核心环节。当项目规模扩大接口数量激增单纯依赖手工测试不仅效率低下还容易遗漏回归场景。这时一个轻量、灵活且强大的工具就显得至关重要。Python的requests库正是这样一个被广泛采用的利器。它不像一些重型框架那样需要复杂的配置和学习成本而是以“人类友好”的API设计让测试工程师能快速上手将测试逻辑从“点击”转变为“代码”。我选择requests作为自动化测试的核心主要基于几个现实考量首先它的学习曲线平缓任何有基础Python能力的开发者都能在几小时内写出可运行的测试脚本。其次requests对HTTP协议的支持非常完整从基础的GET、POST到复杂的认证、会话管理、文件上传都能优雅地处理。再者其生态成熟与pytest、unittest等测试框架以及Allure、HTMLTestRunner等报告工具能无缝集成轻松构建起从脚本编写到报告生成的完整流水线。最后也是最重要的一点requests赋予了我们极大的灵活性。我们可以精细控制每一次请求的头部、参数、超时和重试策略这对于模拟复杂业务场景、处理各种边界条件和异常响应比如网络抖动、服务端限流至关重要。简单来说用requests做接口自动化就是把测试用例从“文档描述”变成“可执行、可断言、可复现的代码”。它适合所有需要与HTTP接口打交道的测试工程师、开发工程师甚至DevOps工程师无论是验证一个新上线的微服务还是确保核心交易链路在每日构建后依然稳固requests都能成为你手中最趁手的工具之一。2. 环境搭建与基础请求封装2.1 核心环境准备与依赖安装工欲善其事必先利其器。开始之前我们需要一个干净的Python环境。我强烈建议使用虚拟环境如venv或conda来管理项目依赖避免不同项目间的包版本冲突。首先创建并激活一个虚拟环境# 创建虚拟环境 python -m venv venv_apitest # 激活虚拟环境 (Windows) venv_apitest\Scripts\activate # 激活虚拟环境 (MacOS/Linux) source venv_apitest/bin/activate激活后命令行提示符前会出现(venv_apitest)字样。接下来安装核心库pip install requests pytest pytest-html allure-pytest这里我们一次性安装了测试框架pytest、HTML报告插件pytest-html以及生成更美观的Allure报告的allure-pytest。requests库是核心自然也在其中。注意如果安装过程中遇到网络问题可以尝试使用国内镜像源例如pip install -i https://pypi.tuna.tsinghua.edu.cn/simple requests pytest。安装完成后可以通过pip list命令确认requests等库已正确安装。一个常见的报错是ModuleNotFoundError: No module named requests这通常意味着虚拟环境未正确激活或者安装命令在全局Python环境中执行了。请务必确保在激活的虚拟环境中操作。2.2 构建可复用的请求会话类直接使用requests.get()或requests.post()在简单场景下没问题但在实际的自动化项目中我们往往需要处理一些通用逻辑比如统一请求头为所有请求添加Content-Type: application/json或认证令牌。全局超时设置避免某个接口卡死导致整个测试套件长时间等待。日志记录详细记录每次请求和响应的信息便于调试。异常处理与重试应对网络波动或服务端临时错误如429状态码。因此封装一个基础的RequestSession类是非常好的实践。下面是一个我常用的基础封装示例import requests import logging from typing import Optional, Dict, Any import json import time class RequestSession: 封装requests.Session提供统一的请求、日志和基础重试能力 def __init__(self, base_url: str , timeout: int 10): 初始化会话 :param base_url: 接口基础地址如 http://api.example.com/v1 :param timeout: 默认请求超时时间秒 self.session requests.Session() self.base_url base_url.rstrip(/) # 去除末尾斜杠 self.timeout timeout # 设置默认请求头 self.session.headers.update({ Content-Type: application/json; charsetutf-8, User-Agent: APITestBot/1.0 }) # 配置日志 logging.basicConfig(levellogging.INFO, format%(asctime)s - %(name)s - %(levelname)s - %(message)s) self.logger logging.getLogger(__name__) def _full_url(self, endpoint: str) - str: 拼接完整的请求URL endpoint endpoint.lstrip(/) return f{self.base_url}/{endpoint} if self.base_url else endpoint def request(self, method: str, endpoint: str, **kwargs) - requests.Response: 发送HTTP请求的核心方法 :param method: HTTP方法如 GET, POST, PUT, DELETE :param endpoint: 接口路径如 users/login :param kwargs: 传递给requests.request的其他参数如 json, params, headers, timeout url self._full_url(endpoint) # 处理超时优先使用调用时传入的timeout否则使用默认值 timeout kwargs.pop(timeout, self.timeout) # 请求前日志 self.logger.info(f[Request] {method} {url}) if json in kwargs: self.logger.debug(fRequest Body: {json.dumps(kwargs[json], indent2, ensure_asciiFalse)}) if params in kwargs: self.logger.debug(fRequest Params: {kwargs[params]}) try: response self.session.request(methodmethod, urlurl, timeouttimeout, **kwargs) # 响应后日志 self.logger.info(f[Response] Status: {response.status_code}, Time: {response.elapsed.total_seconds():.2f}s) # 尝试记录响应体如果是JSON则格式化 try: resp_json response.json() self.logger.debug(fResponse Body: {json.dumps(resp_json, indent2, ensure_asciiFalse)}) except json.JSONDecodeError: self.logger.debug(fResponse Body (Text): {response.text[:500]}...) # 只记录前500字符 except requests.exceptions.Timeout: self.logger.error(f[Timeout] {method} {url} exceeded {timeout}s timeout.) raise except requests.exceptions.ConnectionError as e: self.logger.error(f[ConnectionError] {method} {url} failed: {e}) raise except Exception as e: self.logger.error(f[Unexpected Error] {method} {url}: {e}) raise return response # 便捷方法 def get(self, endpoint: str, params: Optional[Dict] None, **kwargs) - requests.Response: return self.request(GET, endpoint, paramsparams, **kwargs) def post(self, endpoint: str, json_data: Optional[Dict] None, **kwargs) - requests.Response: return self.request(POST, endpoint, jsonjson_data, **kwargs) def put(self, endpoint: str, json_data: Optional[Dict] None, **kwargs) - requests.Response: return self.request(PUT, endpoint, jsonjson_data, **kwargs) def delete(self, endpoint: str, **kwargs) - requests.Response: return self.request(DELETE, endpoint, **kwargs)这个类做了几件关键事情它内部维护了一个requests.Session对象可以自动管理cookies在多次请求间保持状态它统一了日志格式让请求和响应的关键信息一目了然它提供了get、post等便捷方法让调用更符合直觉。后续所有的测试用例都将基于这个封装类来编写这能极大提升代码的整洁度和可维护性。3. 测试用例设计与断言策略3.1 从手工测试到自动化用例的转化设计自动化测试用例第一步是梳理手工测试场景。假设我们有一个用户管理服务核心接口包括用户登录、查询用户信息、创建用户、更新用户、删除用户。手工测试时我们会准备测试数据用Postman或浏览器发送请求然后肉眼检查返回的状态码、数据字段是否正确。自动化测试就是将这个过程代码化。一个完整的测试用例通常包含三个部分准备Arrange准备测试数据如创建测试用户、获取认证令牌。执行Act调用被测试的接口。断言Assert验证接口返回是否符合预期。例如一个“登录成功”的用例可以这样设计准备使用一个已知正确的用户名和密码。执行向/auth/login发送POST请求携带用户名和密码。断言状态码为200。响应体中包含token字段且不为空。响应体中user_id字段与预期用户ID一致。3.2 多层次断言从状态码到业务逻辑使用requests获取到Response对象后我们需要对其进行全面的断言。pytest的assert语句结合Python丰富的表达式能力可以让我们进行非常灵活的断言。基础断言def test_login_success(api_client): 测试登录成功场景 # 1. 准备 login_data {username: test_user, password: secure_password123} # 2. 执行 resp api_client.post(/auth/login, json_datalogin_data) # 3. 断言 # 断言状态码 assert resp.status_code 200, fExpected 200, got {resp.status_code}. Response: {resp.text} # 断言响应体是有效的JSON resp_json resp.json() assert isinstance(resp_json, dict) # 断言关键字段存在且不为空 assert token in resp_json, Response missing token field assert resp_json[token], Token field is empty # 非空判断 assert user_id in resp_json, Response missing user_id field # 断言业务逻辑user_id是正整数 assert isinstance(resp_json[user_id], int) and resp_json[user_id] 0, fInvalid user_id: {resp_json[user_id]}进阶断言处理复杂数据结构当响应结构复杂时可以使用jsonpath或递归查找来断言嵌套字段。一个简单实用的方法是使用字典的.get()方法进行安全访问和断言。def test_get_user_detail(api_client, auth_token): 测试获取用户详情包含嵌套信息 headers {Authorization: fBearer {auth_token}} resp api_client.get(/users/1001, headersheaders) assert resp.status_code 200 user_data resp.json() # 断言顶层字段 assert user_data.get(username) test_user assert user_data.get(email) testexample.com # 断言嵌套对象字段 profile user_data.get(profile, {}) assert profile.get(nickname) Tester assert isinstance(profile.get(age), int) # 断言数组字段 roles user_data.get(roles, []) assert len(roles) 0 assert member in roles # 断言数组包含某个元素实操心得断言信息要足够清晰。当断言失败时assert语句后面的错误信息应该能直接告诉我们哪里出了问题。所以我习惯在断言状态码或关键字段时附带打印出响应文本resp.text这在调试初期非常有用。另外对于可能为None的字段使用.get(key, default)比直接[key]索引更安全能避免KeyError导致测试用例意外中断。4. 处理复杂场景与高级特性4.1 会话管理与认证状态保持很多接口需要认证比如先登录获取token后续请求在Header中携带这个token。requests.Session的妙处就在这里——它可以自动管理Cookies。但对于更常见的基于Token如JWT的认证我们需要手动处理。方案一每次请求手动添加Headerclass TestUserWithAuth: def setup_method(self): self.client RequestSession(base_urlhttp://api.example.com) # 登录获取token login_resp self.client.post(/login, json_data{user: admin, pass: 123}) self.token login_resp.json()[access_token] def test_auth_api(self): # 为本次请求添加认证头 headers {Authorization: fBearer {self.token}} resp self.client.get(/protected/data, headersheaders) assert resp.status_code 200方案二封装一个自动注入Token的Client更优雅的方式是扩展我们之前的RequestSession让它能自动管理认证状态。class AuthRequestSession(RequestSession): 带认证状态的请求会话 def __init__(self, base_url: str ): super().__init__(base_url) self._token None def login(self, username: str, password: str): 登录并保存token resp self.post(/auth/login, json_data{username: username, password: password}) resp.raise_for_status() # 如果状态码不是2xx抛出HTTPError异常 self._token resp.json()[token] # 登录后更新session的默认headers后续所有请求自动携带 self.session.headers.update({Authorization: fBearer {self._token}}) self.logger.info(Login successful, token updated in session headers.) return resp def logout(self): 登出清除token if self._token: self.post(/auth/logout) # 可选通知服务端token失效 self._token None self.session.headers.pop(Authorization, None) self.logger.info(Logged out, authorization header removed.)这样在测试类中我们只需要在setup阶段调用一次client.login(...)后续所有通过这个client发起的请求都会自动带上认证头极大简化了测试代码。4.2 应对限流与429状态码在测试或高并发场景下我们很容易触发服务端的限流策略收到429 Too Many Requests响应。一个健壮的自动化测试框架必须能妥善处理这种情况。策略一请求间增加延迟最简单的方法是在连续请求之间插入短暂的睡眠时间。import time def test_multiple_requests_with_delay(api_client): for i in range(10): resp api_client.get(f/items/{i}) # 简单的断言... time.sleep(0.5) # 每次请求后暂停0.5秒但这会显著拉长测试执行时间且延迟时间难以精确设定。策略二实现带退避策略的智能重试更专业的做法是实现一个重试装饰器或适配器当遇到429或5xx错误时自动重试。我们可以利用requests的HTTPAdapter和urllib3的Retry类。from requests.adapters import HTTPAdapter from urllib3.util.retry import Retry def create_session_with_retry(retries3, backoff_factor0.5, status_forcelist[429, 500, 502, 503, 504]): 创建一个带重试策略的Session :param retries: 最大重试次数 :param backoff_factor: 退避因子用于计算重试间隔 (backoff_factor * (2^(重试次数-1))) :param status_forcelist: 触发重试的状态码列表 session requests.Session() retry_strategy Retry( totalretries, backoff_factorbackoff_factor, status_forceliststatus_forcelist, allowed_methods[GET, POST, PUT, DELETE, HEAD, OPTIONS, TRACE] # 注意默认不重试POST这里显式允许 ) adapter HTTPAdapter(max_retriesretry_strategy) session.mount(http://, adapter) session.mount(https://, adapter) return session # 在我们的RequestSession中集成 class RobustRequestSession(RequestSession): def __init__(self, base_url: str , timeout: int 10, retry_config: dict None): # 先调用父类初始化但替换掉默认的session self.base_url base_url.rstrip(/) self.timeout timeout default_retry_config {retries: 3, backoff_factor: 1.0, status_forcelist: [429, 500, 502, 503, 504]} config {**default_retry_config, **(retry_config or {})} self.session create_session_with_retry(**config) # 使用带重试的session self.session.headers.update({ Content-Type: application/json; charsetutf-8, User-Agent: APITestBot/1.0 }) self.logger logging.getLogger(__name__)这个重试策略是“指数退避”的。例如backoff_factor1.0第一次重试等待1秒第二次等待2秒第三次等待4秒。这既能给服务端喘息之机又避免了无意义的频繁重试。特别注意默认的Retry策略对于非幂等的POST、PATCH等方法是不重试的因为重试可能导致重复提交。在我们的测试场景中如果确认测试接口是幂等的比如查询、或测试专用的清理接口可以像上面代码一样通过allowed_methods参数显式允许。对于非幂等操作如创建订单应谨慎使用或禁用重试。4.3 文件上传、下载与多部分表单测试文件上传接口是常见的需求。requests处理multipart/form-data非常方便。文件上传示例def test_upload_avatar(api_client, auth_token): headers {Authorization: fBearer {auth_token}} # 准备文件 file_path test_avatar.png # 确保文件存在可以在这里动态创建一个测试文件 with open(file_path, wb) as f: f.write(bfake_png_data) # 写入一些模拟数据 with open(file_path, rb) as f: files {file: (avatar.png, f, image/png)} # 元组格式: (文件名, 文件对象, MIME类型) data {description: My new profile picture} resp api_client.post(/users/avatar, filesfiles, datadata, headersheaders) assert resp.status_code 200 assert resp.json()[avatar_url] is not None文件下载示例def test_download_report(api_client, auth_token): headers {Authorization: fBearer {auth_token}} resp api_client.get(/reports/monthly.pdf, headersheaders) assert resp.status_code 200 assert resp.headers[Content-Type] application/pdf # 将内容保存到文件 with open(monthly_report.pdf, wb) as f: for chunk in resp.iter_content(chunk_size8192): f.write(chunk) # 验证文件大小 import os assert os.path.getsize(monthly_report.pdf) 0这里使用了resp.iter_content(chunk_size8192)来流式下载大文件避免一次性将整个文件加载到内存中。5. 测试数据管理与Fixture的应用5.1 测试数据的隔离与清理自动化测试不能污染线上或测试环境的数据。每条测试用例都应该是独立的运行前后环境状态一致。这涉及到测试数据的“创建”和“清理”。原则谁创建谁清理。通常我们在测试开始前setup创建测试所需的数据在测试结束后teardown清理这些数据。pytest的fixture是管理这类生命周期的最佳工具。import pytest pytest.fixture def test_user(api_client): 创建一个测试用户测试结束后删除它。 # 1. 创建数据 (Setup) user_data { username: ftest_user_{int(time.time())}, # 使用时间戳确保唯一性 password: TempPass123, email: ftest_{int(time.time())}example.com } create_resp api_client.post(/users, json_datauser_data) # 假设创建成功返回用户ID user_id create_resp.json()[id] yield user_id # 将user_id提供给测试用例使用 # 3. 清理数据 (Teardown) - yield之后的部分会在测试用例结束后执行 api_client.delete(f/users/{user_id}) def test_update_user_email(api_client, test_user): 测试更新用户邮箱。fixture test_user 提供了可用的用户ID。 user_id test_user update_data {email: updatedexample.com} resp api_client.put(f/users/{user_id}, json_dataupdate_data) assert resp.status_code 200 # 可以再查询一次验证更新是否生效 get_resp api_client.get(f/users/{user_id}) assert get_resp.json()[email] updatedexample.com在这个例子中test_userfixture确保了每个运行test_update_user_email的测试都有一个全新的、独立的用户测试完成后这个用户会被自动删除不会影响其他测试。5.2 使用工厂模式生成复杂测试数据当测试数据构造逻辑复杂时比如一个完整的订单对象可以抽象出一个“工厂”函数。def create_order_data(user_id, product_skusNone): 生成一个标准的订单测试数据 if product_skus is None: product_skus [SKU001, SKU002] return { user_id: user_id, items: [{sku: sku, quantity: 1} for sku in product_skus], shipping_address: { street: 123 Test St, city: Testville, zipcode: 12345 }, payment_method: credit_card } # 在测试用例中使用 def test_create_order(api_client, auth_token, test_user): headers {Authorization: fBearer {auth_token}} order_data create_order_data(user_idtest_user) resp api_client.post(/orders, json_dataorder_data, headersheaders) assert resp.status_code 201工厂函数让测试数据生成逻辑集中、可复用也更容易维护。当业务字段变更时只需修改工厂函数即可。6. 集成测试框架与生成测试报告6.1 使用Pytest组织测试用例pytest是目前Python社区最主流的测试框架它功能强大且灵活。我们将用pytest来发现、组织和运行所有基于requests的测试用例。项目目录结构建议api_auto_test/ ├── conftest.py # 全局fixture定义如api_client ├── requirements.txt # 项目依赖 ├── tests/ # 测试用例目录 │ ├── __init__.py │ ├── test_auth.py # 认证相关测试 │ ├── test_user.py # 用户管理测试 │ └── test_order.py # 订单相关测试 └── utils/ └── request_client.py # 封装的RequestSession类conftest.py定义全局Fixtureimport pytest from utils.request_client import RobustRequestSession import os pytest.fixture(scopesession) # 整个测试会话只创建一次 def api_client(): 创建一个全局的、带重试的API客户端 base_url os.getenv(API_BASE_URL, http://localhost:8080/api/v1) client RobustRequestSession(base_urlbase_url, timeout15) yield client # 如果需要可以在这里做全局清理比如登出所有会话 # client.logout() pytest.fixture def auth_token(api_client): 获取一个有效的认证token供需要认证的测试用例使用 # 这里使用一个预设的测试账号实际项目中可以从配置或环境变量读取 login_resp api_client.post(/auth/login, json_data{username: test_auto, password: test_pass_123}) assert login_resp.status_code 200, 预置测试账号登录失败请检查环境或账号配置 token login_resp.json()[access_token] return token一个完整的测试模块示例 (tests/test_user.py)import pytest class TestUserAPI: 用户相关接口测试集 def test_create_user_success(self, api_client): 测试成功创建用户 user_data { username: fnew_user_{pytest.current_timestamp}, # 使用pytest插件生成唯一标识 email: fnew_{pytest.current_timestamp}test.com, password: Str0ngPss! } resp api_client.post(/users, json_datauser_data) assert resp.status_code 201 resp_data resp.json() assert id in resp_data assert resp_data[username] user_data[username] # 清理删除创建的用户也可以通过fixture实现这里演示直接调用 api_client.delete(f/users/{resp_data[id]}) def test_create_user_duplicate_username(self, api_client, test_user): 测试创建重复用户名的失败场景 # 假设test_user fixture返回了已存在用户的用户名 duplicate_data { username: test_user[username], # 重复的用户名 email: anothertest.com, password: password123 } resp api_client.post(/users, json_dataduplicate_data) # 预期应该返回400或409冲突状态码 assert resp.status_code in [400, 409] assert already exists in resp.json().get(message, ).lower() pytest.mark.parametrize(invalid_email, [not-an-email, missingdomain, domain.com, ]) def test_create_user_with_invalid_email(self, api_client, invalid_email): 参数化测试使用无效邮箱创建用户应失败 user_data { username: fuser_{pytest.current_timestamp}, email: invalid_email, password: ValidPass123 } resp api_client.post(/users, json_datauser_data) # 预期客户端错误 assert resp.status_code 400 # 可以进一步断言错误信息中包含邮箱验证相关的关键词 error_msg resp.json().get(message, ) assert any(keyword in error_msg.lower() for keyword in [email, invalid, format])这里展示了几个关键点使用class组织相关测试使用pytest.mark.parametrize进行参数化测试用一个测试函数覆盖多种无效邮箱的输入场景在断言时不仅检查状态码还检查响应消息内容使测试更健壮。6.2 生成丰富的测试报告测试执行完毕后一份清晰的报告对于分析结果至关重要。pytest可以生成多种格式的报告。1. 控制台详细输出运行测试时使用-vverbose参数可以输出每个测试用例的详细结果使用-s可以输出打印语句如我们封装的Client中的日志。pytest tests/ -v -s2. 生成JUnit XML报告便于CI集成pytest tests/ --junitxmlreports/test-results.xmlJenkins、GitLab CI等持续集成工具可以解析这种格式的报告展示测试通过率和历史趋势。3. 生成美观的HTML报告使用pytest-html插件。pytest tests/ --htmlreports/report.html --self-contained-html生成的report.html文件可以在浏览器中打开清晰地看到通过、失败、跳过的测试用例列表以及每个失败用例的详细错误信息和日志。4. 生成Allure报告更强大、更美观Allure报告提供了仪表盘、图表、用例分组、附件如请求/响应日志、截图等高级功能。 首先运行测试并生成Allure结果数据pytest tests/ --alluredir./allure-results然后使用Allure命令行工具生成HTML报告allure generate ./allure-results -o ./allure-report --clean allure open ./allure-report # 在浏览器中打开报告为了在Allure报告中附加我们封装的请求/响应日志可以使用pytest的钩子函数或在fixture中动态添加附件这需要更深入的配置但能极大提升调试效率。7. 常见问题排查与实战技巧在实际编写和运行接口自动化测试的过程中你会遇到各种各样的问题。下面是我总结的一些典型问题及其解决方案。7.1 连接与超时问题问题ConnectionError或Timeout可能原因服务未启动、网络不通、防火墙限制、服务端处理过慢。排查步骤手动用curl或Postman访问同一地址确认服务可达。检查base_url是否正确特别是协议http/https、端口和路径。适当增加timeout参数如从10秒增加到30秒。但要注意设置过长会拖慢失败测试的速度。检查本地或服务器防火墙设置。技巧在RequestSession的初始化中设置一个合理的默认超时如10秒并为某些已知的慢查询接口在调用时单独指定更长的超时时间。# 针对一个生成复杂报表的慢接口单独设置长超时 resp api_client.get(/reports/complex, timeout60)7.2 处理动态数据与依赖问题测试数据ID或Token动态变化导致硬编码的断言失败。解决方案永远不要硬编码ID、Token等动态值。使用fixture或 setUp 方法实时获取。示例前面提到的auth_tokenfixture和test_userfixture就是最佳实践。它们保证了每次测试都能拿到最新的有效数据。问题测试用例之间有顺序依赖。反模式test_B需要test_A创建的数据。解决方案每个测试用例必须是独立的。使用fixture来建立测试用例所需的初始状态。如果test_B需要一个特定状态就在test_B内部或通过一个fixture去创建这个状态而不是依赖另一个测试用例的执行。7.3 处理非JSON响应问题接口返回HTML、XML或纯文本resp.json()抛出JSONDecodeError。解决方案先检查Content-Type再决定如何解析。resp api_client.get(/status) content_type resp.headers.get(Content-Type, ) if application/json in content_type: data resp.json() elif text/html in content_type or text/plain in content_type: data resp.text # 然后可以用正则或字符串方法提取需要断言的信息 assert System is OK in data else: # 其他二进制格式等 pass7.4 调试与日志查看当测试失败时详细的日志是定位问题的关键。我们已经在RequestSession中集成了日志记录。确保测试运行时日志级别设置为INFO或DEBUG。查看请求详情日志中记录了URL、方法、请求体如果为JSON。查看响应详情记录了状态码、耗时和响应体JSON会格式化非JSON会截断显示。技巧对于复杂的测试场景可以在关键的断言前后添加自定义的日志信息。self.logger.info(fAsserting that user {user_id} has role admin...) assert admin in user_roles self.logger.info(Assertion passed.)7.5 性能与稳定性考量避免同步睡眠除非模拟用户思考时间否则不要在测试用例中使用time.sleep()来等待异步操作完成。应采用**轮询polling**机制。def wait_for_status(api_client, task_id, expected_statusSUCCESS, max_attempts10, interval2): 轮询任务状态直到达到预期状态或超时 for i in range(max_attempts): resp api_client.get(f/tasks/{task_id}) current_status resp.json()[status] if current_status expected_status: return True elif current_status in [FAILED, CANCELLED]: raise Exception(fTask {task_id} failed with status: {current_status}) time.sleep(interval) raise TimeoutError(fTask {task_id} did not reach {expected_status} within {max_attempts*interval} seconds)管理测试数据量清理数据时如果直接循环删除如删除所有测试用户可能效率低下或触发限流。如果服务端提供了批量删除或按条件删除的接口应优先使用。如果没有可以考虑在测试开始前通过一个专门的“测试数据初始化”接口来清理旧数据而不是在每条用例后单独删除。通过系统性地应用这些策略和技巧基于requests的接口自动化测试框架就能变得非常健壮和高效足以应对从简单CRUD到复杂业务流程的各种测试场景。关键在于理解HTTP协议、善于利用requests和pytest提供的各种功能并以一种清晰、可维护的方式组织你的测试代码。