二、迁移类测试策略

1、概述

随着业务需求或数据量增长到一定程度，往往需要进行数据库切换，这里就伴随这数据迁移。

关键字： 全量数据迁移，增量数据迁移，分库分表，数据双写，oracle、mysql、hbase…，新老数据兼容，数据订正

2、发布方案(迁移方案)

两大类：正常发布、停机发布

正常发布：可以实现线上业务无缝切换，不影响用户使用，需要保证新老数据兼容，发布过程中的数据写入等。

停机发布 : 优点在于可以避免发布过程中的新数据写入，缺点是发布过程中，不能正常提供服务。

发布方案的制定是根据具体业务情况制定发布方案，对业务无影响的情况下较常采用停机发布，方便简单。

介绍一种无缝对接的正常发布方案

A库历史库 mysql分库分表 到 B库新库hbase

步骤1、全量dump1：A库数据全量迁移至B库

步骤2、打开双写：同时写入到A库历史库和B库新库

步骤3、全量dump2：开启双写前的所有差集，将差集灌回B数据库，这里是补充全量dump1期间和开启双写前只写入到A的数据。保证了A、B数据库数据的完全一致，同时已经开启了双写。

步骤3’、测试介入，可对A、B库取某一时间段前所有数据进行数据验证。

步骤4、停止对A库的写入，发布前端应用，切换至B库新库

注意点：

1、双写时，B库不存在被写源数据或B库数据状态异常等情况，需要从业务上考虑，是否直接从A库中获取数据并覆盖至B库

2、以上步骤中的多次dump和双写有多个写入B库的场景，需要以保证B库和A库一致为原则，如B库的重复写入等情况的处理。

3、测试策略

在进行数据迁移测试前，需确认的CheckList

CheckList

1、 哪些表需要迁、哪些表不需要迁；需要迁移的表老库和新库的对应关系是怎样的

2、 明确表的关联关系，关联表是否需要迁移，不迁移怎么处理

3、 迁移的表中，哪些字段要迁移，哪些不迁移，对应关系是怎样的

4、 新表中的字段，老表是不是一定有，如果不一定，怎么处理可能为空的情况，尤其是必填字段的处理

5、 迁移前，新表是否为空，不为空是否可能存在数据重复的情况，怎么处理

6、 新老表中的字段类型、长度的定义是否一致，可否正确转换

7、 需迁移的表数据量为多少

8、 开发做了哪些数据迁移正确性的保障

针对不同的业务场景需要测试人员设计不同的测试方案，主要都是两个层面的验证，数据层面的数据验证和功能层面的功能验证

1、数据验证：使用工具或设计对账程序全量验证

a、全量数据验证

b、增量数据验证

c、抽样数据验证

根据业务情况判断需要进行哪一项或几项数据验证

工具使用：可以选用目前较成熟的迁移工具：愚公移山， 兼全量数据验证和增量数据验证功能

验证方式：若迁移场景不在愚公的适用范围内，全量验证和增量数据验证需要另外设计适用于该场景下的数据验证方案

可采用的一些验证方式：考虑根据不同数据的存储方式，数据量的大小

a、关系数据库，直接新老数据库中jdbc方式获取数据，一条条进行对比，新老数据存在规则转换的情况需要在对账程序中同时进行规则判断。

b、全量或抽样dump历史库和新库两份文件进行对比，数据库非常大的时候推荐使用hadoop

32/3<123>