在软件的生命周期中，经常遇到由于业务发展，系统迭代更新带来的数据迁移工作；或者软件系统本身的重构抑或其他因素，几乎都需要对数据进行迁移。
最近看了一些关于数据迁移测试相关的资料，由于以前对这方面没有太多实践，所以浏览的同时也在思考如何进行数据迁移测试，这篇博客，整理记录一些自己的总结和思路。。。
参考内容：如何进行大规模在线数据迁移
一、数据迁移面临的风险
1、数据规模
想象一下，数以亿计的数据，在生产环境的数据库上进行迁移，比如一个数据对象（有关联的N条数据）迁移需要一秒钟，那么如果按照顺序迁移，则可能花费几个月甚至几年的时间。
2、迁移过程中服务是否停止
企业通过不断的对用户提供服务产生效益，所有的系统升级、产品迭代现在基本都是在线进行，而不依赖于有计划的维护时段。
因为不能在迁移过程中中断或者停止所有或部分服务，那么在这个迁移过程中必须要保证服务100%处于可用状态。
3、数据的正确性、一致性、可用性
正确性：代码中很多的代码都是在直接使用数据库某些表中的数据，如果试图一次性的修改整个应用里面的代码，那么涉及的方面将是巨大的，也很容易忽略一些边界情况。
在数据迁移过程中，必须确保每项服务获取到的数据都是正确无误的。
一致性：在数据迁移过程中，必须确保从原有的数据库迁移过来的数据和新数据库表中存储的数据保持一致。
可用性：即无论是迁移前，还是迁移过程抑或迁移完成后，数据都必须是100%可用。
二、迁移前的准备工作
1、确认数据迁移范围
在进行数据迁移前需要和开发、运维等相关部门确认好数据的迁移范围，分析原有系统和现有系统的功能模块、大致的处理流程，分析两者的区别，以及历史数据对用户的影响程度等，
确认工作量和工作进度，这样才方便确认数据迁移边界和范围，不至于盲目的全部迁移。
2、统计迁移数据类型
①、基础数据迁移
基础数据也可以称为主档数据，通常来说这一类数据都是需要全部复制到新的系统数据库中，因为它会影响所有的业务。
②、流程性数据
这一类数据只有在记录完全关闭后才能结束，需要进行增量导入和数据更新，同时还要进行相关查询界面的开发，以保证旧有数据能够在新系统中查询的到。
③、历史数据
对于这一类的数据，需要和业务部门确认好历史数据对用户的影响，哪些是必须要迁移的，哪些是可以通过备份或双写模式进行迁移的，确认数据范围和新老系统的差异以及库表结构等。
3、新老系统数据库表结构变化
①、可以通过excel表格等方式确认相关表的数据字典对照，勾画出对应字段、转换逻辑、依赖关系等，必要时在新系统表上做相应的冗余，等数据迁移完毕后再清除；
②、注意不同数据库的字段类型的匹配问题，比如SQLServer的text，在oracle应该对应clob，根据具体情况和实现的难易程度来确认具体做法；
③、关于主键的问题，一致的数据类型尽量维持现有状态，不一致的尽量采用oracle的序列或sqlserver的identity int，但迁移完毕后，要注意序列值的更新。
三、迁移数据的方法
1、直接复制表
将原有系统数据库中的表直接复制到新系统的数据库中；
2、拆表&合表
拆表：将原有系统数据库中的表数据拆分到新系统数据库中的几张表中；
合表：将原有系统数据库中的表字段合并到新系统数据库中的一张表中；
PS：需要确认清楚，哪些表分拆迁移，哪些表合并迁移，迁移的数据字段、条数等！
四、数据迁移测试
1、数据量一致性测试
要做到新老系统无缝切换，就必须保证数据的正确性和一致性，首要条件就是迁移的数据量是保持一致的，否则无法进行其他测试。
方法：①、可以通过文本统计工具或者数据库连接工具将迁移前的数据库表名、字段、数量等进行统计，然后将迁移后的新数据库表名、字段、数量等进行统计，然后进行比较。
②、通过MD5生成工具，对新老数据文本进行MD5值比对测试，如果一致则表示数据量一致，如果不一致，则表明迁移后的数据有部分存在问题。
2、数据库表结构变化测试
这种测试分2种情况：一种是新老数据库表结构完全不存在关系，新数据库表的字段都是给定的默认值；还有一种是新数据库表字段是由原有系统数据库表字段转换而来。
方法：针对第一种情况，因为新增的字段都是给定的默认值，所以只需要根据开发提供的填写规则，检查该字段的所有值是否满足填写规则。
针对第二种情况，可以通过编写自动化测试脚本或者人工抽样或者切片方式进行，具体的抽样选择根据数据量等具体情况选择合适的比例即可。
五、业务逻辑测试
完成上面的数据迁移测试后，需要在新的系统中进行回归测试，以确保迁移过来的数据是100%可用的。
回归测试前需要和业务、开发确认哪些业务模块涉及了哪些表，然后根据具体情况，尽可能的提高测试用例覆盖率，做一次全系统的功能回归测试（可以考虑自动化测试来替代一部分手工测试）。
