系统升级了，旧数据就不要了么？
摘要：软件系统中的数据移植是指将旧系统中的数据、应用程序、个性化设置等迁移到新系统，以保证新系统上线后的业务正常进行，广泛应用于系统升级、重构场景。数据移植测试贯穿整个测试过程，具体体现在以下几个阶段：
一、准备阶段
数据移植执行前，测试人员需对数据移植的各项信息进行了解分析：
1、移植数据规模、数据类型以及数据范围
在测试准备阶段需了解本次系统升级影响的数据规模，根据移植数据量评估数据移植时长，计算系统受影响时长；梳理移植数据类型，如合约、流水、配置等，便于分析其影响交易、制定测试范围；分析移植数据范围，如对某些省份、区划、机构所属数据进行移植，判断是否对剩余部分正常交易产生影响。
2、数据移植方法
一般来说，数据迁移有数据直接复制、数据抽取合并（拆表、合表）、数据处理转换等几种，测试人员通过数据移植类别，确定迁移方法，合理设计测试场景，同时还需关注数据迁移是否有新增、删除字段。
3、新旧系统兼容性
当新旧系统采用不同数据库、框架、编码模式时，需对新旧系统兼容性进行分析，根据迁移方案研究是否有因新旧系统不兼容导致的数据迁移问题，如将数据从Sybase数据库迁移到Oracle数据库，两个数据库字段定义类型、数据类型可能存在不兼容，Sybase对空值处理为长度为1的空格，而Oracle则为NULL，拼接报文时会因缺少字段而报错，测试时需特别关注。
4、新旧系统业务差异性
新旧系统存在业务差异时，分析新旧系统交易清单差异，关注存量交易、新增交易、在途交易等，判断是否需在移植前进行冗余数据治理或残缺数据补录，以保证客户的交易连续性。
5、确定新旧系统迭代情况
数据迁移后，如新旧存在并行期，需了解业务处理模式，确定旧系统存量数据处理方式。
二、执行阶段
测试人员构造场景开展模拟测试：
1、移植过程验证
在测试环境模拟数据迁移，验证移植脚本的有效性，分析迁移过程的风险。若移植过程中系统继续支持交易，则需在移植过程中进行功能性测试，保证移植过程中交易不受影响。
2、移植中断场景测试
关注移植过程异常中断时，是否会造成数据丢失，是否支持中断后继续移植。
3、应急回退测试
移植过程异常中断时系统应支持应急版本回退测试，测试人员需对此场景及回退版本进行功能性测试，保证回退完成后的业务处理正常。
4、移植脚本性能测试
在移植过程中对移植脚本性能进行监控，监测移植程序执行时长及相应服务器性能表现。
三、验证阶段
数据迁移完成后，需要对数据迁移质量进行检查，以确保新系统能够正常启用并代替老系统提供服务。测试主要从以下几个方面进行:
1、后台数据验证
当数据移植采取直接复制方法时，需对迁移前后的数据一致性进行比对，迁移数据条数应完全一致，表名、表结构、字段对应关系准确，对数据的格式、字符、长度验证确保无乱码、截断现象；若迁移过程中进行了拆表、合表等数据抽取合并操作，需要核对新旧系统表结构及字段类型对应关系无误；迁移过程中涉及数据处理转换，则需对处理结果进行验证，通过模拟数据处理过程，验证新系统数据为正确的处理输出。
在数据处理过程中可以借助数据库操作工具通过执行SQL将旧数据按照新数据库表结构进行数据处理，生成新数据库相应格式的输出文件，在数据比对过程中，可以借助编程语言进行数据量比对，也可借助Java、Python等编程语言实现数据抽取、处理及比对，以Python为例：
数据抽取、数据处理：
数据比对：
2、前台业务验证 通过前台查询等业务判断后台数据迁移后是否有丢失、重复、乱码、截断等问题，校验移植前后数据一致性，同时对交易进行连通性回归测试，确保迁移后数据可用。
3、业务逻辑验证
系统升级进行业务迁移应以不影响客户业务为前提，对于业务流程复杂的交易，测试人员应该在迁移前在旧系统中设置每个步骤断点，进行埋数，迁移后在新系统中验证每个断点后可以正常继续业务，以保障业务逻辑性完备，可详细阐述为下图：
在互联网发展日新月异的今天，软件迭代速度加快，数据移植测试更加频繁，测试人员只有关注数据移植全流程，更加准确的分析数据影响、理解移植技术，才能保证测试质量，助力系统升级。
页:
[1]
