文件断点续传测试
假设用户上传一个1GB的大文件,网络突然中断。此时系统已经上传了前500MB(假设分成5个Chunk,每个100MB)。
当用户重新连接时,系统应该从第6个Chunk(500MB处)继续上传剩余部分。
但实际测试中发现:系统错误地将新上传的Chunk序号再次从1开始编号,导致:
- 新上传的第1个Chunk(即文件500-600MB的内容)覆盖了原始的第1个Chunk(0-100MB)
- 最终合并后的文件前100MB被破坏,且后续内容错位
技术原理拆解
- 断点续传机制
- 文件会被切割成多个Chunk(分片),每个Chunk有唯一序号(例如Chunk1、Chunk2…)
- 服务端根据Chunk序号拼接文件
- 缺陷本质
- 客户端在断线重传时未正确记录已上传的Chunk序号,而是重置了序号计数器
- 服务端收到重复的Chunk序号时,直接覆盖原有数据(未做冲突检测)
举个实际例子
🔄 正常流程
markdown
用户上传文件:Chunk1 → Chunk2 → Chunk3(中断)
重传时继续:Chunk4 → Chunk5 → ...(服务端正确拼接)
🔥 缺陷场景
markdown
用户上传文件:Chunk1 → Chunk2 → Chunk3(中断)
重传时错误:Chunk1 → Chunk2 → ...(服务端用新Chunk1覆盖旧Chunk1)
最终文件 = 新Chunk1 + 新Chunk2 + 旧Chunk3 → 文件内容错乱
为什么这是严重问题?
- 数据完整性破坏:用户上传的文件内容被篡改
- 用户体验灾难:用户发现文件损坏,对产品失去信任
- 技术债务暴露:反映出服务端缺乏分片唯一性校验机制
你在测试中的价值体现
- 精准复现:用Fiddler拦截请求,手动中断网络,模拟真实弱网环境
- 逆向分析:通过抓包发现重传时Chunk序号被重置(对比前后请求的序号值)
- 推动修复:推动开发增加分片唯一性标识(如:文件Hash+Chunk序号联合校验)