信息时代,随着用户数量不断增加,业务量不断增长,企业原有数据库不足以有效支撑业务的发展,在此情况下,企业更多的是寻求一款更加稳定的数据库进行替代。本文以Sybase数据库和Oracle数据库为例。
Oracle数据库是目前世界上流行的关系数据库,采用多进程多线索体系结构,而Sybase数据库采用单进程多线索体系结构。两者均采用多线索的模式,该模式能用较少的线索管理大量的用户进程,降低了对系统资源的占用,提高了系统资源的利用率。多进程较单进程的优势在于,能实现数据库事务的并行处理,提高并发事务处理的响应速度,避免了单服务器结构中很容易造成服务器进程瓶颈,进而避免了因此而引起的单服务器进程死锁。因此,当前企业一般以Oracle数据库替代Sybase数据库。
数据库迁移后,需要测试人员进行有效的验证,以保障系统的可用性,这是一个必不可少的环节。本文以实际项目测试经历为依据,对数据库表结构及迁移数据的测试方法、经验进行了总结,供测试人员使用。
1、数据库表结构测试
数据库迁移普遍会涉及表字段的变换,包括字段的新增、删除或修改等情况,此时,测试需关注以下3个方面:
(1)新增字段测试:关注表结构,检查新库中新增字段的字段类型是否与预先定义一致;检查迁移前后新增的字段在数据库记录中是否有值及其正确性。数据库迁移后,新增字段根据业务需求可能会存在以下两种插入方式:一是系统上线前就通过数据变更导入数据,这种情况下我们需要验证该新增字段在数据库表中是否都已按照业务需求填充完整。二是系统上线后,客户发生实际业务后获取并填充该新增字段,针对这种情况,则建议验证涉及该字段增删改查的系统功能在迁移后能否正常使用。
(2)删除字段测试:关注表结构,检查删除的字段在新库中是否已被删除,确认被删除字段数据是否需要导入新库,还是直接删除,如需导入新库,需确定数据导入规则,然后验证导入后数据的准确性、完整性等。此外,需要选择关联功能进行验证。
(3)修改字段测试:关注表结构,检查新库中新增字段的字段类型是否与预先定义一致。数据库迁移时,部分字段类型、字段内容可能会发生改变。针对字段内容发生变化的情况,也需要验证相关系统功能能否正常使用,以及表中数据的准确性及完整性。针对字段类型,Sybase及Oracle数据库存在一些差别,以Sybase的datetime字段为例,它保留了毫秒级的数据,而Oracle的date类型只保留到秒级别数据,因此测试时需要关注因字段类型变化带来的数据一致性问题。同时,在测试时要极为关注,并与开发确认字段类型的差别是否会对系统功产生影响。下表列出了Sybase及Oracle部分常见字段类型,供测试人员参考:
表1 Sybase及Oracle常见数值类型
2、迁移数据测试
对于进行数据库迁移的数据,要关注以下几点:迁移过程中出现的脏数据,数据的提取方式,迁移前后的数据一致性。
(1)脏数据
脏数据是指源系统中的数据不在给定的范围内、对于实际业务毫无意义、数据格式非法、以及在源系统中存在不规范的编码和含糊的业务逻辑。数据从Sybase数据库中迁移出来时会有一部分脏数据,包含重复数据、无效数据、不可见数据等,首先需要在Sybase数据库中处理脏数据,再导出数据,最后将数据导入Oracle数据库。所以迁移后:
Oracle数据库的数据量=实际迁移数据量=迁移前Sybase数据量-脏数据量。
(2)数据提取方式
数据的提取是为了更好的进行数据一致性对比,考虑到Sybase数据库与Oracle数据库导出数据的规则不同,直接对比各自导出数据文件需要进行大量的格式和文本转换,我们采用直接从两种数据库中查询,然后以统一格式生成文本文档的方式提取数据,并在数据之间以特定的分隔符进行分割。在实际操作中需要针对不同处理字段类型,定义不同的转换函数,例如定义一段Oracle数据库中clob字段转string的函数:
然后通过用Java语句提取到文本文档当中,而Sybase数据库中的字段则可直接转为string然后写入文本文档。
这样就可以获取到格式为TXT的数据提取文本。
(3)基于Beyond Compare工具进行数据对比
Beyond Compare是一种文本比对工具,此工具主要用途是对比两个文件夹或者文件,并将其差异以颜色标出。针对迁移前后数据的一致性测试,我们的基本思路是对于没有发生改变的字段的数据进行全量的文本对比,再采用抽样的方式选中一部分数据进行所有字段的人工对比。前文中数据库结构测试里的表结构在这里就是数据一致性测试的一个基础,确定了需要使用文本对比的字段。在Beyond Compare工具中,选择文本比较,将两份提取出的数据文本分别放入两侧对比框中,将立即对文本进行比较,并标注出有差异的项。一般选择显示差异项来锁定有差异的数据。当两份文本对比无差异时,我们就可以确认数据库迁移前后的数据是完全一致的了。
图1 Beyond Compare比较界面
以上,便是我们本文的主要内容。当然,数据库迁移测试,并不能只从数据库结构、迁移数据两个维度进行验证,我们还需在数据迁移后的环境开展功能验证,通过全量的功能回归,发掘数据迁移后的缺陷。此外,为了保障系统上线后的稳定性,我们需要开展性能测试,这些我们将在以后再进行分享,希望上述内容能对开展数据库迁移测试的朋友提供帮助!
本文内容不用于商业目的,如涉及知识产权问题,请权利人联系我们将立即处理。