核心是确保验证信息稳定、安全、可维护：Bearer Token须从环境变量读取并校验非空，Basic Auth用HTTPBasicAuth封装且凭据来源保密，Cookie登录必须复用Session对象，断言需兼顾业务主干与容错性（如状态码范围判断、动态字段模糊匹配、敏感信息脱敏）。
带验证信息的 API 自动化测试，核心不是“能不能发请求”，而是“怎么让验证信息稳定、安全、可维护地参与请求”。用 requests 做这事，关键在认证方式选对、凭据不硬编码、错误响应不忽略。
Bearer Token 怎么安全传入 headers？
多数现代 API（如 RESTful 后端、GitHub、GitLab）用 Bearer Token 认证。直接写死在 headers 里是常见错误，既不安全也不利于多环境切换。
- Token 应从环境变量读取：
os.getenv("API_TOKEN")，本地用.env文件配合python-dotenv加载 - 必须检查是否为空，避免发
Authorization: Bearer None导致 401：if not token: raise ValueError("API_TOKEN is missing") - Token 过期时服务器通常返回
401 Unauthorized或403 Forbidden，不要只看状态码 2xx 就认为成功
示例片段：
import requests
import os
<p>token = os.getenv("API_TOKEN")
if not token:
raise ValueError("API_TOKEN is missing")</p><p>headers = {"Authorization": f"Bearer {token}", "Content-Type": "application/json"}
response = requests.get("<a href="https://www.php.cn/link/93a819cbd635bd1505ef0f804c21cc2a">https://www.php.cn/link/93a819cbd635bd1505ef0f804c21cc2a</a>", headers=headers)Basic Auth 的用户名密码怎么避免明文暴露？
requests.auth.HTTPBasicAuth 是标准解法，但它只是封装了 base64 编码，**不加密**——重点在于传输过程走 HTTPS，且凭据来源不能写死。
立即学习“Python免费学习笔记（深入）”；
- 别用字符串拼接
"username:password"再手动 base64，易出错；直接用requests.auth.HTTPBasicAuth(user, pwd) - 用户名/密码同样从环境变量或密钥管理服务（如 HashiCorp Vault）获取，测试脚本里绝不出现
"admin:123456" - 某些老系统要求 Basic Auth 但响应头不含
WWW-Authenticate，此时requests不会自动重试，需手动处理 401 后重新发请求
Cookie 登录态如何复用而不重复登录？
面向 Web 页面的 API（比如内部后台系统）常依赖 Cookie 维持会话。每次新建 requests.Session() 实例才能自动管理 Cookie，否则每个 requests.get() 都是无状态新请求。
- 登录接口返回
Set-Cookie后，后续请求必须复用同一个session对象，不能换requests.get(...) - 登录失败时，有些系统仍返回 200 但响应体含错误字段（如
{"success": false, "msg": "invalid credentials"}），得解析 body 判断，不能只看 status_code - Session 超时后再次请求可能返回 302 跳转到登录页，或返回 HTML 片段——这时
response.headers.get("Content-Type")通常是"text/html"，可据此识别异常
示例：
session = requests.Session()
login_resp = session.post("https://intranet.example.com/login", data={"u": user, "p": pwd})
# 检查登录是否真成功，不只是 status_code == 200
if "dashboard" not in login_resp.url:
raise RuntimeError("Login failed or redirected unexpectedly")
<h1>后续请求自动携带 Cookie</h1><p>user_resp = session.get("<a href="https://www.php.cn/link/806247394ef755e46009b2856ba64e9c">https://www.php.cn/link/806247394ef755e46009b2856ba64e9c</a>")如何让测试断言既覆盖业务逻辑又不脆弱？
自动化测试崩在非业务点上最浪费时间：比如字段顺序变化、多余空格、时间戳精度浮动。断言要抓主干，放细节。
- 优先用
response.json().get("data")取关键字段，而不是response.json()["data"]——避免 KeyError 中断整个测试 - 对时间字段（如
created_at）不做精确相等判断，改用datetime.fromisoformat(...)解析后比较是否在合理误差范围内（±5 秒） - 状态码断言写成
assert response.status_code == 200，但更稳妥的是assert response.status_code in (200, 201)，兼容不同成功码 - 敏感字段（如 token、password）在日志或调试输出中必须脱敏，
print(response.json())前先深拷贝并抹除 key
真正难的不是构造一个带认证的请求，而是让这套逻辑在 CI 环境跑得稳、换环境配得快、出问题时能快速定位是凭据失效、接口变更，还是断言写得太死。每层验证都得有 fallback 和明确报错路径，不然一次 401 就得翻三遍日志。
