Python+requests接口自动化测试框架搭建实战指南

干了几年测试开发，我一直跟身边的同事说：接口自动化是投入产出比最高的测试投资。UI自动化脆如玻璃，今天一个id变了明天一个xpath挂了，维护成本高到让人怀疑人生。但接口不一样，接口是系统的骨架，骨架稳了，再怎么折腾UI都不至于塌方。

Python+requests这个组合，是我用过的接口自动化方案里最顺手的一套。requests库本身设计简洁、语义清晰，配合Python的灵活性，能在很短时间内搭出一套能跑业务链路的接口测试框架。本文不聊虚的，从环境配置到框架搭建，从登录鉴权到报告生成，把我实际项目中验证过的方案完整拆给你看。

1. 为什么是Python+requests：接口自动化的选型思考

1.1 接口自动化测试到底要解决什么问题

做接口自动化的第一件事，不是写代码，而是想清楚目标。我见过不少团队，一上来就追求大而全的平台，最后平台成了摆设。接口自动化要解决的核心问题其实就三个：回归成本、数据可信度、测试效率。

• 回归成本：每次版本迭代，核心接口是否被改坏，手工点页面验证链路太慢，接口层跑一遍几十个用例，几分钟出结果。
• 数据可信度：UI层的报错可能是前端问题，接口层验证了后端逻辑的正确性，出了问题能精准定位到服务端。
• 测试效率：开发自测、CI流水线、每日巡检，都需要一个能快速触达后端逻辑的验证手段。

接口自动化不需要覆盖所有接口，优先覆盖核心交易链路、鉴权逻辑、数据状态流转。以支付场景为例，下单、支付回调、订单状态查询这三段接口必须自动化覆盖，因为它们是资金相关的高危链路，任何改动都可能引发线上故障。

1.2 requests库凭什么成为接口测试的首选

Python的HTTP客户端有不少选择，urllib、httpx、requests，我最终常驻requests是有原因的。urllib是标准库，功能其实够用，但API设计偏底层，光是一个URL编码就要处理好几步，写起来繁琐不说，可读性也差。httpx是后起之秀，支持同步异步双模式，性能确实好，但在接口自动化这个场景里，异步带来的收益远不如代码复杂度带来的成本。requests的API设计几乎就是"望文生义"：GET请求就requests.get()，POST请求就requests.post()，参数用params和json两个关键字一目了然。

更重要的是requests的生态成熟度。它在处理重定向、Cookie持久化、SSL证书校验、代理隧道这些坑时，基本做到开箱即用。比如测试环境经常用自签名HTTPS证书，urllib遇到这种场景要写一堆SSLContext配置，而requests只需要一个verify=False参数。

1.3 这个组合适合谁用

如果你是测试工程师、测试开发，或者是需要验证自己接口的后端开发，Python+requests这套组合都值得掌握。它对机器配置的要求几乎为零，Windows、macOS、Linux都能跑，也不需要像Java那样装JDK配环境变量。Python脚本本身就是一种可执行的需求文档，即使团队里有人不懂代码，看到requests.post(url, json=data)也能猜出七八分意图。

2. 环境准备：装对Python版本比装requests本身更重要

2.1 Python版本怎么选

很多人装Python时直接下载官网最新版，这是第一个坑。接口自动化项目不是越新越好，而是要稳。以我实际踩过的坑为例：Python 3.12刚发布时，有些第三方库还没适配，装requests虽然没问题，但要装pandas做数据处理、或者装allure-pytest做报告时，就可能遇到二进制包编译失败的情况。

我的建议是：当前项目环境优先选Python 3.8到3.11之间的版本。3.8是经典版本，兼容性极好，即使到现在，一些老项目的requirements.txt里还固定着python==3.8。如果你要在这个项目里做异步处理或者用一些新语法特性，3.10、3.11都很合适。具体选择可以参考下表：

2.2 虚拟环境：隔离比想象中重要

接口自动化项目通常不止一个，今天做下单链路，明天做数据巡检，每个项目的依赖版本可能互相冲突。我吃过一次大亏：某个项目的requests版本需要2.28以上，但另一个老项目要求requests固定在2.25，结果两个项目的依赖在一个环境里"打架"，搞到后来整个Python环境崩了，只能重装。

所以，创建虚拟环境这个步骤一定不能省。Windows下直接用venv：

python -m venv venv venv\Scripts\activate

macOS/Linux下：

python3 -m venv venv source venv/bin/activate

激活后，命令行前缀出现(venv)，就说明已经进入独立的Python环境了。这时用pip安装的所有包都会被隔离在这个虚拟环境里，不会污染全局Python。

2.3 requests安装与验证

安装requests只需要一行命令：

pip install requests

国内网络环境不建议直接用官方PyPI源，速度慢还容易超时。我一般使用清华镜像源：

pip install requests -i https://pypi.tuna.tsinghua.edu.cn/simple

验证安装成功，在Python交互式环境里执行：

import requests print(requests.__version__)

能打印出版本号就说明环境OK了。另外，pip install requests会自动带上urllib3、certifi、charset_normalizer、idna这些依赖库，其中urllib3是requests的底层HTTP引擎，certifi是用来做SSL证书校验的，这些都不需要手动装。

3. requests库实战：GET、POST、Session会话的实际用法

3.1 请求方法对照

requests的API设计走的是"一个方法对应一个HTTP动词"的路线。最常用的就两个：requests.get()和requests.post()。接口测试里，PUT和DELETE用得相对少，但requests也提供了对应方法。

以GET请求为例，最典型的写法：

import requests url = "https://api.example.com/api/v1/products" params = { "page": 1, "page_size": 20, "category": "electronics" } response = requests.get(url, params=params) print(response.status_code) print(response.json())

POST请求则不同，它通常需要提交数据。开发里最常见的约定是application/json格式，requests里用json参数即可：

import requests url = "https://api.example.com/api/v1/login" payload = { "username": "tester01", "password": "Passw0rd123" } response = requests.post(url, json=payload) print(response.status_code) print(response.text)

json参数和data参数看起来差不多，但有个关键区别：json会自动把Python字典序列化成JSON字符串，并设置Content-Type: application/json；data则是按application/x-www-form-urlencoded格式传表单。如果用错了，后端可能解析不到参数，返回400错误。

3.2 响应对象里面的关键信息

发请求只是第一步，更关键的是从响应里提取信息做断言。requests的Response对象里有几个我几乎天天用的字段：

• response.status_code：HTTP状态码，200表示成功，401表示未认证，403表示权限不足，500表示服务端异常。
• response.headers：响应头，字典形式，通常用来取Content-Type、Set-Cookie等。
• response.text：响应体文本，适合直接看内容或者做正则匹配。
• response.json()：JSON反序列化后的Python字典，接口返回JSON时最常用。

有一个细节容易踩坑：response.json()如果遇到响应体不是合法JSON，会抛出requests.exceptions.JSONDecodeError。所以稳妥的做法是先判断Content-Type，或者用try/except包一层。

import requests response = requests.get("https://api.example.com/health") try: data = response.json() except requests.exceptions.JSONDecodeError: data = {"raw": response.text}

3.3 Session会话保持：登录态的正确处理方式

接口测试里最常碰到的场景就是：先登录拿Token，然后带着Token去请求业务接口。如果把Token每次都手动传进headers里，代码会非常啰嗦，还容易漏传。requests的Session对象就是为解决这个问题设计的。

Session在底层维护了一个连接池和Cookie存储。你在Session上登录一次后，后续请求会自动带上该Session持有的Cookie，还可以统一设置headers。

import requests session = requests.Session() session.headers.update({ "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64)" }) # 登录，此时Token被存储在Session的Cookie或者自定义header中 login_url = "https://api.example.com/login" login_data = {"username": "admin", "password": "123456"} response = session.post(login_url, json=login_data) # 后续请求，Session自动携带登录态 profile_url = "https://api.example.com/user/profile" profile_resp = session.get(profile_url) print(profile_resp.json())

这里有一个很实用的技巧：如果登录后返回的Token是放在响应体里的，而不是通过Set-Cookie设置的，你可以手动把Token塞进Session的默认headers里，这样后面的请求就都不用管Token的事了：

token = response.json().get("data", {}).get("token") session.headers["Authorization"] = f"Bearer {token}"

3.4 超时与重试：接口测试不能干等

接口请求默认不会设置超时时间，意味着如果后端卡死，你的测试也会一直挂起。这在自动化场景里是致命的——一个用例卡住，整个测试套件都得堵在那里。所以，所有请求都必须显式设置timeout参数：

response = requests.get(url, timeout=(3, 5))

timeout=(3, 5)的意思是连接超时3秒，读取超时5秒。这个配置比一个单一的timeout=5更精细：连接超时指建立TCP连接的时间上限，读取超时指收到响应数据的时间上限。一个请求可能连接很快，但响应很慢，分开设置能更精准地判断问题。

对于重试策略，requests本身没有内置重试机制，但可以通过urllib3的Retry配合HTTPAdapter实现。以下几点需要结合具体场景：

import requests from requests.adapters import HTTPAdapter from urllib3.util.retry import Retry session = requests.Session() retry = Retry( total=3, # 总重试次数 connect=3, # 连接失败重试次数 read=2, # 读取失败重试次数 backoff_factor=0.5, # 重试间隔 = backoff_factor * (2 ** retry_count) status_forcelist=[500, 502, 503, 504] ) adapter = HTTPAdapter(max_retries=retry) session.mount("https://", adapter)

需要强调的是，重试机制只适合幂等请求（GET类）。对于POST下单这类非幂等操作，重试可能会导致重复下单，必须谨慎设计，最好结合接口幂等键来使用，或者干脆不设置重试。

4. 搭建接口自动化框架：请求封装、断言封装与数据驱动

4.1 目录结构设计的原则

接口自动化框架不需要多花哨，但结构要清晰，不然用例一多就成一锅粥。我常用的目录结构如下：

api_test/ ├── config/ │ ├── __init__.py │ └── settings.py # 环境配置、全局变量 ├── common/ │ ├── __init__.py │ ├── http_client.py # requests二次封装 │ ├── assert_utils.py # 断言封装 │ ├── read_data.py # 数据读取 │ └── logger.py # 日志配置 ├── testcases/ │ ├── __init__.py │ ├── test_login.py # 登录模块用例 │ ├── test_order.py # 订单模块用例 │ └── test_pay.py # 支付模块用例 ├── data/ │ ├── login_cases.yaml # 登录用例数据 │ └── order_cases.json # 订单用例数据 ├── reports/ │ └── 2024-05-18/ # 按日期存放测试报告 └── requirements.txt

这种结构的核心思路是：配置、公共方法、用例、数据、报告分层隔离。修改环境配置不用动用例，新增用例不用碰公共代码。

4.2 请求封装：把requests再包一层

直接在每个用例里面调requests.post()不是不行，但问题很多：环境地址一变，所有用例都要改；日志记录不统一，出了问题不好排查；Token等公共逻辑散落在各处，维护成本高。所以我习惯封装一个HttpClient类。

import requests import logging from config.settings import BASE_URL, GLOBAL_TIMEOUT logger = logging.getLogger("api_test") class HttpClient: def __init__(self, base_url=BASE_URL): self.base_url = base_url.rstrip("/") self.session = requests.Session() self.timeout = GLOBAL_TIMEOUT def set_token(self, token): """设置全局Token""" self.session.headers["Authorization"] = f"Bearer {token}" def request(self, method, url, **kwargs): """统一的请求入口，所有请求都走这里""" full_url = f"{self.base_url}/{url.lstrip('/')}" kwargs.setdefault("timeout", self.timeout) if "verify" not in kwargs: kwargs["verify"] = False # 测试环境关掉证书校验 logger.info(f"请求: {method.upper()} {full_url}") logger.info(f"参数: {kwargs.get('json') or kwargs.get('data') or kwargs.get('params')}") response = self.session.request(method, full_url, **kwargs) logger.info(f"响应: {response.status_code} - {response.text[:200]}") return response def get(self, url, **kwargs): return self.request("GET", url, **kwargs) def post(self, url, **kwargs): return self.request("POST", url, **kwargs)

封装的核心价值有两点：一是统一入口，任何请求都能打日志、做统计；二是全项目共享配置，比如verify=False在测试环境只需要配置一次，切到生产环境时只需调整settings里的开关，不用到处改代码。

注意，verify=False会产生一个InsecureRequestWarning的警告。测试环境用自签名证书时没法避免，但可以通过urllib3.disable_warnings()屏蔽告警，让日志更干净。

4.3 断言封装：状态码之外还要校验业务码

一个常见的误区是只断言HTTP状态码是不是200。实际做过接口自动化的人都知道，200只代表HTTP请求到达了服务端，业务是否成功还要看响应体里的业务状态码。我遇到过不止一次，接口返回200但code字段却是5000，业务上就是失败的。

所以断言的封装至少要覆盖三层：

• HTTP状态码：检查网络层和路由是否正确
• 业务状态码：检查后端业务逻辑是否成功
• 关键业务字段：检查核心数据是否符合预期

class AssertUtils: @staticmethod def assert_response(response, expected_status=200, expected_biz_code=None, expected_fields=None): assert response.status_code == expected_status, \ f"HTTP状态码不符, 期望{expected_status}, 实际{response.status_code}" data = response.json() if expected_biz_code: biz_code = data.get("code") assert biz_code == expected_biz_code, \ f"业务状态码不符, 期望{expected_biz_code}, 实际{biz_code}" if expected_fields: for key, value in expected_fields.items(): actual = data.get("data", {}).get(key) assert actual == value, \ f"字段{key}不符, 期望{value}, 实际{actual}"

实际项目中，断言的粒度需要根据接口的重要程度来设计。核心字段必须断言，非核心字段不要过度断言，否则接口一有合理变动用例就会误报，测试维护成本飙升。

4.4 数据驱动：把用例数据从代码里抽离

代码写死数据的做法只适合探索测试。真正跑回归的用例集，数据必须外置，方便产品和测试随时调整测试数据而不改代码。我常用YAML文件来管理用例数据，因为YAML可读性好，嵌套结构也清晰。

以登录接口为例，写一个login_cases.yaml：

- name: 登录成功 method: POST url: /api/v1/login data: username: "admin" password: "123456" expected_status: 200 expected_biz_code: 0 - name: 密码错误 method: POST url: /api/v1/login data: username: "admin" password: "wrong_pass" expected_status: 200 expected_biz_code: 1001

然后配合pytest实现参数化：

import pytest import yaml from common.http_client import HttpClient from common.assert_utils import AssertUtils client = HttpClient() def load_login_cases(): with open("data/login_cases.yaml", "r", encoding="utf-8") as f: return yaml.safe_load(f) @pytest.mark.parametrize("case", load_login_cases()) def test_login(case): response = client.post( case["url"], json=case.get("data", {}) ) AssertUtils.assert_response( response, expected_status=case["expected_status"], expected_biz_code=case.get("expected_biz_code") )

数据驱动的核心思路是让一个测试函数变成"执行器"，数据的扩展不增加代码量。新增一个用例场景，只需要在YAML里加一段配置，测试代码一行都不用改。

5. 业务实战：登录鉴权、Token传递与跨接口链路测试

5.1 登录接口与Token提取

接口自动化的第一个坎往往是登录。登录方式多种多样，有基于Cookie会话的，有基于JWT Token的，也有OAuth2.0的。以一个典型的JSON登录为例，登录成功后的响应体往往长这样：

{ "code": 0, "message": "success", "data": { "token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VyX2lkIjoxMjMsImV4cCI6MTcxNjAwMDAwMH0.signature" } }

我在框架里处理Token的逻辑是：在所有依赖登录的用例执行之前，先通过一个session级别的fixture完成登录，并把Token注入HttpClient实例，从而让所有用例自动携带Token。

import pytest from common.http_client import HttpClient @pytest.fixture(scope="session", autouse=True) def login_fixture(): client = HttpClient() login_resp = client.post("/api/v1/login", json={ "username": "admin", "password": "123456" }) assert login_resp.status_code == 200 token = login_resp.json()["data"]["token"] client.set_token(token) return client

这里注意scope="session"的含义：整个测试会话只执行一次登录，所有用例共用这个登录态。这样既节省了重复登录的开销，也保证了用例之间的连贯性。

5.2 跨接口的业务链路：下单一支付一查询

接口自动化真正的价值在于串联链路。单测一个接口，问题还算好定位；一旦涉及多个接口之间的数据传递，才能模拟出真实用户的操作路径。以订单支付链路为例：

1. 创建订单，拿到order_id
2. 对订单发起支付，需要order_id和支付方式
3. 查询订单状态，确认订单已变成"已支付"

这三个接口之间是有数据依赖的，第二个和第三个接口都依赖第一个接口返回的order_id。处理这种依赖，我通常用一个context字典的顺序执行方式：

def test_order_payment_flow(): client = HttpClient() # 登录 login_resp = client.post("/api/v1/login", json={"username": "admin", "password": "123456"}) token = login_resp.json()["data"]["token"] client.set_token(token) # Step 1: 创建订单 order_resp = client.post("/api/v1/order/create", json={ "product_id": 1001, "quantity": 1, "address": "测试地址" }) assert order_resp.status_code == 200 order_id = order_resp.json()["data"]["order_id"] # Step 2: 支付订单 pay_resp = client.post("/api/v1/order/pay", json={ "order_id": order_id, "pay_type": "alipay" }) assert pay_resp.status_code == 200 assert pay_resp.json()["data"]["pay_status"] == "success" # Step 3: 查询订单状态 query_resp = client.get(f"/api/v1/order/detail?order_id={order_id}") assert query_resp.status_code == 200 assert query_resp.json()["data"]["order_status"] == "paid"

这段代码要传达的核心思想是：接口链路的测试要按照用户真实操作顺序来组织，每一步的数据都要从前一步的响应中提取。如果第2步失败，用例会在第2步中断并抛错，你就能准确定位是哪一段出了问题。但是，如果这里用pytest.mark.parametrize把三段拆成三个独立用例，order_id的传递就成了难题，这也是我选择顺序执行方式的原因。

5.3 加密接口的应对思路

不少金融和政企项目在接口层面做了数据加密，常见的是AES+RSA组合。测试这种接口，关键点是和开发对齐加密逻辑，确认用的是AES的哪种模式（CBC、ECB或GCM），密钥如何获取。

以AES-CBC为例，加密和解密的代码可以这样写：

from Crypto.Cipher import AES from Crypto.Util.Padding import pad, unpad import base64 key = b"0123456789abcdef" # 16字节密钥 iv = b"abcdef9876543210" # 16字节偏移量 def aes_encrypt(data: str) -> str: cipher = AES.new(key, AES.MODE_CBC, iv) encrypted = cipher.encrypt(pad(data.encode("utf-8"), AES.block_size)) return base64.b64encode(encrypted).decode("utf-8") def aes_decrypt(data: str) -> str: cipher = AES.new(key, AES.MODE_CBC, iv) decrypted = unpad(cipher.decrypt(base64.b64decode(data)), AES.block_size) return decrypted.decode("utf-8")

加密接口的测试要格外注意：断言时不要直接拿加密后的响应体做全文匹配，而是先解密再断言业务字段。调试阶段可以写一个独立的解密脚本，单独验证接口返回数据的正确性。

6. 测试报告与持续集成：单机跑通还要能定时执行

6.1 pytest集成与报告生成

接口自动化项目我基本全用pytest作为测试框架，因为它和requests配合起来很自然，fixture机制处理登录态和资源清理非常方便，参数化支持又极其友好。运行用例加上-v参数可以看到每个用例的执行情况。

生成HTML报告最简单的方式是pytest-html：

pip install pytest-html pytest testcases/ -v --html=reports/report.html --self-contained-html

--self-contained-html参数很关键：它会把CSS和JS内嵌到HTML文件中，生成单一文件报告，分享给别人时不需要附带额外的资源目录。

如果你想要更专业的报告，可以用Allure。Allure报告从用例步骤、历史趋势到缺陷分类都做得很好，适合团队展示和长期统计。基本用法：

pip install allure-pytest pytest testcases/ -v --alluredir=reports/allure-results allure serve reports/allure-results

6.2 日志收集：测试失败的定位利器

报告能告诉你失败在哪，但没法告诉你为什么失败。所以我建议在框架里加上日志模块，把每个请求的URL、请求参数、响应状态码、响应体关键内容记录下来。日志级别用INFO，失败时在report里附上对应的日志文件路径。

import logging logger = logging.getLogger("api_test") logger.setLevel(logging.INFO) if not logger.handlers: handler = logging.FileHandler("logs/api_test.log", encoding="utf-8") formatter = logging.Formatter("%(asctime)s - %(levelname)s - %(message)s") handler.setFormatter(formatter) logger.addHandler(handler)

在HttpClient的请求方法里，我前面已经加了日志输出。这样一次完整的请求链路在日志里能清晰看到：发什么、收什么、断在哪。实际排查问题时，日志比报告好用得多。

6.3 Jenkins定时任务配置

测试写好了要在CI环境里跑，我用的最多的是Jenkins。在Jenkins里新建一个自由风格项目，配置Git仓库地址，构建步骤选"执行shell"或"执行Windows批处理命令"，然后填入：

cd ${WORKSPACE} pip install -r requirements.txt pytest testcases/ -v --html=reports/report.html --self-contained-html

然后配置"构建后操作"里的"Publish HTML reports"，把reports/report.html设置成展示页面。最后在"构建触发器"里勾选"定时构建"，填入H 2 * * *表示每天凌晨2点跑一次。

接口自动化跑定时任务有两个好处：一是每天早晨到公司就能看到昨晚的回归结果，有问题早上就处理；二是对线上环境做持续健康巡检，接口挂了你可能是第一个知道的人。

7. 高频报错排查实录：429、超时、SSL与编码问题

7.1 429 Too Many Requests：请求频率撞上服务端限流

最近在跑一个接口巡检脚本时，频繁遇到429 Too Many Requests。这个状态码的意思是请求太频繁，触发了服务端的限流策略。我的第一反应不是改代码，而是去确认限流规则：是单IP限流还是账号维度限流？单位时间窗口是多少？分接口限流还是全局限流？

排查清楚后，对症下药有几种方案：

• 加延时：简单粗暴，如果允许降速，在每次请求前time.sleep(1)就把频率降下来了。
• 重试退避：如果确实需要用高频率跑，就要加上带退避的重试机制，第一次失败等1秒重试，第二次等2秒，第三次等4秒，指数退避能有效降低与限流策略的硬碰硬。
• 分布式来源IP：当服务端按IP限流时，用多台执行机或代理池分散请求来源。

import time import random def request_with_backoff(session, method, url, max_retries=3, **kwargs): for attempt in range(max_retries): response = session.request(method, url, **kwargs) if response.status_code == 429: wait_time = 2 ** attempt + random.uniform(0, 1) time.sleep(wait_time) continue return response return response # 最后还是一个429就返回给调用方判断

7.2 连接超时与Proxy环境变量干扰

ConnectionError几乎是每个接口测试人都会遇到的报错。常见原因有三类：

• 网络不通：目标服务器IP不可达、端口没开放。
• 代理干扰：操作系统设置了HTTP_PROXY或HTTPS_PROXY环境变量，requests默认会读取这些代理配置，导致请求走了代理但代理不可用。
• 目标服务没启动：后端服务挂了，TCP连接直接被拒绝。

排查顺序我一般是：先ping目标服务器，再telnet端口通不通，然后用curl -v裸测一下接口，最后看Python代码里的代理配置。

# 临时清除代理环境变量 unset HTTP_PROXY HTTPS_PROXY ALL_PROXY

如果公司环境必须走代理，就在requests里显式指定：

proxies = { "http": "http://proxy.example.com:8080", "https": "http://proxy.example.com:8080" } response = requests.get(url, proxies=proxies)

7.3 SSLError：证书校验引发的"信任危机"

测试环境用自签名HTTPS证书时，requests.get()默认会校验证书，遇到不受信任的证书会抛出requests.exceptions.SSLError。解决方式有两种，安全级别不同。

方案一（测试环境快速解决）：

response = requests.get(url, verify=False)

方案二（捕获异常并忽略特定场景）:

import urllib3 urllib3.disable_warnings(urllib3.exceptions.InsecureRequestWarning) response = requests.get(url, verify=False)

生产环境或涉及敏感数据的接口，我不建议关闭证书校验，而应该把证书文件下载下来，通过verify=/path/to/cert.pem传入。这是安全底线问题，测试环境可以妥协，生产环境不能。

7.4 中文乱码与UnicodeEncodeError

接口返回的中文响应体在控制台打印乱码是最常见的小问题。大部分原因出在控制台编码和响应体编码不一致。requests会从HTTP头里的Content-Type字段自动判断编码，但如果接口没返回charset参数，requests默认可能是ISO-8859-1，中文自然就乱码了。

解决方案是手动设置编码：

response = requests.get("https://api.example.com/user/info") response.encoding = "utf-8" print(response.text)

如果已经拿到response.text发现乱码，可以用response.content拿到字节流，然后手动解码：

content = response.content.decode("utf-8", errors="ignore")

日志文件里写中文时，如果遇到UnicodeEncodeError，检查两点：FileHandler是否设置了encoding="utf-8"，以及写入的字符串是否混入了不可编码的emoji。

8. 框架维护与扩展：从能跑到跑得舒服

写到这里，你已经能搭建出一套可用的接口自动化框架了。最后分享几个我在维护阶段觉得特别重要的经验。

第一，不要过度设计。框架够用就行，不要一开始就引入复杂的数据工厂、多环境引擎、动态参数注入这些模块。先把核心链路跑通，让团队看到价值，后续再根据需要渐进增强。

第二，用例的独立性比减少重复代码更重要。两个用例如果相互依赖，其中一个失败会导致另一个也失败，排查问题时会很困惑。设计用例时尽量让每个用例可以独立运行。

第三，环境切换要配置化。测试环境、预发布环境、生产环境的地址和账号信息放到配置里，不要写死在代码中。我用的是config/settings.py加环境变量覆盖的方式，切换环境时只需改一个环境变量。

第四，定期清理测试数据。接口自动化跑久了，数据库里会积累大量测试产生的脏数据。我在项目中加了数据清理脚本，每天定时执行，避免测试数据干扰真实业务。

最后再提一个小技巧：框架跑完以后，可以把测试结果推送到企业微信或者飞书群，用webhook发一条消息，包含通过率、失败用例、报告链接。这样整个研发团队都能看到自动化测试的产出，而不是只有测试自己知道。这也是让接口自动化价值被看见的一个有效方式。