51Testing软件测试论坛

标题: 银行数据库迁移功能测试经验总结 [打印本页]

作者: lsekfe 时间: 2021-3-3 10:55
标题: 银行数据库迁移功能测试经验总结
近年来，随着互联网行业的快速发展，银行系统更新迭代愈发频繁，Oracle数据库因具备高安全性、高性能、完全向下兼容等优势，目前已成为银行系统主流的数据库软件。笔者参与了Sybase数据库向Oracle数据库迁移的测试工作，在数据库迁移的测试过程中，笔者发现传统的功能测试方法已难以适应数据库迁移测试的测试需求，例如存在需求书、设计说明文档等测试依据不足的问题，再加上数据库迁移影响的数据表和客户范围异常庞大，加上原有“测试”的积累和复用非常有限，导致测试人员在有限的项目测试周期内很难做到充分测试。笔者认为提升测试质量的关键在于测试设计，而数据库迁移功能测试需有一套针对性强的测试设计方法，才能有效提高测试效率、提升测试质量。
　　笔者结合自身参与的本次Sybase数据库向Oracle数据库迁移功能测试实践经验，首选总结了Sybase数据库和Oracle数据库之间与功能测试密切相关的差异，然后针对数据库之间的各类差异，在原有功能测试方法基础上，整理了一套有针对性的数据库迁移功能测试的经验和方法，最后对于数据库迁移功能测试方法进行了总结和展望。
　　一、Sybase和Oracle主要区别
　　（一）SQL语法不一致
　　1、字符串处理函数不同：例如Sybase为substring（），oracle为substr（）；取系统时间Oracle为sysdate,Sybase为getdate()。
　　2、多表联结语法不一样。
　　（二）字段超长后处理机制不同
　　超过数据库定义字段长度的输入，Sybase处理机制为自动截断，输入超长字符时交易成功；Oracle在输入超长字符时因无自动截断机制，则交易报错无法成功。这种不同的超长字符输入处理机制导致大量历史异常数据在Sybase成功，在Oracle交易失败。超长字段输入来源包括：(1)主机向系统数据库的输入数据；(2)系统自身页面前端未控制字符长度，输入超长的数据；(3)系统自身程序有超长函数名称，存入日志表报错；(4)关联系统输入超长字段。该差异引发的问题是本次迁移涉及范围最广的问题，涉及改造交易上百个。后针对字段超长的问题，项目讨论后决定重新梳理交易相关字段，补充测试用例，进行专项测试，针对重要外部系统输入的字段逐项对比排查。
　　（三）中文字段字节长度不一致
　　Sybase数据库1个中文占2个字节；Oracle数据库1个中文占3个字节，如部分输入字段在数据库迁移前后未对中文字段长度进行扩充，则会出现实际业务不一致的情况。例如：在系统的某个录入页面，第一版测试时，开发未对自定义备注（可输入中文）进行字段长度的扩充，导致自定义备注在数据库迁移前后内容由于超长被覆盖而导致不一致。需重点梳理业务字段及支持输入类型（是否含中文）。
　　（四）字符类型转换
　　Sybase和Oracle对于不同字符类别的处理机制不同；以char字符类型处理机制为例，Sybase中历史数据中有长度为1的数据‘6’，迁移到oracle后，取值时为会自动补空格变为‘6 ’，导致程序逻辑出错。刚开始开发人员在程序中通过trim过滤空格，后统一将char类型修改为varchar类型。
　　（五）空值读取结果不一致
　　Sybase和Oracle对于空值的处理机制不同，例如：对于0长度的空值‘ ’，Sybase存储为长度为1的空格：‘ ’，后续查询该字段报文时，该字段为长度为1的空格；Oracle则存储为null，后续查询该字段拼报文时，该字段取出为NULL,会少1个字段。
　　（六）查询语句输出默认排序不一致
　　例如：明细类交易，两个数据库输出顺序不一致；同时待处理任务输出顺序也不一致。
　　（七）日期格式不一致
　　Sybase与Oracle日期处理格式不一致。例如：Oracle datetime格式为to_date(‘2020-05-10 12:00:00','yyyy-mm-dd HH24:mi:ss')，Sybase datetime格式为 ‘05/10/2020 12:00:00 AM'。
　　二、Sybase向Oracle数据库迁移测试方法
　　笔者基于Sybase和Oracle数据库在功能测试相关差异，结合项目测试过程和发现的缺陷，总结了如下数据库迁移测试经验和方法。
　　（一）多场景测试
　　笔者参与的基础数据库迁移项目，数据表多、数据量大，影响的客户范围广。需要首先对客户和交易进行分类，其中客户分为存量客户（Sybase）、新增客户（Oracle），交易分为存量交易（Sybase）、新增交易（Oracle）、在途交易（交易流程在数据迁移到Oracle前未在Sybase执行完毕）。针对如上不同客户和交易类型进行交叉组合，确定了如下几类交易场景。
　　存量客户（Sybase）的存量交易（Sybase）成功
　　存量客户（Sybase）的在途交易在Oracle执行成功
　　新增客户（Oracle）的新增交易（Oracle）成功
　　注：数据库迁移项目中一般都会设置应急回退机制（Oracle向Sybase),因为也需对存量交易场景进行充分测试。
　　（二）超长字段测试
　　上文提到Sybase和Oracle对于超长字符的处理机制不同，Sybase为自动截断，Oracle无法自动截断，测试充分性的关键在于全面梳理所有场景的输入项和各输入项的字段长度，笔者结合项目测试发现的典型问题，对输入场景、输入项类别、字段长度检查方法做了如下总结：
　　1、输入场景
　外部系统向被测系统数据库输入的数据
　　典型问题：外部系统维护的备注信息输入超过20个汉字时，系统（Oracle数据库）做金融性交易时报错。
　　系统自身页面输入超长数据
　　典型问题：金融性交易（Oracle）复核拒绝时在“拒绝原因”字段录入超长字符，然后进行发送交易时报错。
　　关联系统输入
　　典型问题：交易在各关联系统之间流转时，如输入项录入超长字符时可能引发报错。
　　2、输入项类别
　　显性输入：客户录入界面输入框（关注字段长度）
　　隐性输入：客户无法看到的输入到系统数据库中的信息（不要遗漏该输入的字段长度）
　　例如在登录界面，显性输入为客户号和操作员号，隐性输入为操作员姓名、手机号等，隐性输入为测试人员最易遗漏的输入项，该部分的字段输入长度应加以关注。
　　3、字段长度检查
　　数据库结构表中进行查询
　　在系统输入界面（Sybase）运用边界值测试方法测试字段最大长度
　　（三）中文输入边界值测试
　　前文提到中文字符在两个数据库占用的字节长度不一样，Oracle为3个字节，Sybase为2个字节，开发需对中文输入的字段长度进行扩充。测试人员需要准确完整的梳理出所有涉及中文输入的内容，如账户名、客户姓名等；同时需测试非中文输入的字段是否对中文做了限制性输入，例如手机号等。考虑到安全方面的风险，可适当加入防SQL注入等安全测试方面案例。总结如下：
　　中文输入框最大长度边界值测试
　　非中文输入框-中文限制性输入测试
　　防SQL注入测试：如输入“and 1=1”等
　　（四）空值NULL测试
　　因Sybase对空值的处理为长度为1的空格，而Oracle为NULL，在拼接报文时会出现因缺少字段而报错。测试人员应根据需求说明书逐一对各输入框的必输性进行测试，对于非必输项需测试其为空值的场景。笔者在测试过程中发现非必输项如输入空值，则迁移到Oracle数据库后会报错误，后项目组采取了对所有输入为空值的字段，均用统一默认值替代，解决了因识别空值为NULL而引发报文中字段缺失进而导致交易报错的问题。
　　（五）查询类交易输出顺序测试
　　Oracle和Sybase对于查询类交易的输出顺序不同，测试人员需对Oracle数据库输出顺序（明细类交易）与业务人员进行讨论，看是否对客户需求造成了影响。同时，查询类交易也需测试翻页场景，对于翻页后反显的信息是否显示正确。
　　（六）日期输入格式测试
　　测试过程中会有涉及日期和时间输入的测试场景，如预约日期等，需测试输入各类日期和时间格式后交易是否成功、交易后输出的日期和时间是否显示正确。如：2001年3月7日、2001/3/7、01/3/7、03/07/01、16:22:30、4:22:30 PM、4:22 PM、16时22分等。
　　三、Sybase向Oracle数据库迁移测试经验小结
　　笔者参与的项目测试投产时间正值节假日前后，交易量正值高峰期，且本次数据库迁移测试时间十分紧迫，在基于上文的数据库迁移测试方法基础上，笔者针对测试准备和执行阶段的经验进行了总结，如下经验有助于进一步提升迁移测试质量和测试效率。
　　（一）对于缺陷进行分类处理，测试初期SQL语法错误引发的缺陷最为典型且数量最多，严重影响了测试执行进度。在集中收集缺陷数据后，笔者与开发沟通，明确建议开发先对SQL语句进行全面的代码复查，由开发人员手工执行一遍SQL语句，确保没有低级语法错误，在施行了该措施后，测试执行进度有了明显的提升，缺陷数量也明显呈下降趋势。
　　（二）在测试准备阶段，要提前申请生产数据脱敏。如果具备条件，最好在脱敏数据中测试。因为生产上存在大量历史异常数据，会严重影响测试数据的准备。
　　（三）对于功能测试人员来说，还不具备从数据库字段去分析异常值的能力和条件，因此对于关键系统、关键字段还需要开发去梳理和分析。例如笔者在测试过程中发现外部系统传到被测系统数据库的部分字段有非法汉字，导致交易报错。该字段在数据库迁移时，开发已发现但未处理。在笔者建议下，项目组对所有异常字段进行了充分分析，并进一步扩展到对所有从相关系统获取的字段进行分析，确保了交易的数据处理正常。
　　（四）对于在途状态的交易迁移对比测试，例如在Sybase发起，迁移后在Oracle复核发送。该类测试的经验就是安排多轮测试、循序渐进。同时受测试环境、人员经验限制，项目在开始迁移对比测试不顺利，大量测试用例不具备条件，执行进度受阻，导致了测试计划多次调整。针对该问题，笔者建议对于数据库迁移测试，应严格按照冒烟用例、基本流程用例、全量用例循序渐进作测试计划，这样测试效率更高。
　　四、总结和展望
　　本文总结的Sybase数据库向Oracle数据库迁移测试方法和经验旨在通过规范的测试设计，针对数据库迁移功能测试的特殊性，进一步扩充功能测试用例，提升测试效率和测试全面性。
　　同时该方法具有一定的延展性，在其他类型的数据库迁移项目中，仍可以通过分析数据库之间的差异，参考本文总结的测试方法和经验，建立起一套规范化体系化的数据库迁移测试方案。

欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)