项目中遇到数据迁移测试，从一头雾水开始做起，绕了不少弯路，趁着还有印象，赶紧总结一下，适时调整思路。
1、技术层面检查
这次项目的数据迁移，SA是缺失的，但是测试需求还是可以跟开发人员沟通确认：
1）迁移的是哪几张表？
2）迁移表之间是否存在关联关系，如何关联？
3）迁移表中，哪些字段的数据需要迁移，哪些字段不需要迁移，不做迁移是否会隐藏风险，是否存在中间转换？
4）迁移表的表结构在新老库中是否相同，包括：
- 是否存在新表的必填字段而旧表没有，应该用什么数据填写？
- 是否存在旧表数据在新表中没有对应字段存储，如何处理？
- 是否存在新旧表中字段类型、长度不一致，能否正确转换？
- 需迁移的数据共计多少条记录？
- 旧表中字段是否存储特定值？（迁移后需关注新旧表中存储数据是否一致）
2、业务层面检查，保证迁移数据可用性、连续性
确认迁移数据之后，直接检查数据库表及其数据（核对总记录数，核对明细数据），是发现数据迁移缺陷最快捷的一个方法，但是有一些缺陷还是不能单纯通过这种方式发现的，还是需要从业务层面去检查，而且对于迁移后数据也需要保证其在业务流程上是可用的——即：迁移前，这些数据能支持完成什么功能，不支持什么功能，迁移后应该也是一致的。所以，除了检查数据库表及其数据，还需要挑选迁移数据，去回归这些相应的功能，其测试范围可以侧重以下几点：
- 该数据支持的功能；
- 该数据不支持的功能；
- 涉及到跨子系统的功能（需要关联系统维护相关数据，这是不能通过数据库检查来发现问题的，必须跑业务流程才能验证）；
- 涉及到查询表数据，尤其是查询多表的功能（尤其是报表功能，还有一些查询回显信息的功能）
- 或者通过相关工具，调用新老数据去执行交易，交易响应数据返回一致，则说明没有问题，若不一致，需人为查明原因；
3、小结
技术检查时，最好通过工具核对每一张表，每条记录的数据，先检查总记录数，再检查明细记录数，然后检查各个字段的值是否正确
业务检查时，通过移植后数据执行特定的交易，来验证移植数据的正确性，如果条件允许可以通过工具来调用移植前数据与移植后数据对原系统与新系统发起交易，比对返回值的一致性（比如选取销户）
本文源自公众号 测试届的LV