以下为作者观点:
数据迁移,是在保证新旧系统业务连续性的前提下,将数据从旧数据库迁移到新数据库的过程,测试前通过迁移策略和方案了解新旧系统数据如何重构与关联,测试过程需确保数据迁移的正确性,主要体现在技术层面,确保数据0丢失,数据库库表处理正确,字段映射正确;业务层面确保数据量、各数据转换正确,确保业务连续性,数据能向后、向前兼容性测试,同时新旧功能可以正常使用,相关报表正确。
迁移测试关注的重难点?风险?
可能有同学会问:数据迁移测试需要关注哪些点?测试过程可能存在哪些风险呢?
首先,需要关注数据迁移的技术细节。数据迁移通常有两种类型,同类型数据库的迁移和不同类型数据库的迁移,不同类型的数据库迁移可能涉及表结构变化、编码和语法上的差异,会加大迁移的难度。在表结构方面,有的迁移是直接复制表,有的迁移是进行表结构拆分与合并,后者测试时需关注各表字段、类型、长度、映射等变化。迁移数据规模程度也会影响到迁移的结果,数据量大,数据库表迁移准确性难度增大。
另外,还需要关注迁移时点的数据的业务状态。通常来说,迁移时服务器应用会提前停止服务,并进行必要的数据检查,避免迁移期间产生新的业务或操作系统带来的迁移问题。若迁移涉及表结构的变更,表字段新增、修改、删除等变化。测试时需关注各表的更正情况,数据、报表变化情况。
最后,需要关注迁移时点前后的业务规则变化。除了考虑新系统的规则变化,还要考虑旧数据迁移后需要进行规则适配,例如旧系统没有,新系统有的字段,验证是否给到正确的默认值。保证旧系统数据迁移后业务的可用性与连续性,避免迁移后需重新回滚测试。
接下来,我们将详细介绍数据迁移的测试策略及测试实施,话不多说,上干货~
迁移测试验证策略与计划
一、需要熟悉迁移方案
了解新老系统上线方案,以及数据如何迁移,存量兼容数据如何处理。新老系统切换时是否关闭批量处理、日终初批处理服务。上线后,旧系统设备如何处理,是废弃还是继续使用。在数据并账方面,流程如何处理,账务如何迁移。在数据同步方面,了解同步时间策略和同步范围策略,是全量同步还是增量同步。
以商票系统为例,迁移总体技术方案采用编写迁移shell脚本,先在旧库建立与新库业务表相同字段的临时表,在旧库进行数据的筛选、加工至临时表,再将临时表中的数据导出成表数据文件,到oracle数据库使用sqlldr导入informix数据文件。存量数据一次性迁移,增量数据实时迁移方式进行迁移。迁移时点为日初后迁移,新系统上线后,旧系统依然在使用,故测试时不仅要验证迁移数据在新系统的业务验证,还需要对旧系统进行回归验证。
二、需要了解迁移范围和迁移规则
熟悉完迁移方案后,需圈定迁移范围才能针对性进行测试验证,分析是否涉及基础数据迁移,历史业务数据迁移,是否涉及流程中的数据迁移。
1.关注迁移数据种类和状态,不同类型数据测试关注点不同,例如:基础数据迁移后需要关注新旧系统数据一致性,纯历史数据迁移后,除了数据一致性外,还需要关注迁移后在新系统的查询和业务是否正常。流程中的数据需要关注每个环节的状态,关注在途业务是否能进行后续处理。
2.了解数据迁移规则,数据库变化点、字段变化如字段类型、长度、映射关系,根据规则设计测试案例,确保迁移后映射正确。
3.关注关联系统供数相关文件,分析涉及迁移的关联系统数量,以及相应的卸数文件,验证迁移后卸数给关联系统文件数据量以及字段的正确性。需要特别注意的是,编码方式可能产生变化,需及时同上下游系统同步,制定解决方案,避免乱码产生。
三、需要注意备份和回滚方案
涉及数据备份与回滚与应用备份与回滚,若迁移失败或迁移出现问题时,能及时进行迁移回滚。迁移时特殊情况考虑,如本次商票系统,生产发现有维护错或者缺失的记录,通过新设置的维护功能进行手工维护。
四、制定数据迁移测试计划
测试主要通过技术手段和业务手段的验证来确保迁移的正确性。测试前,根据SIT各轮次测试安排,规划数据迁移验证时间。通常在SIT三个轮次中安排两轮迁移测试,如果有UAT5回归测试,可在回归环境验证一轮。迁移涉及环境的重置,如果有外部联调单位,还需根据联调单位来调整迁移测试时间安排。
经验总结:
技术层面主要验证以下几点:
①数据量0丢失,包含数据是否有多迁移或少迁移,测试根据根据迁移规则筛选数据量,迁移前后进行迁移前后SQL检查。
②数据库测试点:数据库表、字段处理规则;字段映射,迁移规则验证。
③迁移日志检查,检查迁移分步处理是否合理,数据记录是否正确。
④迁移初始值,如特殊流水号、业务ID、账务ID等流水号的配置和处理。
⑤考虑异常情况,异常数据,异常交易,异常处理时情况。
业务层面主要验证以下几点:
①登记簿报表功能及数据准确性;
②功能可用性;
③业务连续性。
迁移测试准备与测试实施
迁移测试准备:
测试数据准备:数据预埋是测试前很重要的准备环节,决定是否有足够的,完整的数据满足迁移测试。确认迁移方案与计划后,准备迁移测试的数据,对于复杂场景,一定要梳理好场景表,根据梳理好的场景表等进行数据预埋,埋数结束需确认预埋数据完整性,避免切换系统后无法再增补所需数据。这部分数据可以在进入SIT测试时优先验证,因为部分数据有时效性,例如票据可能到期结清,无法用于后续业务连续性测试。
迁移前数据备份:迁移前相关业务报表数据导出备份,后续迁移测试进行核对。开发也会将迁移前预埋数据库备份,预防迁移问题需回滚。
迁移测试实施实例:
还是以商票系统为例,首先进行数据量验证,涉及以下两个方面:
①新旧系统业务表/公共数据表的查询、统计、前后端对比来校验;
②涉及公共的机构表数据、用户数据量确保数据的准确性。
其次,进行数据准确性验证:
①确保数据0丢失,根据迁移规则筛选数据量确保迁移前数量与迁移后数量一致;
②数据库测试点,通过对比迁移前后的数据库表、字段处理规则,字段映射,迁移规则进行验证。
③涉及公共表的机构、用户数据量岗位的权限准确。
第三,登记簿报表验证,主要涉及验证总行全辖、分行等各机构买卖登记簿/日终余额登记簿数据各字段是否正确、总数是否正确;最后进行功能可用性验证和业务连续性验证。
功能可用性验证和业务连续性验证主要验证以下方面:
①旧数据、新数据在新系统操作流程是否受到阻碍;旧系统在新系统挑票界面可以正常挑到票,以及等分化的票据业务流程不受影响。
②能查询老数据、也能查询新数据;涉及新数据/老数据迁移后均能在新系统登记簿查询到,以及老数据均能在老登记簿查询到。
③业务连续性验证,涉及票据迁移(传统票据贴现后),能保证后手业务能正常开展;涉及公共数据,保证用户或机构下相关业务能正常开展。
④最后是特殊情况和异常校验,流程中的数据(在途业务的处理),流程中的数据需要关注每个环节的状态,关注在途业务是否能进行后续处理。