我正在为该迁移过程计划一种测试策略。为了确定此处最危险的领域，我阅读了一些从迁移测试和ETL工具测试中获得的一般经验，并将它们与我们的迁移过程规范进行了比较。
哪里出错了？
出于向后兼容的原因，新数据将由新应用程序通过适配器提供给旧模块。旧模块将使用迁移的数据来完成其工作。
新数据模型将支持一些新的应用程序功能。
新数据模型将不再支持某些旧的（通常不经常使用）应用程序功能。
旧模型中的可为空字段不再为可为空。
文件系统中的文件以不同的格式定义。
以前将在旧系统中解耦的数据现在将基于（
自动规则
管理员规则
将使用新的数据格式
可能出什么问题了？
新功能使用的数据值可能未正确设置为默认值。
适配器可能会将新数据错误地转换为旧格式。
并非所有实体都可以迁移，例如，在新系统中找不到某些旧客户端配置。
并非所有数据（属性）都可能被迁移。
新数据模型可能使用的数据格式可能无法存储某些旧数据结构（例如VARCHAR vs. BLOB）
旧模块可能无法读取已迁移的文件
等。
我的第一个想法是在此处结合两种测试策略：
低级测试策略将相对彻底，但覆盖面很少。这样做的想法是隔离最具代表性的原始数据样本（这对企业有意义，例如单个客户及其文档）。然后，对于每个映射规则，为样本数据的相应部分定义实际的预期输出。自动化检查。
高级测试策略虽然不够彻底，但却涵盖了大多数应用程序功能，并试图找出与旧模块的集成问题。这个想法是首先迁移所有数据。然后执行涉及新应用程序和旧模块的所有功能的用户测试方案。
您建议采取什么其他策略来发现已识别风险的错误？
#1 楼
我本人参与了一些数据迁移，所以我说您在正确的道路上有了一个很好的起点。在迁移之前创建预期行为的基准并在迁移后进行比较将很有用，但是正如您所提到的，有许多事情可能会发生变化，因此结果将不完全相同，并且需要一些人工工作要比较结果并确保它们符合期望。如前所述，您计划针对应用程序运行回归测试，以确保功能未被破坏。希望您已经拥有自动化测试或定义良好的手动测试套件来满足其中的大多数需求。
请确保您了解当前的极端情况，并且这些情况已包含在迁移中。开发人员可以轻松处理通常需要的所有数据，但是，在某些极端情况下，特定客户或特定配置的数据存储方式不同，因此您需要确保正确处理这些特殊情况。 （我发现了一个问题，该问题可能导致20万处于“特殊”状态的人（数百万人）在一次迁移过程中被锁定在其帐户之外）。
如果系统在迁移期间将处于联机状态，（我我正在考虑可能要花费数小时甚至数天甚至数周的迁移），请确保在初次通过之后，自迁移开始以来，用于获取所有数据的清理过程与原始过程一样健壮。开发人员在这部分上花费更少的时间很容易，但这同样重要。如果仅使用一小部分数据进行测试，也很难进行测试。
如果有可能，请在迁移之前以空运行方式对整个数据集进行完整迁移。即使您无法测试每条数据，这也将为开发人员提供大量信息，他们很可能会发现他们的某些迁移脚本在某些数据上出错，因此需要更仔细地分析以确保他们处理正确地。然后去进行回归测试。
Red-Gate提供了一组工具，使您可以在数据库之间进行数据比较。即使数据存储的方式不同，您也可以比较特定查询的结果，因此，如果您知道旧系统中的查询应等同于新系统中的查询，则可以用这种方式进行比较。
评论
@Sam_Woods，感谢您分享经验。通过清理过程，您是指将生产数据恢复到以前的状态？
– dzieciou
2012年2月19日在16:25
我的意思是，在非常大的数据迁移中，迁移通常是在系统仍处于启动状态且正在运行并收集新数据时进行的。通常，迁移过程会在后台进行初始运行，然后将开关切换到新数据存储，然后运行第二个过程，以迁移在初始迁移过程中插入到旧数据存储中的所有其他数据。如果您只是在迁移过程中关闭了服务，那么这将不适用。
–山姆·伍兹（Sam Woods）
2012年2月21日在22:03
#2 楼
迁移可能是一个麻烦的测试过程，有些测试人员可能会无所适从。很高兴看到您正在认真对待它。我可能会考虑配置设置如何影响迁移。如果您的产品具有可能影响迁移的按客户配置设置，则可以考虑如何测试适当的设置样本。您对“适当”的定义可能取决于诸如您的客户是谁，哪种设置最重要，最危险或最复杂等因素。该论坛中的其他问题讨论了组合测试的方法。
评论
您可以举例说明每个客户的设置吗？您是说迁移的数据库和文件系统可能无法覆盖生产系统中所有与客户端相关的数据吗？
– dzieciou
2012年2月19日在16:52
@dzieciou我添加了每个客户设置的示例。我的意思是，测试迁移结果的一种方法是考虑每个客户设置的变化如何影响数据的使用方式。这是测试的通用方法，而不是特定于迁移的方法。
–user246
2012-2-19在19:35
#3 楼
在此线程上有一些非常好的建议。我唯一可以添加的内容可能是有点偏离主题，但仍然是相关的：确保在迁移生产环境时保持新鲜。不久前，我参与了一个项目，该项目在凌晨四点进行了切换，测试人员全都工作了9-5天，然后在午夜现场进行了迁移。当我们进行健全性测试时，我们的专心完全被射中了，我们最终错过了一些令人讨厌的问题！评论
谢谢。您能在迁移的背景下评论健康测试吗？以前执行的测试的关键子集只是为了确保一切正常？
– dzieciou
2012-2-19在17:02
#4 楼
从这个问题以及所有答案中我都获得了很多信息。在问题中，标题为“哪里可能出问题了？”或“可能出了什么问题”，我认为从功能的角度来看，还应该考虑对系统性能的影响，因为您提到迁移涉及复杂数据模型以及文件系统的更改。
评论
我用最坏情况下的人工数据测试了目标系统的性能（就实体编号而言，这比现有生产情况要差）。为什么我必须再次验证已迁移数据的系统性能？
– dzieciou
2012-2-18在9:22
您不认为在迁移数据后，数据库的统计信息将发生变化，从而可能影响系统性能吗？即使在您的情况下，数据库的架构（非null，新的外键等）似乎也在发生变化，因此在迁移后从以前的系统到当前系统的性能基准标记是有意义的。
–rahul
2012年2月19日在9:09
也许我在这里不清楚。 1）我已经用新的数据模式安装了数据库（将数据迁移到的位置相同）。 2）我用定义的最坏情况下的人工数据负载填充了新模式。人工数据的大小比我将迁移的数据大。 3）我评估了这些人工数据的查询响应时间。您是否意味着迁移的数据将具有一些统计数据，这些统计数据是人工数据所没有的，但仍然会对性能产生负面影响？
– dzieciou
2012年2月19日在9:50
我想提供一个简单的例子来说明我的观点（虽然在您的情况下可能不正确）-假设在迁移数据之前，我们需要删除索引，并且一旦迁移了所有数据，就需要重新填充索引。我们以某种方式错过了重新填充索引的机会。在这里，性能问题可能是由于缺少索引（数据库统计信息）引起的，而不是因为新架构或新设计中存在一些问题。但是这些问题在数据迁移期间并不罕见。
–rahul
2012-2-19在11:16
#5 楼
在旧系统和新系统中，是否都有任何业务统计功能？如果为true，则可以在两个版本中进行相同的统计并进行比较。示例：客户数量应该相同，最好和最差客户的收入..
这些可以作为一种cheksum，可以确保不会丢失任何临界值。
#6 楼
测试迁移需要对当前和目标数据模型以及映射进行良好的分析。确保所有数据字段都已映射。您还需要检查数据字段是否已细分为多个字段，或者两个或多个字段已合并为一个。检查已消除的东西，因为可能不再需要。现在有一些ETL工具可以帮助您进行测试，但是当我很长时间进行类似项目时，我已经编写了自己的工具，该数据库连接到两个数据库提取的结构，并要求用户将数据从旧映射到新。它根据用户输入分析了两种结构，并显示了结果（错误情况）。
#7 楼
以上是一些很好的答案，我认为每个人都是正确的。您朝此方向走的越多越好。您是否研究过一些语义分析工具，例如Rever？ （www.rever.eu）。他们对一个类似的转换问题进行了案例研究，但是因为他们的工具分析了代码以及架构，所以他们可以显示转换逻辑的元数据结构，以获取代码的逻辑视图以供审查，然后再建议进行物理测试以上。除了基于代码和架构的源和目标的元数据视图外，众所周知，许多边缘情况仅在代码中可见，而在架构中不可见。评论
谢谢。您能指出我提到的案例研究吗？我发现的唯一页面的信息非常有限。此处没有链接的白皮书。
– dzieciou
2012-2-19在17:27
我们可能没有预算/时间尝试该工具，但我想了解它解决的问题。我们已经实现了迁移工具。什么边缘情况在其代码中而不在架构中可见？该工具在哪些情况下可以帮助我们在这里发现？
– dzieciou
2012年2月19日在17:31
评论
在生产中，将同时迁移所有客户，还是逐步迁移？全部在同一时间。原因是避免同时托管旧版本和新版本的产品。你为什么要问？
逐渐迁移的优点是您可以从错误中学习。当然，它需要同时托管（和维护）两个版本。这对您来说可能不切实际，并且在任何情况下都与您的问题有关。