数据迁移测试-part2
文章转载于51testing
因旧系统代码过于繁重,代码更新代价大,界面不再适应大家当前的审美及操作习惯,项目会进行重新的开发,从而产生一个新模块或者新系统。
新系统产生,在进行测试的时候测试工作量较大。针对此工作,做如下总结。
1.确保新系统功能完善且已完成大部分的测试工作。
因新系统生成后,会产生信息的新的数据信息,同时需要兼容数据迁移过来的旧数据信息,如果新系统的功能存在大量的bug或者是功能不完善,
此时如果进行数据迁移,系统中产生的bug不容易区分是对旧数据产生的兼容性错误还是新系统本身的错误。
2.旧数据新页面
数据迁移后,需保证,旧数据在新的系统模块页面中的展示查看时不应有报错信息。此时应考虑将某单一数据进行取出后进行测试,保证页面不报错。
再一个比较重要的是,迁移过来的数据项内容对于在新页面的显示问题。常见的有以下几种:
1)原值显示,之前的值为多少,迁移后原值显示。
2)同一数据项内容,不同的值得显示,如状态:提交后,审批中、审批完成等,需判断旧数据不同场景或者不同值在迁移以后再新biz页面的显示。
3)空值判定,对于空值,在制定迁移方案或者需求中应进行说明,空值迁移以后是以空值正常显示,还是以某个固定值为替补,确认后进行测试。
4)关联数据,新系统的某个值是经过旧数据中多个字段产生,或者多个值运算产生,此时应分情况进行综合考虑。
5)字段处理,如某些旧系统中的整数,要求在新系统中为小数点后两位的显示,或者日期只有年月日不要时分秒等的规则,进行字段处理的情况。
6)是否符合新系统中的校验规则,新系统是否对某个字段新增了校验规则,如果有,此种情况需进行兼容新系统的校验规则,此是需跟需求进行确认
该种场景应如何处理。
7)接口测试,因系统中调用了某些不迁移的数据模块的接口,所以需进行查看新系统页面中对于未迁移的数据的支持及调用情况。
8)附件迁移,附件是一个特殊的模块,查看迁移方案是调整附件的重新指向,还是讲附件名称重新定义为符合新biz规则的情况,针对不同情形,进行
相关测试。
3.旧数据新table
迁移方案制定的时候,一般会进行筛选数据,或者全部迁移。
如果进行了筛选数据,再执行迁移(针对某个单一模块更新),那么在进行测试的时候,需进行查看不符合筛选条件的数据是否也被迁移,在源头
上进行把控;是否存在即符合迁移条件同时 又不符合迁移条件的异常数据;筛选后的数据数量是否迁移成功的数据保持一致,如果有失败数据需从日志
中进行筛选过滤,查看迁移失败原因。
如果没有筛选数据,直接进行整体迁移(整个模块或者项目迁移),在进行测试的时候还是同样,第一,需保证旧数据的数量与新的数据数量是一致的。
第二,如果不一致,需进行查看迁移失败的数据,失败原因。
数据迁移中被舍弃的数据:因迁移,有些字段对于新系统将不再适用,所以,会有一个舍弃,此时应考虑舍弃的数据是否会影响到迁移数据的情况,不过
此种情况一般是不会有问题的,因需求和开发进行舍弃这些此段时也会进行排查。不过测试人员还是需进行相关排查。
新系统中新增的字段:新兼容系统,新系统会产生相应的新的字段,此时应考虑旧数据中对新字段的对应及其相关的关联关系。如果没有对应关系的新字段,
是否会影响新系统中的业务场景。
注意点:1,迁移失败数据的过滤,数据迁移时肯定因不同情形会产生迁移失败的情况,应要求开发记录迁移失败数据,以便后续跟踪过滤。
2,单证序列号的测试,新系统使用时是否是根据旧数据的序列号后以此产生。如果还是根据业务规则重新计数,是否会产生同一序列情况。
4.旧数据新业务逻辑
1),页面查看,旧数据迁移成功后,如果是仅查看的内容,即验证数值系那是正确,可以兼容所有数据即可。
2),新系统后续页面逻辑,旧数据迁移后,有可能是仅支持查看即可,有时仍需在系统中进行其他业务逻辑,如果购物系统,在加入购物车的物品,在新系统中不仅
要支持可以查看到该购物车的这次数据,还应可以继续在新系统中进行提交订单等操作,此时应根据不同情形分类场景,将不同场景的旧数据情况考虑在
内,然后分别在新系统中进行验证。
3),迁移到系统中,与旧系统的业务接口对接,因有些系统属于某个模块单独迁移,其余模块暂不迁移,所以此时应考虑,迁移后的数据是否可直接与此处进行直接
业务对接。
总得来说,数据迁移就是要保证新系统能用的情况下,兼容旧数据,且旧数据不影响新系统的使用,且旧数据也能够兼容新系统的业务逻辑。
![](https://img2018.cnblogs.com/blog/1473846/201903/1473846-20190328233814074-2027599016.png)