关于数据迁移，测试应该做什么？

数据迁移的需求背景

公司内部出现业务先合并、新旧系统替换、业务扩大需要进行数据库分表等情况下，就需要涉及到数据迁移。对应的常见的迁移场景有：

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、相关接口告警率：关注数据迁移后，接口的告警率是否异常上涨。

小案例

以上是个人对于小部分数据迁移测试后的总结反思。一个人必须不停地总结归纳，才能不被茫茫人海淹没～

现在我邀请你进入我们的软件测试学习交流群：【746506216】，备注“入群”， 大家可以一起探讨交流软件测试，共同学习软件测试技术、面试等软件测试方方面面，还会有免费直播课，收获更多测试技巧，我们一起进阶Python自动化测试/测试开发，走向高薪之路。

喜欢软件测试的小伙伴们，如果我的博客对你有帮助、如果你喜欢我的博客内容，请 “点赞” “评论” “收藏” 一 键三连哦！