数据迁移的测试：伪迁移

       在数据迁移开发过程中，你的团队可能会在测试环境中运行许多小型的迁移，以此来优化迁移过程并发现问题。但是，你至少应该执行一次包含全部数据集的迁移，这很重要。这种“伪迁移”是对迁移过程的一次测试，是对迁移的性能和时间安排的一种评估，也是最终的数据迁移的一次演练。

       伪迁移的一些重要元素如下所示。

       应该使用全部的数据集和用于运行生产迁移的相同硬件来进行此项迁移。这样做的一部分目的是得到一个合理的数据迁移时间安排；大型数据集的迁移过程可能会花费数小时甚至数日。

       项目团队的各种人员应该参与测试并验证迁移结果。熟悉源应用程序和数据的用户是发现问题的最佳人选。

       伪数据迁移过程应该先编好全部的脚本，而且每个进行的操作都要有时间截日志。伪迁移和实际的数据迁移之间的时间间隔可能是几周或几个月；你无法记住伪迁移过程中的每个步骤，除非它成为用于生产迁移的脚步的一部分。

       验证数据迁移过程有几种常见方法。

       查看数据迁移工具的错误日志：这是一个很好的起点；大多数工具都会记录下失败的操作，从而突出显示数据迁移过程中的问题。

       查询测试：这种类型的测试包含针对源应用程序和CRM程序的运行查询，从而发现迁移中的问题。例如，如果源应用程序包含50000个账号记录，CRM中是否也创建了50000个账号？如果没有，哪些记录没有被创建，为什么？查询还可以用于测试迁移逻辑中的特定部分。例如，查询可以提供源应用程序和CRM应用程序中按销售阶段划分的销售机会的记录，因此你可以验证映射逻辑是否正确应用。

       点测试：这包括确定源应用程序中的一些记录，并逐一字段地将其与CRM对照，从而确认所有数据都倍正确地转换，以及源应用程序中的各个记录之间的关系在CRM中都被如实地重新创建。这是三种测试测试中唯一能够在项目团队成员中分散进行的测试。

       当让项目团队参与测试时，需要提醒大家描述问题时要具体。理想情况下，你应该指出哪些具体的记录和字段没有被正确地迁移。像“CRM中的数据看起来有些问题”这样笼统的评价是毫无帮助的。

       当伪项目团队的测试结束后，你需要决定是否继续推行数据迁移过程。如果测试中发现的问题很少，且很容易纠正并开展重新测试，你就可以进行下一步了。如果迁移测试发现了重大的问题，你可能需要调整项目计划，在问题解决之后再进行第二次伪迁移。