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