测试文件生成完整方案：普通文件、可播放视频与可显示图片

测试文件到底怎么生成，这里我摸索出了一套完整方案。尤其是需要"可播放的视频"或"可正常显示的图片"时，不能简单拿随机字节去填充，里面有不少细节坑。

之所以想写这篇，是因为上周帮别人搞一个上传接口的压测，对方给的需求只有一句"给我准备几个10MB、50MB的文件"。我随手在Linux上敲了dd if=/dev/zero of=test.bin bs=1M count=10生成了10MB文件。结果文件丢给开发后，对方说上传到系统里被格式校验拦住了——因为服务端只接收图片或视频，而那个10MB文件只是一堆零字节。后来又试过在某在线工具网站生成测试视频，下载下来用播放器打开直接报错，因为那些工具生成的"视频"只有文件头是视频格式，实际内容根本不是完整可解码的。从那次之后我就整理了一套自己的方案，适用于Linux、macOS、Windows，覆盖普通文件、可播放视频、可显示图片三类测试素材。

这套方案适合谁用？后端接口测试、App测试、运维需要验证CDN传输，或者前端要测试上传控件，都很适合。下文所有命令，我都给到了可以直接复制运行的级别。

1. 测试场景里最常被忽略的痛点：文件"能用"比"够大"更重要

很多测试工具教程会让用户在Linux上用dd或fallocate生成一个大文件，然后直接拿去做上传测试。这个思路本身没错，但有一个隐藏前提：被测系统如果只是把文件当作二进制流转发或存储，那么全零文件完全够用。可一旦系统加了任何"内容识别"逻辑，哪怕是读一下文件头或MIME类型，全零文件就会当场露馅。

我实际遇到过的几种典型场景，你可以对照判断自己的需求属于哪一类：

• 后端接口接收文件后调用图片处理服务（如缩略图、水印），如果是损坏图片，服务直接报500；
• 视频平台上传接口会做预解析，读取时长、分辨率、编码格式，假视频文件无法通过；
• CDN上传压测时虽然不关心内容，但如果有边缘节点做了Content-Type探测，全零文件会引起不可预料的失败；
• 前端Web页面上传组件用FileReader读取文件并预览，全零文件在浏览器里无法以img或video标签展示。

所以说，在准备测试素材时，第一步是搞清楚被测系统对文件内容有没有格式要求。如果只是验证"文件大小限制"这个逻辑本身，用dd生成普通文件就够了；如果需要走完整业务链路，那就要生成"内容真实可用"的文件。下文第2、3、4节会分别讲清这三类文件的生成方式。

2. 通用文件怎么生成：三行命令解决80%的临时需求

先讲最基础的——生成一个不关心内容、只关心字节大小的通用文件。这类文件适合测试文件上传大小限制、网络带宽、下载速度、存储容量等场景。

2.1 dd命令：可控性最强的基础工具

dd是Linux/macOS下最通用的方式。它的参数核心是bs和count，两者相乘就是最终文件大小。例如要生成10MB（这里按十进制含义的MB理解，命令中的M通常表示1024×1024字节）：

dd if=/dev/zero of=test_10M.bin bs=1M count=10

执行完ls -l test_10M.bin就能看到大小正好是10485760字节。如果有精确到字节的需求，比如"1025字节"这种奇数大小，可以用truncate先建文件再修正，或者直接把bs=1 count=1025。但bs=1 count=1025这种写法执行很慢（每次只写1字节），我一般这样处理：

# 先按较快的块大小生成 dd if=/dev/zero of=test.bin bs=1K count=1 # 再用 truncate 精确扩展到 1025 字节 truncate -s 1025 test.bin

truncate可以任意扩大或缩小文件到指定大小，而且速度极快。缩小时会截断内容，扩大时补零，非常适合"我要一个N字节文件"的场景。

2.2 truncate：秒建超大稀疏文件

truncate最强大的地方是生成超大文件几乎不占磁盘空间。例如：

truncate -s 10G test_10G.bin

执行后文件名义大小是10GB，但使用du -h test_10G.bin查看会发现它只占用了极小的磁盘空间。这种文件叫稀疏文件（sparse file），文件系统不会为这些零字节区域分配实际磁盘块。

这个特性在测试中是把双刃剑。验证上传限制时，服务器读取文件时看到的就是0字节块，这在多数Linux服务端没有问题。但如果被测系统会对文件做md5计算或完整性比对，稀疏文件的全零内容就会造成误导——所有同大小的稀疏文件内容完全一样，根本无法区分你传的是哪一个。

2.3 Windows下用fsutil生成测试文件

Windows环境下没有直接的dd命令（除非装了GNU工具或WSL），但系统自带的fsutil可以完成同样的事：

fsutil file createnew C:\temp\test_10M.bin 10485760

数字单位是字节，所以10MB要写成10485760。需要注意的是fsutil在某些精简版Windows上不可用，或者权限不足时会报错。如果你更习惯PowerShell，也可以用 .NET 的File.WriteAllBytes配合字节数组初始化：

[System.IO.File]::WriteAllBytes("C:\temp\test_10M.bin", New-Object byte[] 10485760)

2.4 全零文件与随机内容文件怎么选

如果被测系统会计算文件指纹或做内容比对，建议让文件内容随机化。Linux下可以用：

head -c 10M /dev/urandom > test_rand_10M.bin

但这种方式生成速度比dd全零慢很多，10MB还好，1GB以上会明显等很久。如果是大文件且需要随机内容，可以折中：用dd生成全零主体，再用随机数据覆盖文件头部几百KB。这样既能保证文件有大半的随机特征，生成速度也可控。

3. 生成可播放的指定大小视频：先用公式算码率，再交给FFmpeg

大部分测试教程讲到这里就停了，但这恰恰是测试素材准备中最关键的分水岭。可播放视频不能靠堆字节实现，必须用编码器真正生成画面和音频，而这两者的配比直接决定最终文件大小。

3.1 理解视频大小和码率的数学关系

视频文件大小的核心公式是：

文件大小(字节) ≈ (视频码率 + 音频码率) × 时长(秒) / 8

注意这里的码率单位是bps（bit per second），而我们平时说的文件大小是字节，所以要除以8。有了这个公式，就能反过来根据"目标大小"和"目标时长"算出需要设定的视频码率。

举个例子：我想生成一个约10MB、时长10秒的MP4文件。假设音频用128kbps，那么视频码率可以这样估算：

总码率 = 10 × 1024 × 1024 × 8 / 10 = 8388608 bps ≈ 8.39 Mbps

减去音频的128kbps，视频码率大约取8.2 Mbps。由于编码器实际输出会有波动，这个数值算出来后会落在"大约10MB"附近，而不是分毫不差的10485760字节。

这里有个很重要的认知：视频编码时，最终文件大小不可能精确控制到个位字节。码率控制本质上是编码器在"尽量贴近目标"和"保证画质稳定"之间折中。对测试场景来说，±5%的误差完全够用。

3.2 固定码率法：用FFmpeg一步到位

FFmpeg提供了-b:v（视频码率）、-maxrate（最大码率）、-bufsize（解码器缓冲区大小）这几个参数。只设置-b:v时，编码器在画面复杂时会拉高码率，画面简单时会降低码率，最终文件大小并不稳定。为了更接近目标，我习惯同时设置-maxrate和-bufsize：

ffmpeg -f lavfi -i testsrc=duration=10:size=1280x720:rate=30 \ -f lavfi -i anullsrc=r=44100:cl=stereo \ -c:v libx264 -b:v 8M -maxrate 8M -bufsize 16M \ -c:a aac -b:a 128k \ -y test_10M.mp4

解释一下这里的几个要点：

• -f lavfi -i testsrc=duration=10:size=1280x720:rate=30：这是FFmpeg内置的测试视频源，会生成一段动态变化的彩色测试图案，且带有时钟时间，在播放器里能明显看到画面在动；
• -f lavfi -i anullsrc=r=44100:cl=stereo：生成一段静音音频。之所以要加音轨，是因为很多播放器和服务端解析器会要求文件至少包含视频流或音频流，有音轨能提高通用性，也更接近真实用户上传的文件；
• -c:v libx264 -b:v 8M -maxrate 8M -bufsize 16M：视频采用H.264编码，目标码率8Mbps。bufsize一般设为码率的2倍，给编码器一个合理的缓冲窗口；
• -c:a aac -b:a 128k：音频采用AAC编码，码率128kbps。

执行完用ffprobe验证一下文件：

ffprobe test_10M.mp4

可以看到时长、编码格式、流信息等元数据。也可以用播放器打开，确认画面真的在动，而不是一张静止图。

3.3 用不同测试源控制画面复杂度：它直接决定文件大小误差

testsrc是最常用的测试图案，但它的画面相对平滑，压缩率高，这意味着实际文件往往比估算值小一些。如果想让文件更贴近目标大小，可以换成mandelbrot（分形图案）或cellauto（元胞自动机）这类高复杂度画面：

ffmpeg -f lavfi -i mandelbrot=size=1280x720:rate=30:end_pts=300 \ -f lavfi -i anullsrc=r=44100:cl=stereo \ -c:v libx264 -b:v 8M -maxrate 8M -bufsize 16M \ -c:a aac -b:a 128k \ -y test_mandelbrot_10M.mp4

高复杂度画面不容易被压缩，编码器需要花更多码率去保留细节，最终文件大小会更贴近甚至略超目标值。实测对比下来，同样的码率设置，mandelbrot产物比testsrc大30%左右。

理解了这条规律之后，你就能根据测试需求反向选择测试源：

顺带提一句，如果你的测试场景要求视频分辨率是4K、或者编码格式是HEVC（H.265），把size改为3840x2160、把编码器从libx264换成libx265即可。H.265的压缩率更高，同样码率下文件更小。

3.4 生成超大视频时，先想清楚组合策略

生成100MB以上视频时，如果还死磕"高码率+短视频"的组合，会遇到一个瓶颈：码率超过一定程度后，编码器也要保持输出，但画面复杂度撑不住高码率，文件大小依然上不去。我在实测里发现，生成100MB视频用时10秒，需要约84Mbps的码率，这远超常规视频码率，某些编码器会表现不稳。

更靠谱的做法是延长时长。生成一个60秒、目标码率约14Mbps的视频，文件大约105MB，这个码率在H.264编码下更自然，文件也不容易因为编码器限制而产生大的偏差。

ffmpeg -f lavfi -i smptebars=duration=60:size=1920x1080:rate=30 \ -f lavfi -i anullsrc=r=44100:cl=stereo \ -c:v libx264 -b:v 13853k -maxrate 13853k -bufsize 27706k \ -c:a aac -b:a 128k \ -y test_100M.mp4

这里我就不手动算码率了，直接把公式带入：目标100MB，时长60秒，(100×1024×1024×8/60) 约等于13.98Mbps，减掉0.128Mbps的音频，视频码率取13853kbps左右。生成后一般会在95~110MB之间，对测试来说足够精确。

4. 生成"看起来真实"的指定大小图片：按尺寸和按大小是两条路线

图片和视频不同，视频靠码率×时长控制大小，图片最大的影响因素是分辨率和内容复杂度。所以生成指定大小的图片，要先搞清楚"指定大小"指的是分辨率还是字节数——两者经常被混为一谈。

4.1 按像素尺寸生成：用ImageMagick最快

如果测试只要求"一张1920x1080的图片"，不关心字节数，那用ImageMagick的convert命令最省事：

# 生成纯色渐变图 convert -size 1920x1080 gradient:blue-yellow test_gradient.png # 生成噪声纹理图（plasma是ImageMagick内置的复杂纹理） convert -size 1920x1080 plasma:fractal test_plasma.png

gradient生成的是一张平滑渐变图，色彩过渡自然，在浏览器和系统看图器里都能正常打开；plasma:fractal生成的是一张类似火星表面或流体效果的纹理图，视觉上更丰富，但由于细节多，文件也更大。

如果你是Python技术栈，不想依赖ImageMagick，Pillow可以做到同样的事：

from PIL import Image img = Image.new("RGB", (1920, 1080), (30, 144, 255)) img.save("test_blue_1920x1080.png") # 生成横向渐变 pixels = img.load() for x in range(1920): for y in range(1080): pixels[x, y] = (int(x / 1920 * 255), 100, 200) img.save("test_gradient_1920x1080.png")

但注意Pillow逐像素操作大图时速度很慢，测试素材不需要逐像素定制，所以更推荐用ImageMagick的一行命令。

4.2 按文件大小生成：随机噪声图是最直接的办法

如果需求是"给我一张5MB左右的JPEG图片"，这就要走上"按字节控制图片大小"的路子。核心思路很简单：图片之所以小，是因为大面积颜色区域可以被压缩得很高效；反过来，图片里全是随机噪点，压缩算法就很难缩小体积，文件就会逼近像素数据的原始大小。

用Python Pillow生成随机噪点图：

from PIL import Image import numpy as np width, height = 1920, 1080 arr = np.random.randint(0, 255, (height, width, 3), dtype=np.uint8) Image.fromarray(arr).save("test_noise.png")

生成出来的PNG通常非常大，因为随机RGB数据压缩率极低。但没有numpy时用纯Python逐像素填充太慢，所以我还是建议直接上numpy。如果环境里不能用numpy，退而求其次可以用ImageMagick：

convert -size 1920x1080 xc: +noise Random test_noise.png

同样能生成随机噪点图。

这套思路能帮你快速估算像素数和最终文件大小的关系。一张RGB随机噪点图片的PNG大小约等于：宽×高×3字节，再加上PNG容器的几十KB开销。所以想生成"约10MB的PNG"，需要约1000万像素——正好接近一个3000x3000的图。经验做法是把目标像素数乘以0.98作为实际宽高积，给PNG元数据留一点余量。

4.3 用JPEG质量参数逼近目标大小

JPEG是有损压缩格式，文件大小不仅仅取决于分辨率，还取决于压缩质量。如果目标大小不是恰好10000KB，而是"大约5MB、允许误差500KB"，那用质量参数慢慢逼近是很快的。

我用过一个简单脚本，效果不错：

from PIL import Image import numpy as np # 生成随机噪点图作为基础 arr = np.random.randint(0, 255, (2000, 2000, 3), dtype=np.uint8) img = Image.fromarray(arr) # 从质量85开始，逐个质量值试，直到接近目标大小 target = 5 * 1024 * 1024 for quality in range(95, 50, -5): img.save("approx_5M.jpg", quality=quality) if Path("approx_5M.jpg").stat().st_size <= target: break

JPEG对随机噪点的压缩能力有限，质量从95降到60时文件大小不会有特别剧烈的变化，但通过微调分辨率和质量，把最终大小控制在目标值的5%以内并不难。

另外还有一个工具型方案，用ImageMagick配合压缩质量的参数：

# 先把图放大到目标近似尺寸，再用质量参数微调 convert -size 3000x3000 plasma:fractal -quality 85 approx_5M.jpg

生成后再看实际大小，偏大就降低quality，偏小就提高quality或把像素尺寸改大。反复两次就能贴进目标区间。

4.4 补充：PNG与JPEG的压缩特性差异决定了选型

PNG是无损压缩，对渐变、纯色区域压缩很好，对随机噪点几乎压不动；JPEG是有损压缩，对噪点会做一部分有损处理，但面对随机高频信息仍然无法有效压缩。所以：

• 想要"尽量接近目标字节数偏大方向"：用随机噪点PNG，因为压缩率可预测、稳定；
• 想要"能压缩到目标大小且视觉上像真实照片"：用 plasma:fractal 或实际照片素材转JPEG，用质量参数逼近；
• 想要"一张极小但尺寸很大的图"：用纯色PNG或JPEG，1920x1080的纯白JPEG可能只有几十KB。

要根据最终目的去选，而不是一味追求大文件或小文件。

5. 落到真实测试场景：上传限制、CDN传输和批量文件的实操

生成了文件，接下来才是重头戏——怎么用它们完成测试。这节讲几种最常见的落地场景。

5.1 验证Nginx和Spring Boot的文件大小限制

排查Nginx上传限制时，系统最常遇到的行为是：请求直接被拒，返回413（Request Entity Too Large）。要复现这个场景，只需要生成一个刚好超过限制值的文件，然后用curl上传：

# 假设Nginx配置了 client_max_body_size 10m curl -F "file=@test_11M.mp4" http://localhost/upload -v

如果看到HTTP/1.1 413 Request Entity Too Large，说明上传大小限制已经生效。此时对比一下9MB、10MB、11MB三个文件，就能确认限制值是否精准。

Spring Boot项目则是在application.yml里配置了spring.servlet.multipart.max-file-size: 10MB，此时传一个略超10MB的文件，后端会抛出MaxUploadSizeExceededException。我实际排查时发现，不同版本的Spring Boot对超限请求的响应码不一样，有的是400，有的是500，这个不建议直接当作预期，先抓包看真实返回再定断言。

5.2 用一个可播放视频验证CDN或对象存储的上传链路

有一次测CDN回源，我用dd生成了一堆随机文件，结果上传是成功了，但每次回源拉取的文件在视频播放器里都没法打开。排查后发现CDN边缘节点检查了视频文件的moov atom（MP4文件的索引区），发现文件里根本没有这个结构，直接判定为无效文件。

用FFmpeg生成的视频文件天然带完整MP4结构，上传后从CDN节点拉下来用ffprobe验证，能正常解析出编码信息，才说明链路没有在中间环节破坏文件。这是我改成用FFmpeg生成视频做测试的最大原因。

5.3 批量生成不同大小素材的脚本建议

测试中往往需要一组递进大小的文件，手工逐条执行命令很烦。我通常会写一个简单循环脚本，把常用尺寸一次性生成出来：

for size in 1 5 10 20 50 100; do ffmpeg -f lavfi -i testsrc=duration=30:size=1280x720:rate=30 \ -f lavfi -i anullsrc=r=44100:cl=stereo \ -c:v libx264 -b:v ${size}M -maxrate ${size}M -bufsize $((size*2))M \ -c:a aac -b:a 128k \ -y test_${size}M.mp4 done

图片类也可以用同样思路循环调用ImageMagick。这套脚本我会用目录结构区分类型，命名里带上大小和格式，方便后面写自动化测试用例时直接引用路径。

6. 生成过程中绕不开的坑：文件系统、编码器和格式校验

这部分是真正花时间踩过才会知道的经验。给大家拆几个印象深刻的坑，提前避开。

6.1 稀疏文件 vs 实际占用空间：别让假象干扰判断

truncate -s 1G test.bin执行后，ls -l显示1GB，但du -h test.bin可能显示只有1MB甚至0。这在测试磁盘满、分片传输这种场景时会造成误判。系统按"名义大小"接收文件，但文件内容在真正写入磁盘时如果触发了稀疏复制，某些服务端工具在计算流量或做存储空间统计时会看到完全不同的数值。如果测试目标涉及"实际占用空间"，用dd而不是truncate生成文件更稳妥。

6.2 文件系统块大小：NTFS/exFAT的意外偏差

NTFS和exFAT文件系统对文件分配空间的粒度是"簇"，通常4KB或更大。生成一个1字节的文件，磁盘上占用的是4KB，但文件系统把文件大小正确记录为1字节。这个差异和稀疏文件是两回事——文件大小（逻辑大小）永远精确，占用空间（分配大小）取决于簇大小。做存储测试时，这两个指标很容易搞混，要看清测试需求问的是哪一个。

6.3 扩展名和MIME类型：很多系统都认这套"表面功夫"

用FFmpeg生成的是MP4容器，即使把文件名改成.mkv或.avi，文件内部仍然是H.264+AAC的MP4结构。这类改扩展名的文件在服务端做MIME探测时依然能识别为视频，但在严格校验扩展名和内容是否匹配的系统里会被拒收。图片同理，改了扩展名的PNG在服务端强制做JPEG解码时会失败。所以在生成素材时，扩展名必须与容器格式保持一致。

另外，Web系统里有一个常被忽略的点：服务端不只看文件扩展名，还看请求头里的Content-Type。curl默认会用文件扩展名推断MIME类型，但一些测试工具或代码库会固定传application/octet-stream，这会导致上传组件在浏览器预览时无能为力。

6.4 编码器兼容性：FFmpeg不一定自带libx264

有些精简版FFmpeg或静态编译版本没打包libx264，执行上面带-c:v libx264的命令会直接报"Unknown encoder"。确认方法：

ffmpeg -encoders | grep libx264

如果没有，可以考虑用内置的mpeg4编码器代替，它兼容性好、各种播放器基本都支持，缺点是压缩率和画质不如H.264。测试场景里如果对存储体积不敏感，用-c:v mpeg4反而能更快生成文件。

6.5 生成完一定要验证，别让文件"看着在"但打不开

我见过太多人生成测试文件后不做验证，等到测试用例跑挂才回头查。最有效的验证方式就两条：

• 视频用ffprobe看流信息，能解析出视频流、音频流、时长、分辨率才算通过；
• 图片直接用file命令看实际格式，或用Python Pillow重新打开一层确认能正常解码。

养成这个习惯之后，我基本没有因为测试素材本身的问题返工过。尤其是批量脚本运行时，加一个循环检查，5秒钟的事，能省后面很多排查时间。

做测试素材这件事，看起来简单，但真要做到"生成真实内容、结构完整、大小可控、批量可用"，还是需要一套稍微完整的方案。我实际使用下来，普通文件靠dd和fsutil，视频靠FFmpeg码率公式，图片靠随机噪点或ImageMagick纹理，三套方案交叉覆盖了绝大多数测试需求。如果你经常要帮别人准备这类素材，建议把这些命令整理成脚本，配合命名规范放在本地，用的时候改几个参数就行。