将老系统中到数据迁移到新系统中
将新系统中到数据迁移到老系统中，一般不会全部迁移，可能就是将部分表迁移过去，使得老系统可以用新系统中到这些数据进行相关的统计，迁移到主要方式是批量迁移，就是说，在一定的时间范围内，运行一次脚本，将新系统中到数据迁移到老系统中，主要到测试策略如下：
1. 查看时间段内所有数据都进行了迁移操作
迁移是将新系统中一定时间范围内有变化的数据反映到老系统，因此，需要测试在这个时间段内有新系统中有变化的数据都正确反应到老系统中，一般来说，数据迁移，会有一个表专门用来记录在新系统中数据到变化情况，可以通过查看该日志表，得到有变化的数据记录，然后可以在新系统中对应进行检查。
2. 查看新增的数据是否能够迁移
因为是批量到迁移，需要确保新系统中新增到数据能够迁移到老系统中去，可以根据ID，唯一确定新系统中生成的数据迁移到了老系统。
3. 查看修改到数据是否能够真确反映到老系统中
新系统中，不可避免的会对数据进行修改操作修改操作后的数据，相应的，老系统中对应的数据也需要改变，就需要测试，如果新系统中的数据修改了，执行脚本后，老系统中到数据是否会做同样的修改。
4. 查看删除数据是否正确反映到老系统中
新系统中，对数据进行删除操作，该数据对应到老系统中的数据同样也需要被删除。
5. 查看迁移后各字段是否正确
字段对照检查，方法和前面的老系统迁移到新系统中一样。
6. 大数据量测试
因为是批量进行迁移，可能在数据量较大的情况，此时，如果迁移脚本关联操作较多，可能催存在脚本执行时间段内不能完成所有数据到迁移，导致本次本次迁移的数据没有完成，到下一次执行脚本时，又有数据没有迁移完成，就会有大量到数据不能完成迁移操作，此时就需要优化迁移脚本，或者增加脚本定时钟的时间。大数据量的测试，还需要关注，在数据量较大到情况下，迁移的数据是否会出现错误。
7. 业务测试
因为新系统的数据库表结构以及字段表示可能和老系统不一致，需要用迁移到老系统中的数据进行功能测试，流程测试，确保数据可用。
8. 不进行迁移的字段确认
因为新系统的数据库表结构以及字段表示可能和老系统不一致，新系统中部分字段可能在老系统中找不到对应的字段，就不需要迁移，这一部分也需要进行验证，确保不会将不迁移的字段数据迁移到其他的字段中。
9. 字段长度不一致检查
新系统中字段长度和老系统对应字段长度不一致，要么无法迁移，要么就需要进行截取，如果不能迁移，就需要有错误日志，确定哪些字段不能迁移，如果是截取，则需要确认，截取的长度是否真确，如果截取了，是否会在业务上造成影响
对于数据迁移的测试，个人觉得需要关注两个方面，一个是从业务上关注，迁移后的数据在业务流程上应该是可用的，也不会对现有到业务造成影响，另外一个就是迁移后到数据应该是完整的，正确的，可用的首先就需要关注迁移规则是不是正确的，如果迁移规则是错误的，迁移后的数据就算是符合迁移规则了，也是不正确的。
