第一次在项目中遇到数据迁移，从一头雾水开始做起，绕了不少弯路，趁着项目还没有结束，赶紧总结一下，适时调整思路。

　　一、没有需求文档=没有测试需求？

　　这次项目的数据迁移，SA是缺失的，但是测试需求还是可以跟开发人员沟通确认：

　　● 迁移的是哪几张表？

　　● 迁移表之间是否存在关联关系，如何关联？

　　● 迁移表中，那些字段的数据需要迁移，那些字段不需要迁移，不做迁移是否会隐藏风险？

　　● 迁移表的表结构在新老库中是否相同，包括：

　　　　是否存在新表的必填字段而旧表没有，应该用什么数据填写？

　　　　是否存在旧表数据在新表中没有对应字段存储，如何处理？

　　　　是否存在新旧表中字段类型、长度不一致，能否正确转换？

　　● 需迁移的数据共计多少条记录？

　　● 旧表中字段是否存储特定值？（迁移后需关注新旧表中存储数据是否一致）

　　二、从业务层面检查，保证迁移数据可用性

　　确认迁移需求之后，直接检查表及其数据是发现数据迁移缺陷最快捷的一个方法，但是有一些缺陷还是不能单纯通过这种方式发现的，还是需要从业务层面去检查，而且对于迁移数据也需要保证其在业务流程上是可用的——即：迁移前，这些数据能支持完成什么功能，不支持什么功能，迁移后应该也是一致的。所以，除了检查数据库表及其数据，还需要挑选迁移数据，去回归这些相应的功能，其测试范围可以侧重以下几点：

　　1、该数据支持完成的功能

　　2、改数据不支持完成的功能

　　3、涉及到跨子系统的功能（需要关联系统维护相关数据，这是不能通过数据库检视来发现问题的，必须跑业务流程才能验证）

　　4、涉及到查询表数据，尤其是查询多表的功能（尤其是报表功能，还有一些查询回显信息的功能）

　　——暂时接触到和想到的就是这些，后续有补充再更新吧。

====================================分割线================================

最新内容请见作者的GitHub页：http://qaseven.github.io/