数据迁移测试经验分享

以下为作者观点：

数据迁移，是在保证新旧系统业务连续性的前提下，将数据从旧数据库迁移到新数据库的过程，测试前通过迁移策略和方案了解新旧系统数据如何重构与关联，测试过程需确保数据迁移的正确性，主要体现在技术层面，确保数据0丢失，数据库库表处理正确，字段映射正确；业务层面确保数据量、各数据转换正确，确保业务连续性，数据能向后、向前兼容性测试，同时新旧功能可以正常使用，相关报表正确。

迁移测试关注的重难点？风险？

可能有同学会问:数据迁移测试需要关注哪些点？测试过程可能存在哪些风险呢？

首先，需要关注数据迁移的技术细节。数据迁移通常有两种类型，同类型数据库的迁移和不同类型数据库的迁移，不同类型的数据库迁移可能涉及表结构变化、编码和语法上的差异，会加大迁移的难度。在表结构方面，有的迁移是直接复制表，有的迁移是进行表结构拆分与合并，后者测试时需关注各表字段、类型、长度、映射等变化。迁移数据规模程度也会影响到迁移的结果，数据量大，数据库表迁移准确性难度增大。

另外，还需要关注迁移时点的数据的业务状态。通常来说，迁移时服务器应用会提前停止服务，并进行必要的数据检查，避免迁移期间产生新的业务或操作系统带来的迁移问题。若迁移涉及表结构的变更，表字段新增、修改、删除等变化。测试时需关注各表的更正情况，数据、报表变化情况。

最后，需要关注迁移时点前后的业务规则变化。除了考虑新系统的规则变化，还要考虑旧数据迁移后需要进行规则适配，例如旧系统没有，新系统有的字段，验证是否给到正确的默认值。保证旧系统数据迁移后业务的可用性与连续性，避免迁移后需重新回滚测试。

接下来，我们将详细介绍数据迁移的测试策略及测试实施，话不多说，上干货~

迁移测试验证策略与计划

一、需要熟悉迁移方案

了解新老系统上线方案，以及数据如何迁移，存量兼容数据如何处理。新老系统切换时是否关闭批量处理、日终初批处理服务。上线后，旧系统设备如何处理，是废弃还是继续使用。在数据并账方面，流程如何处理，账务如何迁移。在数据同步方面，了解同步时间策略和同步范围策略，是全量同步还是增量同步。

以商票系统为例，迁移总体技术方案采用编写迁移shell脚本，先在旧库建立与新库业务表相同字段的临时表，在旧库进行数据的筛选、加工至临时表，再将临时表中的数据导出成表数据文件，到oracle数据库使用sqlldr导入informix数据文件。存量数据一次性迁移，增量数据实时迁移方式进行迁移。迁移时点为日初后迁移，新系统上线后，旧系统依然在使用，故测试时不仅要验证迁移数据在新系统的业务验证，还需要对旧系统进行回归验证。

二、需要了解迁移范围和迁移规则

熟悉完迁移方案后，需圈定迁移范围才能针对性进行测试验证，分析是否涉及基础数据迁移，历史业务数据迁移，是否涉及流程中的数据迁移。

1.关注迁移数据种类和状态，不同类型数据测试关注点不同，例如：基础数据迁移后需要关注新旧系统数据一致性，纯历史数据迁移后，除了数据一致性外，还需要关注迁移后在新系统的查询和业务是否正常。流程中的数据需要关注每个环节的状态，关注在途业务是否能进行后续处理。

2.了解数据迁移规则，数据库变化点、字段变化如字段类型、长度、映射关系，根据规则设计测试案例，确保迁移后映射正确。

3.关注关联系统供数相关文件，分析涉及迁移的关联系统数量，以及相应的卸数文件，验证迁移后卸数给关联系统文件数据量以及字段的正确性。需要特别注意的是，编码方式可能产生变化，需及时同上下游系统同步，制定解决方案，避免乱码产生。

三、需要注意备份和回滚方案

涉及数据备份与回滚与应用备份与回滚，若迁移失败或迁移出现问题时，能及时进行迁移回滚。迁移时特殊情况考虑，如本次商票系统，生产发现有维护错或者缺失的记录，通过新设置的维护功能进行手工维护。

四、制定数据迁移测试计划

测试主要通过技术手段和业务手段的验证来确保迁移的正确性。测试前，根据SIT各轮次测试安排，规划数据迁移验证时间。通常在SIT三个轮次中安排两轮迁移测试，如果有UAT5回归测试，可在回归环境验证一轮。迁移涉及环境的重置，如果有外部联调单位，还需根据联调单位来调整迁移测试时间安排。

经验总结：

技术层面主要验证以下几点：

①数据量0丢失，包含数据是否有多迁移或少迁移，测试根据根据迁移规则筛选数据量，迁移前后进行迁移前后SQL检查。

②数据库测试点：数据库表、字段处理规则；字段映射，迁移规则验证。

③迁移日志检查，检查迁移分步处理是否合理，数据记录是否正确。

④迁移初始值,如特殊流水号、业务ID、账务ID等流水号的配置和处理。

⑤考虑异常情况，异常数据，异常交易，异常处理时情况。

业务层面主要验证以下几点：

①登记簿报表功能及数据准确性；

②功能可用性；

③业务连续性。

迁移测试准备与测试实施

迁移测试准备：

测试数据准备：数据预埋是测试前很重要的准备环节，决定是否有足够的，完整的数据满足迁移测试。确认迁移方案与计划后，准备迁移测试的数据，对于复杂场景，一定要梳理好场景表，根据梳理好的场景表等进行数据预埋，埋数结束需确认预埋数据完整性，避免切换系统后无法再增补所需数据。这部分数据可以在进入SIT测试时优先验证，因为部分数据有时效性，例如票据可能到期结清，无法用于后续业务连续性测试。

迁移前数据备份：迁移前相关业务报表数据导出备份，后续迁移测试进行核对。开发也会将迁移前预埋数据库备份，预防迁移问题需回滚。

迁移测试实施实例：

还是以商票系统为例，首先进行数据量验证，涉及以下两个方面：

①新旧系统业务表/公共数据表的查询、统计、前后端对比来校验；
②涉及公共的机构表数据、用户数据量确保数据的准确性。

其次，进行数据准确性验证：

①确保数据0丢失，根据迁移规则筛选数据量确保迁移前数量与迁移后数量一致；

②数据库测试点，通过对比迁移前后的数据库表、字段处理规则，字段映射，迁移规则进行验证。

③涉及公共表的机构、用户数据量岗位的权限准确。

第三，登记簿报表验证，主要涉及验证总行全辖、分行等各机构买卖登记簿/日终余额登记簿数据各字段是否正确、总数是否正确；最后进行功能可用性验证和业务连续性验证。

功能可用性验证和业务连续性验证主要验证以下方面：

①旧数据、新数据在新系统操作流程是否受到阻碍；旧系统在新系统挑票界面可以正常挑到票，以及等分化的票据业务流程不受影响。

②能查询老数据、也能查询新数据；涉及新数据/老数据迁移后均能在新系统登记簿查询到，以及老数据均能在老登记簿查询到。