项目已经进入数据割接测试一轮尾声，记得刚刚进入数据割接测试的阶段，大家都很茫然，让我们想起了当时数据准备阶段，这一幕又重现了，数据准备是因为数据及其复杂，业务复杂，大家对其他人负责的业务不熟悉，导致数据准备成为一块绊脚石，然而开发人员都很忙，没有时间一起配合准备。而数据割接测试也同样面临着类似问题，一方面业务及其复杂，新老系统的设计逻辑和数据结构有很大的差异。而我们大部分人对老系统不熟悉，参与割接的开发人员对新系统不熟悉，导致割接测试困难重重。

刚开始我们采用的是把老系统线上的数据割接到新系统，然后我们选择几种典型业务按一定条件准备了一些用户，在新老系统中对比这些用户的数据。发现这这些用户的记录不熟悉，用户的数据又比较乱，不是登录不了，是密码不对，要不是没有用户信息，要不是不能发布宝贝，还要去修改相应的用户信息等等，这样准备数据都快过去了进度很慢。后来大家提出用自己平时用的用户计划好场景，到日常中去构造一些数据，造好后再把这些用户给割接的人，让他们把相应的用户数据增量割接过来。然后再用这些用户在新系统中做交易，看数据是否正确。另外备用一两个用户，在新系统中做同样的数据，进行比较。有些没办法构造的场景才选用哪些已有的用户数据去查看。即自己构造的数据和上线上的数据互相弥补

这样做有几点好处：

首先自己构造的数据自己清楚，不用再去找这些用户数据。

其次自己平时用的用户，用户信息都是全的，能登录，能发宝贝，能做交易，能订购，不用再去修修补补，那怕是要修改，修改的地方也少点。

虽然这样一来有点进展，但是还是遇到了很多的问题，有些数据割接过来有很多错误，因为新老系统的数据结构很大的差异的问题，很多逻辑不对。而项目中的开发人员忙于项目，忽略数据割接测试的重要性，后来我们建议新老系统开发人员和测试人员一起配合数据割接测试，保证数据字段的正确性。

针对以上出现的问题，个人觉得首先要保证迁移脚本的正确性，那好是新老系统的开发人员配合编写脚本。万一项目中开发人员没时间，审核的时候要新老系统的开发人员要一起慎重审核脚本的逻辑。否则不能保证脚本的正确性，那更谈不上保证数据的正确性。