在测试工作中，如果赶上App改版或者重构，很难躲过数据迁移这个老大难问题。对于测试，迁移相关的工作也是相当头大，基本上一个考虑不周就极易会有迁移失败或者脏数据的产生。下面就来说说我们在数据迁移过程中的工作及注意事项，希望能尽量避免大家会遇到的问题：
1. 确认迁移需求
这个永远是一切的开始，无论做啥没有需求就没有后续的工作。在迁移过程中需要确认的需求有很多，也有很大一部分是和业务紧密相关的，所以下面就来说说常见的需求。
a. 双向迁移还是单向迁移。如果是单项迁移，是老系统向新系统迁移还是新系统向老系统迁移（虽然场景很少）。
b. 需要迁移的数据&不需要迁移的数据。
c. 触发迁移的方式（实时自动迁移 or 人工迁移）、迁移过程中的UI展现及迁移后结果的UI展现。
d. 是否只迁移一次，还是可以多次迁移（增量更新）以及迁移时的覆盖逻辑等。
e. 原数据包含空字符串、默认值、null等迁移后展现。在迁移后的系统上该如何展示之前系统中内容为空字符串、null、默认值等的数据。
f. 迁移时间。对迁移效率有什么样的期许，可以接受的最长时间。
g. 各业务自己的逻辑注意事项及其他...
2. 和RD沟通迁移技术方案
这个事情往往被忽视，因为大部分测试并不关心数据迁移的技术方案，而只关心迁移的数据是否一致。但是其实了解迁移的技术方案有几点好处：
a. 可以根据RD的技术方案提前找到技术漏洞，如内容默认值等细节问题，尤其是在RD根据需求讲解技术方案的时候。
b. 在code review时可以根据方案的内容很快的切入到编码逻辑中。
c. 可以提前开始测试工作，比如：如果知道迁移是通过队列发送消息触发，就不用等到RD提供接口或者UI再开始测试，直接自己发消息就可以了。
d. 发现问题后的定位更为准确。
3. 整体测试
这就是测试的重头戏了。
a. 首先重要的事情说三遍，数据，数据，数据。迁移的最主要东西：数据。
刚才在需求里面其实说了很多关于数据的事儿，老系统和新系统在迁移后所有需迁的字段当然要保持数据的一致。然而，这里面的不可见细节还是很多的。数值精度，字符串长度，日期格式，null值转化，空字符串转化，特定格式校验（手机号等），附件能否打开等都需要注意。
b. 数据量匹配
这个不用多说了吧，数据量应该前后是一致的，除非有业务的特殊需要。可以以抽样数据迁移前后是否一致来测试，如果很重要的项目，需要加大样本量。
c. 大数据量迁移。
一些迁移的问题在小数据量的情况下很难发现，但是如果增大数据量就会暴露一些问题。如大数据量迁移下出现的数据缺失，程序死锁，性能缓慢，缓存溢出等问题。
需要注意的是，大数据量不止说数据的条数多，还指单个数据里面的数据体量大，如很多的附件等。
d. 多次迁移（增量迁移）
在老系统上修改或者删除一些数据，然后去验证迁移后新系统是否符合业务需求。
e. 双向迁移
同多次迁移，需要验证迁移后新老系统是否符合业务需求。
f. 迁移效率
在实时迁移（数据同步）时，查看双方数据同步的效率是否满足需求需要。
g. 接口自动化测试辅助
人眼始终比不过电脑。一个两个病历还可以比对，再多人也受不了。这个时候就需要自动化测试的帮助了。比如新老版本都是有获取用户信息的接口的，然后我们要测试迁移完成后数据的一致性，接口测试就能派上用场。写完了一个接口测试，只要去变换不同的用户，就可以去验证他们的数据是否一致。
h. 服务端日志监控
千算万算，很难能够模拟好所有可能遇到的场景。这时候通过监控迁移所在服务的日志往往能够看到一些考虑不到的问题。
网友评论