测试文件下载

测试文件下载，下载第一刀就得砍在这种地方。测试很多人拿到需求就直奔后端接口，文件用 Postman 跑通了就以为万事大吉。下载浏览器里点一下，测试文件没出来，文件再回头怀疑接口超时、下载跨域、Content-Type 不对。其实前端那几行代码才是重灾区。

后端那边也不省心。有个 Spring Boot 接口返回文件，`Content-Disposition` 头里文件名带了中文，没做 URL 编码。Chrome 下载下来文件名变成一串百分号加乱码，Firefox 更绝，直接截断成“download”。开发说“我本地是好的”——他本地用的英文文件名。这种坑，测试环境不专门准备中文名文件根本踩不到。

还有更隐蔽的。接口返回 200，响应体也是完整的文件流，但 `Content-Length` 和实际字节数对不上。浏览器下到一半停了，文件打不开。抓包看响应，数据确实发完了，但服务器配置里 `Content-Length` 被某个中间件改过。这种问题，不对比下载文件的 MD5 和源文件，光看“下载成功”的提示根本发现不了。

我自己的习惯是，测下载功能先分三层。第一层，前端触发逻辑：按钮点击有没有发请求，请求参数对不对，`download` 属性拼写、Blob 处理、URL 释放。第二层，HTTP 协议层：状态码、`Content-Type`、`Content-Disposition`、`Content-Length`、文件名编码。第三层，文件本身：大小、格式、MD5、打开后内容是否完整。三层都过了，才敢说这个下载功能是通的。

说个具体的。上个月测一个 PDF 导出，接口返回的 `Content-Type` 是 `application/octet-stream`，浏览器不认，直接当二进制流下了个没后缀的文件。开发说“我设了 `.pdf` 后缀啊”，但他设的是 `Content-Disposition` 里的 filename，没改 `Content-Type`。Chrome 认 `Content-Type` 优先，后缀被忽略。改成 `application/pdf` 之后，浏览器才正常预览或下载。这种细节，不亲手点一遍根本不知道。

工具方面，别只依赖 Postman。它默认会把响应保存成文件，但不会模拟浏览器的下载行为。用 curl 加 `-OJ` 参数能测 `Content-Disposition`，用浏览器开发者工具的 Network 面板看实际响应头，用 `diff` 或 `certutil -hashfile` 对比文件哈希。三管齐下，比单纯点按钮靠谱得多。

最后说个反直觉的。有些下载失败不是技术问题，是产品逻辑没定义清楚。用户点了下载，文件是生成了，但后端异步任务还没跑完，接口直接返回“文件生成中”。前端拿到这个 JSON 当文件流处理，下载下来一个 `.json` 文件，打开是错误提示。测试这时候要做的不是报 bug，是拉着产品把“异步下载”的交互流程定清楚——轮询、回调、还是直接同步生成。技术测试解决不了产品定义的模糊。

下载功能看着简单，链路却长。前端、网络、后端、文件系统，哪一环松了都掉链子。测的时候别只盯着“能不能下”，多问一句“下下来对不对”。一个字节的偏差，用户拿到手里就是打不开的废文件。