文件断点续传测试

文件断点续传测试

假设用户上传一个1GB的大文件，网络突然中断。此时系统已经上传了前500MB（假设分成5个Chunk，每个100MB）。
当用户重新连接时，系统应该从第6个Chunk（500MB处）继续上传剩余部分。

但实际测试中发现：系统错误地将新上传的Chunk序号再次从1开始编号，导致：

1. 新上传的第1个Chunk（即文件500-600MB的内容）覆盖了原始的第1个Chunk（0-100MB）
2. 最终合并后的文件前100MB被破坏，且后续内容错位

---

技术原理拆解

1. 断点续传机制
   • 文件会被切割成多个Chunk（分片），每个Chunk有唯一序号（例如Chunk1、Chunk2…）
   • 服务端根据Chunk序号拼接文件
2. 缺陷本质
   • 客户端在断线重传时未正确记录已上传的Chunk序号，而是重置了序号计数器
   • 服务端收到重复的Chunk序号时，直接覆盖原有数据（未做冲突检测）

---

举个实际例子

🔄 正常流程

markdown

用户上传文件：Chunk1 → Chunk2 → Chunk3（中断）  
重传时继续：Chunk4 → Chunk5 → ...（服务端正确拼接）  

🔥 缺陷场景

markdown

用户上传文件：Chunk1 → Chunk2 → Chunk3（中断）  
重传时错误：Chunk1 → Chunk2 → ...（服务端用新Chunk1覆盖旧Chunk1）  
最终文件 = 新Chunk1 + 新Chunk2 + 旧Chunk3 → 文件内容错乱  

---

为什么这是严重问题？

1. 数据完整性破坏：用户上传的文件内容被篡改
2. 用户体验灾难：用户发现文件损坏，对产品失去信任
3. 技术债务暴露：反映出服务端缺乏分片唯一性校验机制

---

你在测试中的价值体现

1. 精准复现：用Fiddler拦截请求，手动中断网络，模拟真实弱网环境
2. 逆向分析：通过抓包发现重传时Chunk序号被重置（对比前后请求的序号值）
3. 推动修复：推动开发增加分片唯一性标识（如：文件Hash+Chunk序号联合校验）