本文深入解析了Python测试中requests库因SSL证书验证失败而抛出SSLError的常见场景与科学应对策略，强调避免粗暴全局禁用验证或逐处添加verify=False，而是通过pytest session级fixture统一管控SSL行为——如动态设置自定义CA证书路径、安全禁用警告、或精准注入不验证适配器；同时指出不同HTTP库（如httpx、urllib、boto3）需差异化处理，并特别提醒CI环境中证书缺失的隐蔽性问题及“开发可宽松、CI须严格”的分环境配置原则，帮助开发者在保障测试稳定性的同时不牺牲安全性。

为什么 pytest 运行时 requests 报 SSLError: certificate verify failed

这不是 pytest 本身的问题，而是你代码里或其依赖（比如用 requests.get() 调用内部 HTTPS 接口、mock 未覆盖的第三方请求）触发了 Python 默认的 SSL 验证。系统找不到可信 CA 证书，或目标服务用了自签名/过期/私有 CA 证书，requests 就会直接抛错中断测试。

常见于：本地开发环境调用测试用的 mock server（如 https://localhost:8001）、公司内网 HTTPS 服务、Docker 容器中缺失 CA 证书包。

• 别改全局 urllib3.disable_warnings() —— 它只抑制日志，不解决连接失败
• 别在每个 requests 调用加 verify=False —— 测试逻辑污染严重，且会漏掉真正该报错的场景
• pytest 的 requests 钩子不存在 —— requests 没提供 pytest 原生钩子，得靠 fixture 或 session 级配置

用 pytest fixture 统一控制 requests 的 verify 行为

最干净的方式是定义一个作用域为 session 的 fixture，在测试启动时替换 requests.Session.verify 的默认值，或注入自定义 verify 路径。这样所有通过 requests 发出的请求（包括间接调用）都会受控。

示例（放在 conftest.py 中）：

import pytest
import requests
<p>@pytest.fixture(scope="session", autouse=True)
def disable_ssl_verification():</p><h1>仅用于开发/测试环境，切勿在 CI 或生产测试中启用</h1><pre class="brush:php;toolbar:false"><code>requests.packages.urllib3.disable_warnings()
requests.Session.verify = False</code>

如果需要指定证书路径（比如你有公司根证书 /etc/ssl/certs/company-ca.pem）：

@pytest.fixture(scope="session", autouse=True)
def set_custom_ca_bundle():
    import os
    os.environ["REQUESTS_CA_BUNDLE"] = "/etc/ssl/certs/company-ca.pem"
    # 或直接赋值给 Session 类（更可靠）
    requests.Session.verify = "/etc/ssl/certs/company-ca.pem"

• 务必加 autouse=True，否则 fixture 不会自动生效
• scope="session" 确保整个测试会话只设置一次，避免重复覆盖
• 不要在测试函数里手动改 requests.Session.verify —— 它是类属性，改了会影响后续所有请求，包括其他测试用例

requests.verify=False 为什么有时仍报 SSL 错误？

因为有些库绕过了 requests.Session，比如直接用 urllib.request.urlopen()、httpx、或底层用 ssl.create_default_context() 的 SDK（如 boto3、aiobotocore）。此时仅改 requests 不够。

通用兜底方案（仍放 conftest.py）：

import ssl
from urllib3.util.ssl_ import create_urllib3_context
<h1>禁用所有 urllib3 发起的 SSL 验证（requests 底层依赖它）</h1><p>try:
_create_default_https_context = ssl._create_default_https_context
ssl._create_default_https_context = ssl._create_unverified_context
except AttributeError:</p><h1>Python < 2.7.9</h1><pre class="brush:php;toolbar:false"><code>pass</code>

强制 urllib3 使用非验证上下文

class CustomHTTPAdapter(requests.adapters.HTTPAdapter): def init_poolmanager(self, *args, *kwargs): kwargs['cert_reqs'] = 'CERT_NONE' return super().init_poolmanager(args, **kwargs)

@pytest.fixture(scope="session", autouse=True) def use_insecure_adapter(): session = requests.Session() session.mount('https://', CustomHTTPAdapter())

注意：这不会自动替换 pytest 全局 Session，需配合 monkeypatch 或显式使用该 session

• 第一段（ssl._create_default_https_context 替换）影响面最广，但属于“核弹级”操作，慎用于共享测试环境
• 第二段 CustomHTTPAdapter 更精准，但只对显式使用该 Session 实例的请求生效
• 如果你用的是 httpx，得单独配 httpx.Client(verify=False) 或设环境变量 SSL_NO_VERIFY=1

CI 环境中证书问题更隐蔽，优先检查这些点

Docker 镜像、GitHub Actions runner、GitLab CI 的 Alpine/Ubuntu 基础镜像常缺少完整 CA 证书包，导致 verify=True 时连公网 API（如 https://httpbin.org）都失败。

• Alpine 镜像：运行 apk add --no-cache ca-certificates 并执行 update-ca-certificates
• Debian/Ubuntu：确保安装了 ca-certificates 包，且 /etc/ssl/certs/ca-certificates.crt 存在且非空
• GitHub Actions：Ubuntu runner 默认有证书，但自定义 Docker container 可能没继承；用 run: openssl version -d 查看 OpenSSL 默认 cert 目录
• 永远不要在 CI 中设 verify=False —— 这会让证书过期、域名不匹配等真实问题被掩盖

真正难处理的不是怎么关掉验证，而是如何让测试既跑得通，又不丧失对证书异常的感知能力 —— 所以推荐分环境配置：本地开发允许 verify=False，CI 必须走真实证书链校验，并把证书路径纳入构建流程管理。

理论要掌握，实操不能落！以上关于《解决Python测试SSL证书错误\_pytest request钩子配置方法》的详细介绍，大家都掌握了吧！如果想要继续提升自己的能力，那么就来关注golang学习网公众号吧！