【海量数据测试】大型项目中的海量数据迁移测试实践与方案

本文详细介绍了在大型项目中进行海量数据迁移测试的实践过程,包括数据准备、规则业务熟悉、迁移方案设计、测试驱动等方面。通过具体的案例分析,强调了数据迁移测试的重要性,如字符集问题、数据量评估、业务逻辑检查等,并提出了持续集成和性能评估的解决方案。此外,文中还指出了项目中存在的问题和改进方向。
摘要由CSDN通过智能技术生成
项目背景(某项目重构) 


      某应用很多联系人的信息重复情况,统一维护到欧若拉系统;并且进行根据相同的客户进行合并联系方式,排除很多客户冗余的情况。(个人理解)
数据分析与准备
线上异常数据处理,通常是在测试环境下面去验证数据迁移的逻辑和规则的正确性,那么必然我们需要对与线上的异常数据情况进行汇总和归类。比如线上数据存在电话号码存在小灵通(134432423424);一三五七八六二一;等特殊的异常数据情况进行分析
线上数据的字符集判断;保证真实模拟线上数据迁移的字符集情况,一般情况下数据迁移是在老系统迁移新系统过程中就会有不同的字符集情况。建议开发不要再同一个库中进行迁移数据
线上数据模拟的数量情况和脚本的性能问题,通常数据量是迁移的重要条件之一,一方面是需要技术经理和项目经理进行评估迁移数据量是否满足线上迁移的条件,另一方面能够模拟迁移脚本的性能问题。
数据表结构检查,新系统迁移老系统会存在表结构长度不一致的情况,这类问题会出现在反迁的情况(反迁脚本是当新系统迁移数据有更新的情况,则需要反迁脚本迁移回到新系统,保证新系统和老系统的数据一致性;数据迁移的两种情况:正迁(一次性迁移数据),反迁(实时同步数据迁移));通常反迁过程中会发现新系统的部分字段长度大于老系统的字段长度,就会引申部分数据截取的逻辑情况。
迁移的规则业务熟悉,对于QA来说,数据迁移不仅仅需要验证迁移的表关联和映射的关系,也需要通过测试脚本不断的通过不同的数据去验证迁移的业务规则,我这边举个联系人重构的迁移的例子:如当老表的姓名迁移到新表拆分为姓和名;(如果联系人姓名大于2个字符,判断最后两个汉字是不是长度为2的称呼,是的话,将这两位截取为称谓;如果联系人姓名等于2个汉字,判断是否最后1个汉字是否为长度为
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值