最近经历了一场大型的数据迁移测试，因为以前对数据迁移测试研究甚少，所以对测试实施方案的制定非常的棘手，在网上也查询了很多，发现相关资料很少，并且大部分都是一些理论指导，没有讲到具体的如何去做的方法，整个方案也不够全面，没有实际的实施指导价值。
所以结合了这次自己经历的数据迁移测试实施以及前人的观点，写了这么一篇比较完善的，更具实施指导意义的测试方案，一方面是对这次经历的数据迁移测试的一个总结，另外一方面是想能有更多的朋友参与到这数据迁移测试的讨论中，能为后面可能经历的同学留下更好的参考资料，由于能力有限，文中肯定有很多纰漏，欢迎大家吐槽拍砖，哈哈！希望后面能把这篇文章完善的更好。
下面进入正文
前期准备工作
数据迁移范围确定
在做数据迁移测试前需要和开发部门确认好数据迁移范围，主要包含以下几点：
基本数据迁移
基本数据迁移就是从老库中把一些老表直接复制到新库的新表中，或是：
1.拆表：老库的老表拆分到新库的其他几张新表中去，2.合表：老库中的几张老表的字段合并到新库的一张新表中去
所以需要提前和开发部门确认好以下问题：
要和和开发一起确认要迁移的是那几张表？弄清楚老库中的老表对应要迁移到新库中的哪几张表？
迁移的表中，哪些数据字段需要迁移，哪些数据字段不需要迁移？
老表要迁移的数据记录条数是多少？
新老系统数据库表结构变化
1.新增字段和老系统表完全不存在关系
老表迁移到新表中，新表中有些必填字段在老表中没有的，需要和开发确认这些数据的填写规则（给什么默认值）
2.新增字段是由老系统特定字段转换而来
新系统中的一些字段可能是老系统中的一些字段通过一些规则转化而来的，所以需要和开发部门确认这些转换规则
迁移范围统计方法
基本数据迁移
1.直接复制表
2.非直接复制表（拆表&合表）
新老系统数据库表结构变化
1.新增字段和老系统表完全不存在关系
2.新增字段是由老系统特定字段
测试方案
测试类型分以上几大块，下文会对每种类型的测试做详细的说明
基本数据迁移测试
要保证老系统到新系统的无缝切换，必须要保证数据的正确性，而将老系统中数据迁移到新系统，首先就要保证所迁移的数据量是一致的，
只有在保证数据量一致的情况下，才能进行其他方面到测试，如果数据量都不一致，说明迁移方法或者脚本就是错误的，需要寻找原因。
方法1：
测试工具：
Navicat，文本比较工具（以 Beyond Compare为例）
测试流程：
迁移范围确定：
开发部门统计好本次的数据迁移范围给到测试部门
数据表导出：
1.对于直接复制的表
根据“迁移范围确定”中的库名、表名、条数，通过Navicat工具以txt格式，分别导出对应的迁移前的老表和迁移后的新表，
如果不是全表的数据，可以通过SQL语句选择需要的条数
以上文中的“表1”为例，
导出老库old中的老表hxuser，保存到 hxuser老.txt 中
以及新库new中的新表hxuser，保存到 hxuser新.txt 中
2.对于非直接复制的表
需要在Navicat中先用SQL语句查询到对应的迁移前的老表数据和迁移后的新表数据，然后再用txt格式导出
以上文的“表（2）”为例
1) 先用SQL查询迁移前的老表数据，并导出
2) 再用SQL查询迁移后的新表数据，并导出
3.新旧数据比对
使用Beyond Compare比较老数据和新数据是否一致，一致则说明迁移正确，不一致则说明迁移中存在问题
继续用上文的“表1”为例，比较上一个步骤导出的 “hxuser老.txt” 和“hxuser新.txt”
如果数据一致，则在Beyond Compare中不会有数据差异
如果数据不一致，则在Beyond Compare中能比较出差异数据，并且能直接能定位到差异数据所在，可以统计到新旧数据所有的差异点
方法2：
测试工具：
Navicat，文件MD5生成工具（以Hash为例）
测试流程
测试流程基本和方法1一致，只有在进行第三步“新旧数据比对”有区别，这里是使用Hash工具。
使用Hash，为新老数据文本生成 MD5 值，并比较2个MD5值是否一致，一致则说明迁移正确，不一致则说明迁移中存在问题
（MD5可以为任何文件（不管其大小、格式、数量）产生一个独一无二的md5“数字指纹”，如果任何人对文件做了任何改动，
其MD5也就是对应的“数字指纹”都会发生变化，MD5只会对文件内容进行运算，并不对创建时间，文件名等进行比对）
继续用上文的“表1”为例，分别用Hash为 “hxuser老.txt” 和“hxuser新.txt”生成MD5值
可以看到如果数据一致的时候，MD5值是一致的
当数据不一致时，MD5值也会不同
方法3
测试工具：
代码脚本（任何一种语言都可以，Python和Java优选）
测试流程：
这里可以开发自动化测试脚本，来完成整个测试，这里因为都是在做字段的比对动作，所以尽量开发可以复用的测试脚本
几种方法比较：
新老系统数据库表结构变化测试
新增字段和老系统表完全不存在关系
对于这种“新增字段和老系统表完全不存在关系”的测试，因为都是在新表中给新增字段一个固定的默认值，所以只需要根据开发提供的填写规则，检查该字段的所有值是否满足填写规则。
测试工具：
Navicat
测试流程：
以上文“表3”为例，这里需要检查agent库中表hxuser的status字段的所有值是否都为“1”
其实只需要4步就能完成所有的测试
1.范围及规则确定
开发部门统计好所有新加字段填写规则给到测试部门
2.计算新字段所有行数
计算表hxuser的status字段对应的所有行数，可在Navicat运行SQL语句：
SELECT COUNT(status) FROM hxuser
3.计算新字段中满足规则的行数
计算status字段中值为1的所有行数，可在Navicat运行SQL语句：
SELECT COUNT(status) FROM hxuser WHERE status=1
4.比较两次的行数
比较以上2步计算的行数是否相同，如果相同则表示测试通过，如果不相同则表示新增字段中有不满足取值规则的行，
可以通过其他的SQL语句来定位不满足取值规则的行
新增字段是由老系统特定字段转换而来
方法1
测试工具：
代码脚本（任何一种语言都可以，Python和Java优选）
测试流程：
以上文“表3”为例
1.范围及规则确定：
开发部门统计好所有转化字段以及转化规则给到测试部门
2.测试脚本开发
根据“范围及规则”，编写对应的测试脚本，以达到校验新老字段的所有值是否满足规定的转化规则
3.实施测试
运行测试脚本，检查是否测试通过，若未测试通过，可以做进一步的异常数据定位
方法2
如果没有条件使用测试脚本自动化测试时，可以使用人工的切片抽样测试
测试工具：
Navicat
测试流程：
1.数据切片抽样
用Navicat筛选到需要校验的新老数据，假设需要校验的数据有n行，然后对n行进行分段切片抽样，
影响分段的密度，分段后每一段抽取的数量的因素很多，需要综合考虑之后，确定一个最优值，可以主要参考以下2点因素：
1) n的大小，如果n在100以内，我们甚至可以对n行全量抽取，如果n的值很大，则可以把n均分为若干段，然后在每段中随机抽取相同的数量的行数
2) 实际工作中可以使用到的工时及人力资源，如果很充足的话，我们可以相对高密度的分段，每段大数量的抽取；
如果很紧张的话，那我们只能相对低密度的分段，每段少数量的抽取。
2.数据校验
针对上一步抽样得到的数据，人工检验其是否满足转换规则
几种方法比较
业务逻辑测试
“基本数据迁移测试”和“数据库表结构变化测试”做完以后，需要使用从老系统中迁移过来的数据，在业务系统中进行流程测试，功能测试确保迁移后到数据可用。
在做功能测试时要注意以下2点：
1.需要和开发部门确认新系统会用到老表数据的业务都有哪些，但是每一张表涉及的业务会非常的多，所以想百分百的覆盖所有业务是非常困难的，只能在有限的资源下统计相对全面的的业务范围，这些业务点也就组成了针对数据迁移的功能测试范围。
2.上面这点也说到了，测试的“新系统会用到老表数据的业务”肯定是不全面的，所以最后一定要做一轮全系统的功能回归测试。
注意点
1.账号权限，在Navicat操作数据库时，对于线上数据实施迁移，一定需要提前申请到有线上数据库操作权限的账号
2.上述各种测试方法的采用，一定要结合实际的资源情况，不要盲目追求全自动化测试，我们最终目的是要达到测试效果
3.业务逻辑测试中不要去追求百分百的覆盖率，只需要在现有的资源下，尽可能的提高覆盖率
