用于学习，原文来自网络：http://softtest.chinaitlab.com/qtjs/775532.html
数据迁移主要使用在新老系统到切换，主要有两种类型
一种是将老系统的数据全部迁移到新系统中，业务上只使用新系统，老系统不再使用
另外一种是，老系统的部分功能在新系统中暂时无法实现，但是在业务上需要使用新系统，需要将新系统中产生到数据导入到老系统到数据库中，做特殊用途。
将老系统中到数据迁移到新系统中
主要到策略有：
1. 查看老系统中到数据是否完全迁移到新系统中
要保证新老系统到无缝切换，必须要保证数据的正确性，而将老系统中到数据迁移到新系统，首先就要保证所迁移的数据量是一致的，只要在保证数据量一致的情况下，才能进行其他方面到测试，如果数据量都不一致，说明迁移方法或者脚本就是错误到，需要寻找原因。
2. 查看新老系统数据库表结构变化
1） 哪些新表字段在老库中无数据，而新库必须有，这些数据无则默认给什么值
2） 哪些数据字段一部分有数据，一部分无数据；迁移到新库中无数据这部分如何处理
3） 旧数据库中的表关系到新库中的表关系有什么变化
3. 查看新老系统中，相同字段不同状态的变化
因为新老系统在业务表示上会有一定的差异，用来表示业务状态的标示也会存在有变化，就必须注意新老系统在表示相同业务状态的差异，一般，这种情况会做相应的映射，需要根据映射关系，检查迁移后的数据是否正确。
4. 查看新老系统中各个字段转换是否正确
在进行字段检查测试之前，需要准备测试数据，测试数据到准备最好是能够将每个字段到不同情况都考虑到，可以使用矩阵法，用最少的数据覆盖到最多的状态。准备好数据后，根据迁移规则，可以查看各字段迁移后到数据是否正确，一般来说，迁移规则有以下几种。
1>直接迁移，原来是什么就是什么，原封不动照搬过来，对这样的规则，如果数据源字段和目标字段长度或精度不符，需要特别注意看是否真的可以直接映射还是需要做一些简单运算，还要查看，迁移脚本中是否对长度或精度进行了处理，测试时，也需要准备长度精度不一致到数据进行测试，查看是否能够正确迁移。
2>字段运算，数据源的一个或多个字段进行数学运算得到的目标字段，这种规则一般对数值型字段而言。
3>参照转换，在转换中通常要用数据源的一个或多个字段作为Key，去一个关联数组中去搜索特定值，而且应该只能得到唯一值。一般来说，这样的主要适用于某些类似于id的字段
4>字符串处理，从数据源某个字符串字段中经常可以获取特定信息，例如身份证号。而且，经常会有数值型值以字符串形式体现。对字符串的操作通常有类型转换、字符串截取等。但是由于字符类型字段的随意性也造成了脏数据的隐患，所以在测试这种情况的时候，一定要考虑异常情况。
5>空值判断，对于老系统中空值字段，不能简单的认为迁移后还是空值，需要根据实际的情况，考虑该字段在新库中应该为哪个字段，还要考虑，如果老系统中该字段不为空的情况。
6>日期转换，需要考虑新老系统对日期到不同表示方法。
7>聚集运算，对于事实表中的度量字段，他们通常是通过数据源一个或多个字段运用聚集函数得来的，这些聚集函数为SQL标准中，包括sum,count,avg,min,max。
8>既定取值，这种规则和以上各种类型规则的差别就在于它不依赖于数据源字段，
对目标字段取一个固定的或是依赖系统的值。
5. 查看迁移后的数据在业务逻辑上是否正确
使用从老系统中迁移过来的数据，在业务系统中进行流程测试，功能测试确保迁移后到数据可用。
将老系统中到数据迁移到新系统中
将新系统中到数据迁移到老系统中，一般不会全部迁移，可能就是将部分表迁移过去，使得老系统可以用新系统中到这些数据进行相关的统计，迁移到主要方式是批量迁移，就是说，在一定的时间范围内，运行一次脚本，将新系统中到数据迁移到老系统中，主要到测试策略如下：
1. 查看时间段内所有数据都进行了迁移操作
迁移是将新系统中一定时间范围内有变化的数据反映到老系统，因此，需要测试在这个时间段内有新系统中有变化的数据都正确反应到老系统中，一般来说，数据迁移，会有一个表专门用来记录在新系统中数据到变化情况，可以通过查看该日志表，得到有变化的数据记录，然后可以在新系统中对应进行检查。
2. 查看新增的数据是否能够迁移
因为是批量到迁移，需要确保新系统中新增到数据能够迁移到老系统中去，可以根据ID，唯一确定新系统中生成的数据迁移到了老系统。
3. 查看修改到数据是否能够真确反映到老系统中
新系统中，不可避免的会对数据进行修改操作修改操作后的数据，相应的，老系统中对应的数据也需要改变，就需要测试，如果新系统中的数据修改了，执行脚本后，老系统中到数据是否会做同样的修改。
4. 查看删除数据是否正确反映到老系统中
新系统中，对数据进行删除操作，该数据对应到老系统中的数据同样也需要被删除。
5. 查看迁移后各字段是否正确
字段对照检查，方法和前面的老系统迁移到新系统中一样。
6. 大数据量测试
因为是批量进行迁移，可能在数据量较大的情况，此时，如果迁移脚本关联操作较多，可能催存在脚本执行时间段内不能完成所有数据到迁移，导致本次本次迁移的数据没有完成，到下一次执行脚本时，又有数据没有迁移完成，就会有大量到数据不能完成迁移操作，此时就需要优化迁移脚本，或者增加脚本定时钟的时间。大数据量的测试，还需要关注，在数据量较大到情况下，迁移的数据是否会出现错误。
7. 业务测试
因为新系统的数据库表结构以及字段表示可能和老系统不一致，需要用迁移到老系统中的数据进行功能测试，流程测试，确保数据可用。
8. 不进行迁移的字段确认
因为新系统的数据库表结构以及字段表示可能和老系统不一致，新系统中部分字段可能在老系统中找不到对应的字段，就不需要迁移，这一部分也需要进行验证，确保不会将不迁移的字段数据迁移到其他的字段中。
9. 字段长度不一致检查
新系统中字段长度和老系统对应字段长度不一致，要么无法迁移，要么就需要进行截取，如果不能迁移，就需要有错误日志，确定哪些字段不能迁移，如果是截取，则需要确认，截取的长度是否真确，如果截取了，是否会在业务上造成影响
对于数据迁移的测试，个人觉得需要关注两个方面，一个是从业务上关注，
迁移后的数据在业务流程上应该是可用的，也不会对现有到业务造成影响，另外一个就是迁移后到数据应该是完整的，正确的，可用的首先就需要关注迁移规则是不是正确的，如果迁移规则是错误的，迁移后的数据就算是符合迁移规则了，也是不正确的。