最近在测试公司的一个数据迁移项目，该数据迁移主要是实现将旧系统中的数据准确的迁移到新系统中，开始开发并未给具体的需求说明，按照以往的测试，我们按照黑盒测试的原理从界面上模拟构造各个模块的各种情况数据，查看迁移后数据的准确性。
　　界面构造数据测试点：
　　1) 构造界面字段最长值的数据，测试两边字段长度限制差异
　　2) 构造界面字段各种格式的数据，测试两边字段格式限制差异
　　3) 构造界面字段全填的数据，测试两边字段是否会丢失或者迁移错位
　　4) 构造界面字段默认值的数据，测试两边字段默认值是否一致
　　5) 构造界面重要下拉字段的所有情况，测试迁移后是否显示正确
　　6) 对旧系统有新系统没有的字段，验证是否迁移过去
　　7) 就旧系统没有，新系统有的字段，验证是否给予正确的默认值
　　8) 针对新旧系统字段的唯一值判断构造数据测试验证
　　9) 针对新旧系统字段的是否为空构造数据测试验证
　　10) 构造界面字段各种区间数据，测试新旧系统字段的范围限制
　　开始就是按照以上这些点从界面上构造数据，然后迁移后，到新系统中查看数据是否正确迁移，测过一段时间后，发觉数据显示都正常，无发现新问题。
　　后续我思考了下数据迁移仅靠这样的黑盒测试是否能发现大部分问题，后面我去大概了解下新旧系统数据库表结构，构造一些数据，然后查看表中字段的编号，发现有些界面上显示的是字符，而数据库表中存的是代码编号。觉得数据迁移若仅关注界面的数据测试有些问题是发现不了的，绝对应该还需要了解数据迁移的数据库表之间的迁移原理才能发现更多问题。以下则就是一个仅从界面上测试发现不了需要从数据库表结构入手才能发现的问题
　　例：
　　1、旧系统中是否为超级用户界面上有三个下拉选项如图1，【是、否、---】在数据库表中分别保存为【1、2、null】

图1 旧系统超级用户选项

　　2、新系统中是否为超级用户界面上有两个下拉选项如图2【是、否】在数据库表中分别保存为【1、0】

　　图2 新系统超级用户选项

　　构造数据过程在旧系统界面是否为超级用户为【否】，数据库表存的是编号是【2】。迁移后发现新系统界面中是否为超级用户同样显示为【否】，而数据库表存的是编号是【2】，但是新系统中该字段表中编号范围是【0，1】。界面上显示正确，是因为前端在读取是否为超级用户的时候，读取到【2】的时候不在范围内，会默认显示【否】。这样看来虽然界面上显示正确，但是实际上这个字段值是不正确的，后续若其他模块获取这个字段就会有问题。这个问题如果没有从数据库表结构测试的话是发现不了的。这也说明，在数据迁移测试过程中，单单的黑盒测试是不够的，同时还需要从数据库表结构入手测试（即所谓的灰盒测试）。
　　灰盒测试，是介于白盒测试与黑盒测试之间的一种测试，灰盒测试多用于集成测试阶段，不仅关注输出、输入的正确性，同时也关注程序内部的情况。灰盒测试不像 白盒那样详细、完整，但又比黑盒测试更关注程序的内部逻辑，常常是通过一些表征性的现象、事件、标志来判断内部的运行状态。对于数据迁移，则就还需要从数据库表结构变化出发，了解表之间迁移的原理。
　　数据库方向测试点：
　　1) 旧数据库中的表迁移到新数据库中表有什么变化
　　2) 哪些字段在旧数据库中不存在，而新数据库必须有，这些数据在新数据库中默认值
　　3) 哪些数据字段一部分有数据，一部分无数据，迁移到新库中无数据这部分如何处理
　　4) 数据库中表字段采用代码编号的，查看新旧数据库是否一致
　　对于数据迁移测试，个人觉得应该界面功能测试与数据库测试相结合。从界面上功能测试可以发现一些比较显而易见的问题，再根据了解的情况整理两边数据库的差异点进行重点测试。最后数据迁移测试还需要查看迁移后的数据在业务逻辑上是否正确，即使用从老系统中迁移过来的数据，在业务系统中进行流程测试，功能测试确保迁移后到数据可用