requests发送请求时参数位置错误会导致静默失败：GET用params、POST表单用data、POST JSON用json参数；pytest断言需解析JSON并安全取值，用fixture管理token，设置timeout和重试机制保障稳定性。
requests 发送 GET/POST 时，参数传错位置会静默失败
很多人把 params 和 data 搞混，结果接口返回 200 但数据不对，或者直接 400。GET 请求的查询参数必须走 params，POST 的表单体才用 data；如果后端要 JSON，得用 json= 参数（它会自动设 Content-Type: application/json 并序列化）。
常见错误现象：requests.post(url, data={"a": 1}) 发过去是 a=1（urlencoded），不是 {"a": 1}；而 requests.post(url, json={"a": 1}) 才对。
- GET 请求：只用
params，别塞data或json - POST 表单（如登录页）：用
data=dict(...)或data="key=val&..." - POST JSON（绝大多数 REST API）：直接传
json=dict(...)，别自己json.dumps()+headers - 上传文件：用
files={"file": open("x.txt", "rb")}，此时别再传json或data
pytest 里怎么断言响应结构和字段值
光看 response.status_code == 200 不够，很多接口返回 200 却带错误信息（比如 {"code": 4001, "msg": "token expired"}）。得先解析 JSON，再逐层断言关键字段。
容易踩的坑：response.json() 在非 JSON 响应（比如返回 HTML 错误页、空响应、502）时直接抛 JSONDecodeError，pytest 用例就崩了，不会进断言逻辑。
立即学习“Python免费学习笔记（深入）”；
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
- 加
try/except包住response.json()，或用response.text先看原始内容 - 用
assert "data" in r.json()比assert r.json()["data"]更安全（避免 KeyError） - 检查嵌套字段：推荐用
assert r.json().get("data", {}).get("id") == 123，不硬点链式调用 - 类型校验别省：比如
assert isinstance(r.json()["count"], int)，防止后端返回字符串 "0"
pytest 运行多个接口用例时，如何管理 token 和状态依赖
登录接口返回 token，后续请求要带在 Authorization 头里——但 pytest 默认每个测试函数相互隔离，不能靠全局变量传 token，否则并发跑会乱。
正确做法是用 fixture，把登录逻辑抽成一个带 scope="session" 或 "module" 的 fixture，让多个测试函数复用同一个 token（注意过期时间）。
- 别在测试函数里重复调登录接口，浪费时间还可能触发风控
- fixture 返回 token 后，在其他测试函数参数里声明它，pytest 自动注入
- 如果 token 有有效期，加个简单缓存逻辑（比如记录获取时间和值，5 分钟内直接复用）
- 敏感信息如密码，从
conftest.py读环境变量或配置文件，别硬编码在测试里
断言响应时间超时、重试失败这些非业务逻辑怎么加
接口慢不等于错，但超过 800ms 就该告警；网络抖动导致偶发 502，重试 2 次更合理——这些不属于业务断言，但影响稳定性判断。
requests 本身支持 timeout 参数，但默认不抛异常（除非连接失败），超时后只是响应慢；retry 机制得自己加，别指望 pytest 自动重试失败用例（那掩盖问题）。
- 强制设
timeout=(3, 8)：3 秒连上，8 秒内必须返回，超时抛requests.exceptions.Timeout - 用
urllib3.util.Retry配合requests.adapters.HTTPAdapter实现连接/读取重试（注意别对 POST 无脑重试） - 响应时间断言写成
assert response.elapsed.total_seconds() ，比打印日志更可靠 - 别在测试里用
time.sleep()等异步结果，改用轮询 + 超时（比如每秒查一次状态，最多等 30 秒）
真实场景里，token 刷新逻辑、分页循环拉取、二进制响应（如 PDF 文件校验）、重定向跳转是否允许……这些细节一旦漏掉，自动化就只能“看起来在跑”，实际没守住质量。得按接口文档一条条对齐，而不是只测 happy path。
