数据迁移测试
在进行项目重构或者更新的时候或多或少会对数据库进行变更，为了保证业务的稳定性对数据进行迁移测试是很有必要的，因为数据就是业务的基石，没有数据业务都是空中楼阁，形同虚设，小编结合近期的工作对数据迁移测试做一个小总结，看看数据库迁移主要需要注意的事项。
数据库
数据源变更：数据库名称、数据库类型等，一般情况下在同类型的数据库之间迁移比较常见，但是也存在不同类型的数据库之间的迁移，例如：oracle到MySQL等等，非关系型数据库到关系型，关系型到非关系型。
数据表：
表名称变更
这个比较常见。
例如原来名称为a,迁移后为a1
表结构变更
这个也很常见，常见的变更如下：
字段新增：例如随着业务拓展，原来的定义的字段不能满足新业务需求，需要新增字段
字段减少：有些过时的字段新业务不再需要，例如邮编，现在几乎用不到了；还有就是有的字段迁移到其他表去了。
字段名称变更：之前有些字段命名不规范或者不贴合业务需求等原因。
字段数据类型变更：比较多的是unix时间变成YYYY-MM-DD HH:mm:ss或者反之，字符串转数字，数字转字符串
字段映射关系变更：这种情况是表示某种事务的状态比较多。例如订单的状态：1、2、3，数据删除状态：0、1等，在迁移后可能有新的映射关系。映射值比较类型变更，例如之前等于某个值即可表示某种状态，后面迁移只后要对值进行位运算才能判断，或者进行集合运算才能判断，例如判断值是否在某个范围，或者包含某个值才表示某个状态；另外还有一种情况就是这个字段映射到那个字段去了不一定和之前的字段对应。
表数量变更：现在都流行分库分表，原来可能只一个表，迁移后可能存在三四个表；也可能存在多个表合并成一个表的情况。
表约束变更：比如之前有些字段不能为Null，后面迁移可以为NULL。
表索引变更：迁移后索引名称或者字段发生变更，索引变更后如果之前的一些关键字段没有索引可以通过中间表的索引进行转换，不然数据量大的情况下没索引寸步难行。
迁移关系：
一对一（或者单表分片）的数据迁移：
确定对比字段时一般以旧表字段为对比字段。
这种关系一般比较简单就是从一个表迁移到另外一个表，大部分字段也会保持一致，会有很少的字段发生变化，这个时候只需要根据相应的字段进行新旧表关联数据查询即可查询出旧表关联的新数据，进而进行数据对比。当然还有种情况是虽然是单表一对一迁移，但是迁移后可能进行了分表操作，这时候就需要将新表都联合起来进行查询，假设A为旧表，B为新表如：
SELECT
A.对比字段1,
A.对比字段2
…
FROM oppo_cn.order_receipts AS A
JOIN (
SELECT * FROM a.t _0
UNION ALL
SELECT * FROM a.t __1
UNION ALL
SELECT * FROM a.t __2
UNION ALL
SELECT * FROM a.t __3
) AS B ON A. id = B.id
B表以此类推。
这种情况一般都是以旧表字段为对比字段，因此如果B表字段有差异的话需要进行转换，例如时间格式不一致等。
一对多的数据迁移：
确定对比字段时大部分字段以旧表字段为准，有的会以新表字段为准。
有些时候也会存在旧表一张业务表在新表对应多个业务表，旧表中不同的字段分布在不同的表中。这种情况旧稍微复杂一点，需要从新表中分别查出旧表对应的字段。有的字段需要以旧表为对比标准，有的需要以新表字段为对比标准，这个要具体业务具体分析。这种情况下一般会存在数据拆分或者数据合并的问题。例如旧表中的一个字段之前是一个数组，在新表中对应多个分散的值，这个时候就需要巧妙的运用CASE WHEN 条件语句、子查询、聚合函数了。
多对多
这种关系一般极少几乎不存在这样的对应关系，确定对比字段要结合具体业务分析。
白名单
有的数据迁移配置了白名单，某些字段符合白名单规则才迁移，此时在写数据脚本时需要考虑到白名单的情况。
确定测试方案：
知道上述差异后我们就可以拟定测试方案了，因为一般在数据迁移的过程中表结构多多少少有些变更，我们再迁移关系中确定对比关系后就知道怎么展开测试了，当然一般数据库中的数据都不会少，所以如果肉眼去对比的话既耗时也不准确，很容易看错，所以最好的办法还是设计脚本进行数据对比。一般情况是将SQL单独分离出来，然后结合脚本来进行数据对比，可以用pandas的compare方法实现数据对比，小编是将查询出来的数据存进Excel然后使用pandas进行对比，不得不说pandas在处理批量数据时还是有一定优势的。
注意事项：
数据对比过程中有些缺省值需要做转换，如NULL，0，‘’，‘0’这些字段这个还是得结合具体业务来分析。
还没有评论，来说两句吧...