数据迁移测试的环境问题

Question

需求：数据库迁移，系统有几十张表数据，从mysql迁移到sqlserver，做迁移测试。无自动化工具，通过人工测试比对，考虑检查数据量，抽查数据准确性。

请问迁移测试一般要在测试环境和生产环境测两遍吗？考虑工作量翻倍，有没有简化办法呢？还有什么值得关注的测试点。

Answer 1

参考通义千问和郭老师的小迷弟雅思莫了-编写提供，主要是为了帮助您快速解决问题，如下回答，您可以参考下，如有问题，评论区留言。

数据库迁移测试是一个关键的过程，确保数据在从MySQL迁移到SQL Server时的完整性和准确性。在没有自动化工具的情况下，人工测试确实会增加工作量，但仍然可以通过合理规划和方法来保证测试的有效性：

1. 环境问题：

   • 是的，一般情况下，迁移测试会在非生产环境（如开发环境或独立的测试环境）中首先进行，以验证迁移过程本身并发现问题。这是因为直接在生产环境中做迁移测试存在很大风险。
   • 在非生产环境验证成功后，再计划在生产环境进行迁移，并在迁移完成后立即进行必要的验证测试，确保生产环境的实际表现与预期一致。

2. 简化办法：

   • 优先级排序：根据业务重要性和数据敏感度对表进行优先级排序，优先比对最关键的数据表。
   • 抽样测试：对于大型表，可以采取抽样方式进行数据比对，选择部分代表性的记录而非全量比对，但仍需覆盖各种业务场景和边界条件。
   • 脚本辅助：虽然无自动化工具，但可以编写SQL查询脚本来统计源库和目标库中各表的行数、检查特定字段的样本数据等，减少重复劳动。
   • 复用验证脚本：一旦确定了验证脚本，在不同环境执行时只需修改连接参数，可大大减少脚本编写的时间。

3. 值得关注的测试点：

   • 数据完整性：所有数据是否都已成功迁移，包括但不限于主键、外键关联数据、索引、唯一约束等。
   • 数据准确性：通过对比字段值来确认数据迁移过程中是否有丢失、乱序或错误转换的情况。
   • 数据一致性：关系型数据库中的事务处理可能导致的数据依赖性问题，比如触发器、存储过程的结果是否正确。
   • 数据格式兼容性：MySQL和SQL Server在数据类型、日期格式等方面可能存在差异，需要确保迁移后的数据格式适应新系统的要求。
   • 性能对比：除了数据内容，还需要关注迁移后的数据库性能是否符合要求，例如查询速度、资源使用情况等。
   • 功能验证：在应用层面进行功能回归测试，确保迁移到新数据库之后的所有业务功能正常运行。

总的来说，尽管没有自动化工具增加了测试复杂性，但通过精心设计测试策略、编写有效的验证脚本以及合理安排测试顺序，可以在一定程度上降低工作量和风险。同时，应尽可能寻求引入自动化工具或服务来提高效率和准确性。