数据迁移软件测试应该承担的任务你知道吗？

草帽路飞UU

数据迁移的需求背景

　　公司内部出现业务先合并、新旧系统替换、业务扩大需要进行数据库分表等情况下，就需要涉及到数据迁移。对应的常见的迁移场景有：
　　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、相关接口告警率：关注数据迁移后，接口的告警率是否异常上涨。

　　小案例



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