答案。

在迁移到新版本的应用程序时，如果数据库结构、存储对象或数据转换逻辑发生变化，就需要进行数据迁移测试。

问题的背景

应用程序的演变需要定期更新、从过时的系统迁移以及进行架构变更。通常，数据迁移被视为技术性任务，但如果没有适当的控制，测试人员会定期收到事件报告——从数据丢失到数据转换不正确。

问题

主要困难：

• 在迁移过程中数据的丢失或扭曲；
• 新数据/结构与新版本业务逻辑不兼容；
• 缺乏明确的成功迁移标准。

解决方案

正确的手动测试过程包括：

• 形成覆盖不同类型数据（简单、复杂、边界、非标准）的测试场景；
• 按关键参数（数量、正确性、完整性）比较新旧版本的结果数据；
• 验证复杂实体的转换逻辑；
• 在相关（真实样本）数据上进行测试，必须进行备份。

关键特点：

• 交叉检查不同数据变体： 从简单到聚合和历史数据；
• 完整性和关联性检查： 不仅要保证迁移的准确性，还要保持表、字段、实体之间的关系；
• 迁移过程记录： 所有阶段都必须文档化，以便于重现和可能的回滚。

带有陷阱的问题。

可以使用完全合成的数据进行迁移测试吗？

不可以。合成数据往往无法反映真实的关系和历史案例，重要的是用真实的匿名样本进行补充。

仅比较迁移前后记录的总数是否足以确认正确性？

不可以。在数据转换错误或数据不完整的情况下，记录的数量可能一致。重要的是分析内容和字段的正确性。

需要在空库上检查迁移吗？

必须。这种检查可以发现边界错误场景（例如，空目录，缺少关键记录）。

常见错误和反模式

• 仅检查行数而不分析数据
• 忽视实体和表之间的关系
• 仅使用新数据进行测试而忽略历史数据

生活中的例子

负面案例

在迁移过程中只检查了“新”用户数据。逻辑错误在稍后揭示，当时需要罕见使用的历史数据（例如，旧订单）。

优点：

• 测试阶段快速验证

缺点：

• 历史数据丢失，支持团队介入
• 错误链条揭示时间长

正面案例

创建了真实和归档（匿名化）数据的样本，迁移在它们以及空且高度碎片化的数据库上进行测试。

优点：

• 早期发现潜在错误
• 保护数据的完整性和历史

缺点：

• 测试场景组织更复杂
• 资源在准备和比较样本上的消耗