第一次在项目中遇到数据迁移测试，从一头雾水开始做起，绕了不少弯路，趁着项目还没有结束，赶紧总结一下，适时调整思路。
一、没有需求文档=没有测试需求？
这次项目的数据迁移，SA是缺失的，但是测试需求还是可以跟开发人员沟通确认：
● 迁移的是哪几张表？
● 迁移表之间是否存在关联关系，如何关联？
● 迁移表中，那些字段的数据需要迁移，那些字段不需要迁移，不做迁移是否会隐藏风险？
● 迁移表的表结构在新老库中是否相同，包括：
是否存在新表的必填字段而旧表没有，应该用什么数据填写？
是否存在旧表数据在新表中没有对应字段存储，如何处理？
是否存在新旧表中字段类型、长度不一致，能否正确转换？
● 需迁移的数据共计多少条记录？
● 旧表中字段是否存储特定值？（迁移后需关注新旧表中存储数据是否一致）
二、从业务层面检查，保证迁移数据可用性
确认迁移需求之后，直接检查数据库表及其数据是发现数据迁移缺陷最快捷的一个方法，但是有一些缺陷还是不能单纯通过这种方式发现的，还是需要从业务层面去检查，而且对于迁移数据也需要保证其在业务流程上是可用的——即：迁移前，这些数据能支持完成什么功能，不支持什么功能，迁移后应该也是一致的。所以，除了检查数据库表及其数据，还需要挑选迁移数据，去回归这些相应的功能，其测试范围可以侧重以下几点：
1、该数据支持完成的功能
2、改数据不支持完成的功能
3、涉及到跨子系统的功能（需要关联系统维护相关数据，这是不能通过数据库检视来发现问题的，必须跑业务流程才能验证）
4、涉及到查询表数据，尤其是查询多表的功能（尤其是报表功能，还有一些查询回显信息的功能）
——暂时接触到和想到的就是这些，后续有补充再更新吧。
====================================分割线================================
最新内容请见作者的GitHub页：http://qaseven.github.io/