数据迁移的需求背景
公司内部出现业务先合并、新旧系统替换、业务扩大需要进行数据库分表等情况下，就需要涉及到数据迁移。对应的常见的迁移场景有：
1、需要将两个系统的部分数据统一从A数据库读取，a数据库和b数据库通过指定字段进行关联的情况。
2、直接废弃旧的系统，将旧系统的数据迁移到新系统，后续仅维护新系统。
本文主要总结分享比较场景的数据迁移场景，业务线合并，2个系统的用户数据进行关联的场景。
测试分析
正式环境用户数据分析
在进行数据正式迁移之前，产品/开发/测试均需要参与对线上已有的用户数据进行分析，分析线上大量用户的数据特征，从而进行归纳分类，对不同的分类数据进行迁移策略设计。
以用户账号为例，可能存在：用户使用手机号注册、用户未使用手机号注册等情况，在进行分析时需要考虑到对这两种的用户数据进行迁移的策略。
假设迁移的目标库存在该用户数据，则根据基础信息以目标库为准，并建立源库和目标库的关联关系。
假设迁移的目标库内不存在该用户数据，则直接将源库的用户信息同步在目标库内进行创建。
数据迁移测试分析
数据迁移目标是什么
在进行数据迁移测试之前，需要了解到对应的迁移策略，了解两个系统的数据如何关联，以及对应的目标数据库和源数据库，通过两个数据库数据创建关联：以源数据库b为基础在目标数据库a中创建关联，且将b中的相同的基础字段数据直接选择性的覆盖填充到目标库a中。
在迁移过程中，关联数据部分基础字段冲突的处理逻辑。
若两个数据库相同字段同时存在数据：
选择行覆盖：b内的数据覆盖a内的数据；
选择性丢弃：按照优先级，直接丢弃b内的数据，以a的数据为准（或者丢弃a数据，以b数据为准）。
源数据库和目标数据库的同一个字段的规则差异。
除了数据兼容冲突兼容外，还需要考虑数据库兼容，所谓的数据库兼容就是字段的长度、类型等。例如：
1、字段长度限制。
2、字段区分大小写：例如：用户邮箱，在源数据库内支持大小区分，但是在目标库内不支持。
3、字段支持特殊字符：例如用户昵称在目标数据库内不支持特殊字符，但是在源数据库内支持。
4、字段格式不合法：例如手机号格式、邮箱格式。
迁移方案
在评审阶段，与开发产品确认对应的迁移方案：
1、正式迁移时，是否需要停机。
2、评估迁移失败产生的风险以及对应的解决措施。
3、在测试阶段进行迁移：
a)是否允许针对指定的数据进行迁移测试。
b)测试期间未停机导致的脏数据如何处理。
c)评估迁移失败可能产生的风险，是否可进行数据恢复。
4、迁移准备：提前根据测试分析的各个迁移场景，准备对应的“待迁移”数据，数据要尽可能的模拟线上用户真实数据。
迁移验收
数据迁移成功后验收，需要基于业务场景的角度进行数据对应的功能场景验收，必须要覆盖「增」、「删」、「改」、「查」。
【新增】：迁移后往新的数据库内添加数据后，在软件内访问个人中心查看用户信息获取正确。
【查询】：对用户的基本信息进行迁移后，需要在软件内访问个人中心查看用户的信息是否获取成功，是否有异常报错。
【修改】：对用户的基本信息进行修改，修改后数据存储成功，再次访问个人中心可展示最新的用户数据。
【删除】：删除用户数据后，该用户无法访问。
发布留观
由于迁移数据版本发布后，势必会影响到用户的数据，所以在分析阶段对用户可能出现的反馈制定出对应的应答策略，提前进行人员分工。同时关注由于发布后的功能使用情况。
用户反馈
发布后对用户反馈及时响应，快速定位用户的数据出现变更是否由数据迁移引起，以及如何引导用户正常继续使用，提高用户的满意度。
留观数据
重点梳理关于迁移数据涉及到的相关的核心接口数据，在发布后进行定时监测：
1、相关接口调用量：关注数据迁移后，接口的调用量是否暴涨。
2、相关接口错误率：关注数据迁移后，接口的错误率是否异常上涨。
3、相关接口告警率：关注数据迁移后，接口的告警率是否异常上涨。
小案例
以上是个人对于小部分数据迁移测试后的总结反思。一个人必须不停地总结归纳，才能不被茫茫人海淹没～
版权声明：本文出自51Testing会员投稿，51Testing软件测试网及相关内容提供者拥有内容的全部版权，未经明确的书面许可，任何人或单位不得对本网站内容复制、转载或进行镜像，否则将追究法律责任。
