pytest中应使用io.BytesIO构造内存文件对象并传入files参数，避免磁盘I/O；files值须为(filename, file_obj, content_type)三元组，文件对象以"rb"模式打开；额外字段放data参数；需验证存储结果而非仅HTTP状态码。
pytest里怎么模拟multipart/form-data上传文件
直接用requests.post发原始二进制数据会绕过multipart边界生成逻辑，导致后端解析失败。必须让requests自己构造符合规范的multipart/form-data请求体。
正确做法是把文件对象传给files参数：
import requests
<p>with open("test.pdf", "rb") as f:
response = requests.post(
"<a href="https://www.php.cn/link/9782c50d0c747e4c0be05fc786a7709c">https://www.php.cn/link/9782c50d0c747e4c0be05fc786a7709c</a>",
files={"file": ("report.pdf", f, "application/pdf")},</p><h1>注意：不要同时传 data 或 json 参数，会冲突</h1><pre class="brush:php;toolbar:false;">)
-
files值是三元组：(filename, file_obj, content_type)，缺一不可；省略content_type可能导致后端拒绝或误判类型 - 文件对象必须以
"rb"模式打开，否则requests可能报TypeError: expected bytes, got str - 如果接口还要求额外字段（如
user_id），应放在data参数里，不能塞进files
pytest中如何复用上传逻辑又不污染测试环境
每次测试都真实读写磁盘文件，既慢又难控制内容。更稳妥的做法是用io.BytesIO构造内存文件对象，避免依赖本地路径和文件系统状态。
立即学习“Python免费学习笔记（深入）”；
import io import pytest <p>@pytest.fixture def sample_pdf():</p><h1>生成一个极简但合法的 PDF 字节流（仅 header + trailer）</h1><pre class="brush:php;toolbar:false;">return io.BytesIO(b"%PDF-1.0\n1 0 obj<</Type/Catalog>>endobj\nxref\n0 2\n0000000000 65535 f \n0000000009 00000 n \ntrailer<</Size 2/Root 1 0 R>>\nstartxref\n123\n%%EOF")
def test_upload_valid_pdf(client, sample_pdf): response = client.post( "/upload", files={"file": ("test.pdf", sample_pdf, "application/pdf")} ) assert response.status_code == 200
- 用
BytesIO替代open()，确保每个测试拿到“干净”的文件对象（不会因上一个测试seek到末尾而读空） - fixture返回的是
BytesIO实例，不是字节串——传错类型会导致requests静默失败或报ValueError: File-like object has no .read() method - 如果需要测试不同大小/类型的文件，建议用
pytest.mark.parametrize驱动多个BytesIOfixture变体，而不是硬编码多份文件
为什么上传测试总卡在400或413错误
400通常是Content-Type缺失或files结构不对；413则是Nginx/uWSGI等中间件限制了请求体大小，默认往往只有1MB左右，远小于实际业务文件。
- 检查响应头是否含
Content-Type: multipart/form-data; boundary=...——没有说明requests根本没走files逻辑 - 用
curl -v对比真实请求与pytest发出的请求，重点关注Content-Length和boundary是否一致 - Django/Flask测试客户端（如
test_client）对files支持不一致：Django的client.post(..., data={...}, format="multipart")要加format；Flask的test_client.post(..., data={"file": (io.BytesIO(...), "x.txt")})则不需要额外参数 - 若用uWSGI，需确认
client_max_body_size（Nginx）和limit-post（uWSGI）都调大，否则pytest能发出去，服务端直接拒收
上传成功后怎么验证后端存储结果
只测HTTP状态码不够——文件可能被保存到错误路径、重命名出错、或元数据丢失。得绕过HTTP层，直接检查后端实际落盘或数据库记录。
例如使用临时目录+tmp_path fixture：
import tempfile
from pathlib import Path
<p>@pytest.fixture
def upload_dir(tmp_path):
d = tmp_path / "uploads"
d.mkdir()
return d</p><p>def test_file_saved_with_correct_name(upload_dir, client):
with io.BytesIO(b"hello") as f:
client.post("/upload", files={"file": ("mydoc.txt", f, "text/plain")})</p><pre class="brush:php;toolbar:false;">saved = list(upload_dir.iterdir())
assert len(saved) == 1
assert saved[0].name == "mydoc.txt" # 验证原始文件名未被篡改
assert saved[0].read_text() == "hello"
- 别依赖
os.getcwd()或硬编码/tmp——不同CI环境权限和清理策略不同，tmp_path由pytest自动管理生命周期 - 如果后端用云存储（S3/MinIO），测试时应mock掉
boto3.client或注入测试用的LocalStackendpoint，而非真传到线上桶 - 注意时区和文件修改时间：测试断言
stat().st_mtime容易因系统精度抖动失败，优先验证内容和路径
文件上传测试最易忽略的是边界条件：空文件、超长文件名、含特殊字符（如../或áéíóú.pdf）的文件名、重复上传同名文件时的覆盖策略——这些几乎不会在happy path里暴露，但上线后立刻出问题。
