前几天都在忙着上驾校，测试时代论坛升级好几天都没法进去看资料，今天运气不错，论坛可以进去了，可以翻翻老贴，把一些自己认为比较有价值的整理整理然后收藏；看完测试时代的接着就要翻一翻51testing的了。

今天收录的关于历史数据迁移的测试，通常很少碰到；在我过去工作的5年多里，运气还不错，做过一次这方面的测试任务，在此记录记录。

历史数据迁移的测试

历史数据迁移，说白了就是数据库数据迁移，比如：把一个ACCESS数据迁移到ORACLE数据库，或者是其它数据库之间的数据迁移。

有的人可能会想，既然是数据库数据迁移，不需要做测试需求的确认了，检查一下数据就可以了；有的人由于没有做过这类测试、第一次碰到，傻眼了这可怎么测试啊，书籍上说的黑盒测试技巧里并没有历史数据迁移的测试方法，该怎么办。

我第一次接到这个测试任务时，感觉很特殊，因为实在少见，怎么做呢？

首先，在做历史数据迁移测试之前，也需要做测试需求的确认，主要是弄清楚用户为什么要做这个历史数据的迁移。

我记得，当时这个案例的用户是因为它的一个系统，之前的老系统是在ACCESS数据库中存储的，后来有了新系统、新系统的数据是在ORACLE里，为了把数据统一，就需要把老数据导入到新系统的数据库ORACLE里，便于新系统能查看到即可。

从这个需求，得出如下测试需求点：

1、 ACCESS数据库里有很多张表，要和用户确认要迁移的是那几张表？弄清楚老库中的老表对应要迁移到新库中的那几张新表？

2、 迁移的表中，那些数据字段需要迁移，那些数据字段不需要迁移？

3、 老表迁移到新表中，新表中有些必填字段在老表中没有的，用什么数据填写？

4、 老表迁移到新表中，老表数据在新表中没有对应字段存储，怎么处理？

5、 老库老表数据与新库新表重复，数据怎么处理？

6、 老表要迁移的数据记录条数是多少？

和用户弄清楚这些疑问点后，还需要和开发确认疑问点：

1、 老库中老表的表关系迁移到新系统新表中的表关系是怎样的？

2、 确认用开发编写的数据迁移程序迁移完后的数据检查方法？

确认上面的疑问点后就开始做工期时间计划安排、编写测试计划和测试用例。

    其次，要注意数据迁移后，新系统对老数据功能的使用。

记得当时在确定了测试需求点后，在编写测试用例时，我重点使用了一下新系统、确认新系统会用到老表数据的业务都有哪些？把这部分业务也作为测试用例点进行测试。也许有的人会想，只要后台把数据库表正确迁移完毕，前台应用程序应该是没有问题的，不需要检查的。这是一种偷懒怀着侥幸心理的想法。回到之前的用户需求，用户为什么要数据迁移，目的就是为了能在新系统使用这些数据，因此在数据迁移完毕后，还要重点的检查老数据在新系统中的使用。

就在这个数据迁移测试的过程中，我跟我们的部门经理说，用户肯定会有其它的需求、迁移这些数据肯定要做一些业务处理、新系统程序可能会有改动。结果在迁移数据做完后，用户真的提出了新的需求，被我说中了。^_^。为了让这些老数据在新系统能很好的完成新业务处理，要对老数据进行特殊标识后才进入新系统、同时新系统针对这部分数据相应要增加功能。这就是用户需求没有摸透、没有看清楚需求背后的真正需求，导致迁移程序需要再次进行修改。

有些人，在测试数据库迁移时，一开始想到的理论知识就是：测试数据的完整性、可靠性、有效性；有的人就会问，数据的完整性、可靠性、有效性的测试用例怎么写啊？说实话，我也没有写过数据的完整性、可靠性、有效性的测试用例，我只会根据用户给的需求、整理并发掘测试需求，根据需求形成测试用例。也许数据的完整迁移测试点就属于数据完整性测试用例吧；数据迁移完后新系统对迁移数据可正常使用并处理业务，就属于数据的可靠性、有效性测试用例吧。

不管怎样，在测试的过程中，一定要弄明白用户的真正需求，才不会走弯路，虽然只是个数据迁移，但不只是简单的数据迁移，背后有着很多不为人知的故事！！！！！^_^