数据迁移测试概述：
经常听说应用程序已移至其他服务器，技术已更改，已更新至下一个版本或移至其他数据库服务器等，
这到底是什么意思？
在这种情况下，对测试团队会有什么期望？
从测试的角度来看，这一切都意味着应用程序必须进行彻底的端到端测试，并成功地从现有系统迁移到新系统。
在这种情况下，必须对所有数据进行系统测试，这些数据在旧应用程序中也要在新数据中使用。现有功能需要与新功能/修改功能一起进行验证。
迁移测试，也可以称为数据迁移测试，其中用户的全部数据都将迁移到新系统。
因此，迁移测试包括使用旧数据，新数据或两者的组合，旧功能（不变的功能）和新功能进行测试。
旧应用程序通常被称为“旧版”应用程序。与新的/升级的应用程序一起，还必须对旧应用程序进行测试，直到新的/升级的应用程序变得稳定和一致为止。对新应用程序的广泛迁移测试将揭示在旧应用程序中未发现的新问题。
什么是迁移测试？
迁移测试是一种将旧系统迁移到新系统的验证过程，以最小的中断/停机时间，实现数据完整性和无数据丢失，同时确保在应用程序运行后满足应用程序的所有指定功能和非功能方面的要求。
迁移系统的简单表示：
为什么要进行迁移测试？
众所周知，应用程序迁移到新系统的原因可能多种多样，包括系统整合，技术过时，优化或任何其他原因。
因此，虽然需要将使用中的系统迁移到新系统，但必须确保以下几点：
需要避免/尽量减小由于迁移而给用户造成的任何类型的干扰或不便，例如：停机，数据丢失。
尽量不给用户带来损害或仅很小的损害，确保用户是否可以继续使用软件的所有功能。例如：功能的改变，某个特定功能的删除。
预测并排除在真实系统实际迁移期间可能发生的所有可能的故障/障碍也很重要。
因此，为了通过消除这些缺陷来保证实时系统的顺利迁移，在实验室进行迁移测试是非常必要的。
从技术上讲，还需要出于以下目的执行它：
确保新的/升级的应用程序与旧版应用程序支持的所有可能的硬件和软件兼容。此外，还应该针对新的硬件、软件平台测试新的兼容性。
为了确保所有现有功能都可以在旧版应用程序中正常工作。与旧应用程序相比，新应用程序的工作方式不应发生任何变化。
由于迁移而产生大量缺陷的可能性非常高。许多缺陷通常与数据有关，因此需要在测试过程中识别并修复这些缺陷。
确保新的/升级应用程序的系统响应时间等于或小于对旧应用程序的响应时间。
确保服务器、硬件、软件等之间的连接完好无损，并且在测试过程中不会中断。在任何情况下，不同组件之间的数据流都不应中断。
什么时候需要进行此测试？
在迁移之前和之后都必须执行测试。
在测试实验室进行的迁移测试的不同阶段可以分类如下。
1.迁移前测试
2.迁移测试
3.迁移后测试
除上述内容外，以下测试也将作为整个迁移活动的一部分执行。
向后兼容性验证
回滚测试
在执行此测试之前，任何测试人员都必须清楚地了解以下几点：
作为新系统的一部分发生的更改（服务器、前端、数据库、模式、数据流、功能等）。
了解团队制定的实际迁移策略。迁移的发生方式，逐步发生在系统后端的更改以及负责这些更改的脚本。
因此，有必要对新旧系统进行深入研究，然后相应地规划和设计测试用例和测试场景，作为上述测试阶段的一部分，并制定测试策略。
数据迁移测试策略
设计用于迁移的测试策略包括要执行的一组活动和要考虑的几个方面。这是为了最大限度地减少由于迁移而产生的错误和风险，并有效地执行迁移测试。
此测试中的活动：
1、专业团队组成
与具有所需知识和经验的成员一起组成测试团队，并提供与要迁移的系统有关的培训。
2、业务风险分析、可能错误分析
当前业务不应在迁移后受到阻碍，因此应召开“业务风险分析”会议，包括适当的利益相关者（测试经理、业务分析师、架构师、产品所有者、业务所有者等），并确定风险和可实施的缓解措施。测试应包括发现这些风险的场景，并验证是否实施了适当的缓解措施。
使用适当的“错误猜测方法”进行“可能的错误分析”，然后围绕这些错误设计测试，以便在测试过程中发现错误。
3、迁移范围分析和识别
分析迁移测试的明确范围，何时以及需要测试什么。
4、确定适当的迁移工具
在定义自动或手动测试策略时，请确定将要使用的工具。例如：用于比较源数据和目标数据的自动化工具。
5、确定适当的迁移测试环境
为迁移前和迁移后的环境确定单独的环境，以执行测试所需的任何验证。了解并记录旧版和新版迁移系统的技术方面，以确保按此配置测试环境。
6、迁移测试规范文档并进行审查
准备迁移测试规范文档，其中清楚地描述了测试要求，测试范围，测试技术（自动、手动），测试方法（黑盒，白盒），测试周期数，测试时间表，创建数据并使用实时数据（需要掩盖敏感信息）的方法，测试环境规范，测试人员资格等，并与涉众进行评审。
7、迁移系统的生产启动
分析并记录要进行生产迁移的待办事项清单，并提前将其发布。
迁移的不同阶段测试
阶段1：迁移前测试
在迁移数据之前，作为迁移前测试阶段的一部分，将执行一组测试活动。在较简单的应用程序中，忽略或不考虑这一点。但是，当要迁移复杂的应用程序时，必须进行预迁移活动。
以下是在此阶段采取的行动清单：
设置一个明确的数据范围：必须包含哪些数据，必须排除哪些数据，需要转换的数据等。
在旧应用程序与新应用程序之间执行数据映射：对于旧应用程序中的每种数据类型，将其在新应用程序中的相关类型进行比较，然后进行映射。
如果新应用程序中具有必填字段，而在旧应用程序中不是这样，则请确保旧应用程序不将该字段设置为null。
仔细研究新应用程序的数据模式，包括字段名称、类型、最小值和最大值、长度、必填字段，字段级别验证等。
旧系统中的许多表将被记录下来，如果迁移后删除和添加了表，则需要验证。
在旧应用程序中，应注意每个表、视图中的多个记录。
研究新应用程序中的接口及其连接。接口中流动的数据应高度安全，并且不会损坏。
为新应用程序中的新条件准备测试用例、测试场景和用例。
使用一组用户执行一组测试用例、场景，并保存结果和日志。在迁移之后，同样需要进行验证，以确保遗留数据和功能完好无损。
数据和记录的计数应清楚记录下来，迁移后需要进行验证，以确保没有数据丢失。
阶段2：迁移测试
进行迁移活动时，必须严格遵循迁移团队准备的“迁移指南”。理想情况下，迁移活动从将数据备份到硬盘上开始，以便可以在任何时间恢复旧系统。
验证“迁移指南”的文档部分也是数据迁移测试的一部分。验证文档是否清晰且易懂。所有脚本和步骤必须正确记录，没有任何歧义和任何类型的文档错误，按照步骤执行顺序进行的不匹配项也需要被视为重要的，以便可以进行报告和解决。
需要从版本控制存储库中获取与实际迁移相关的迁移脚本，指南和其他信息以供执行。
记录从迁移开始到系统成功恢复的实际迁移时间，是要执行的测试用例之一，因此“迁移系统所用的时间”需要记录在最终测试报告中，该报告将作为迁移测试结果的一部分提交，并且该信息将在产品发布期间有用。对测试环境中记录的停机时间进行外推，以计算现场系统中的近似停机时间。
它将在旧系统上执行迁移活动。
在此测试过程中，通常会关闭环境中的所有组件并将其从网络中删除，以执行迁移活动。因此，有必要注意迁移测试所需的“停机时间”。理想情况下，它将与迁移时间相同。
通常，“迁移指南”文档中定义的迁移活动包括：
实际迁移应用程序；
防火墙、端口、主机、硬件、软件配置均根据要迁移旧版的新系统进行修改；
执行数据泄漏、安全检查；
检查应用程序所有组件之间的连接；
建议测试人员在系统后端或通过白盒测试来验证以上内容。
指南中指定的迁移活动完成后，将启动所有服务器，并进行与成功迁移验证有关的基本测试，以确保所有端到端系统均已正确连接，并且所有组件都在相互通信，DB已启动并运行，前端与后端通信成功。这些测试需要更早地确定，并记录在迁移测试规范文档中。
该软件有可能支持多个不同的平台。在这种情况下，需要分别在每个平台上验证迁移。
迁移脚本验证将是迁移测试的一部分。有时，在独立的测试环境中，也可以使用“白盒测试”来验证各个迁移脚本。
因此，迁移测试应是“白盒测试”和“黑盒测试”的结合。
一旦完成了与迁移相关的验证并通过了相应的测试，团队就可以进一步进行迁移后测试。
阶段3：迁移后测试
成功迁移应用程序后，便开始了迁移后测试。
这里，端到端系统测试是在测试环境中执行的。测试人员使用旧数据以及一组新的数据来执行确定的测试用例、测试场景和用例。
除此之外，还需要在迁移的环境中验证以下特定项目：
所有这些都记录为测试用例，并包含在“测试规范”文档中。
检查是否在计划的停机时间内将旧版中的所有数据迁移到新应用程序。为确保这一点，请比较数据库中每个表和视图的旧应用程序与新应用程序之间的记录数。另外，报告迁移所需的时间，例如迁移10000条记录的。
检查是否按照新系统更新了所有架构更改（添加或删除的字段和表）。
从旧版迁移到新应用程序的数据应保留其值和格式，除非未指定这样做。为了确保这一点，请在旧应用程序数据库和新应用程序数据库之间比较数据值。
针对新应用程序测试迁移的数据。这里介绍了最大可能的情况。要确保100％的数据迁移验证覆盖率，请使用自动测试工具。
检查数据库安全性。
检查所有可能的样本记录的数据完整性。
检查并确保旧系统中较早支持的功能可以在新系统中按预期工作。
检查涵盖大多数组件的应用程序中的数据流。
组件之间的接口应该进行广泛的测试，因为数据在通过组件时不应被修改、丢失和损坏。集成测试用例可以用来验证这一点。
检查旧数据的冗余。迁移期间，任何旧数据都不应该重复复制。
检查数据不匹配的情况，例如数据类型已更改，存储格式已更改等。
旧应用程序中的所有字段级别检查也应包含在新应用程序中。
新应用程序中的任何数据添加都不应反映在旧版本上。
应该支持通过新应用程序更新旧应用程序的数据。在新的应用程序中更新后，它不应反映在旧版本上。
应该支持在新应用程序中删除旧应用程序的数据。一旦在新应用程序中删除，它也不应删除旧数据。
验证对旧系统所做的更改是否支持作为新系统一部分。
验证旧系统的用户是否可以继续使用旧功能和新功能，尤其是涉及更改的功能。执行迁移前测试期间存储的测试用例和测试结果。
在系统上创建新用户并进行测试，以确保旧版以及新应用程序的功能均支持新创建的用户，并且可以正常工作。
使用各种数据样本（不同年龄段，来自不同地区的用户等）执行与功能相关的测试。
还需要验证是否为新功能启用了“功能标志”，并且将其打开/关闭可以启用或关闭该功能。
性能测试对于确保迁移到新系统/软件不会降低系统性能非常重要。
还需要执行负载和压力测试以确保系统稳定性。
验证软件升级没有打开任何安全漏洞，并因此进行安全测试，尤其是在迁移期间对系统进行了更改的区域。
可用性是需要验证的另一个方面，其中如果GUI布局/前端系统已经改变或者任何功能已经改变，那么与旧系统相比，最终用户感受到的易用性是什么。
由于迁移后测试的范围变得非常庞大，因此最好将需要首先进行的重要测试分离出来，以确定迁移是否成功，然后再执行其余的测试。
还建议将端到端功能测试用例和其他可能的测试用例自动化，以减少测试时间并快速获得结果。
测试人员编写一些用于迁移后执行的测试用例的建议：
迁移应用程序时，并不意味着必须为整个新应用程序编写测试用例。已经为旧版设计的测试用例对于新应用程序仍应该适用。因此，尽可能使用旧的测试用例，并在需要时将旧的测试用例转换为新应用程序的用例。
如果新应用程序中有任何功能更改，则应修改与该功能相关的测试用例。
如果在新应用程序中添加了任何新功能，则应针对该特定功能设计新的测试用例。
当新应用程序中的任何功能删减时，不应考虑相关旧应用程序的测试用例进行迁移后执行，并且应将它们标记为无效并分离。
设计的测试用例在使用方面应始终可靠且一致。关键数据的验证应包含在测试用例中，以便在执行过程中不会遗漏。
当新应用程序的设计与旧版（UI）的设计不同时，应修改与UI相关的测试用例以适应新设计。在这种情况下，测试人员可以根据发生的更改量来决定是更新还是重写。
向后兼容性测试
系统的迁移还要求测试人员验证“向后兼容性”，其中引入的新系统与旧系统（至少两个以前的版本）兼容，并确保与这些版本完美配合。
向后兼容性是为了确保：
新系统是否支持前两个版本以及新版本中支持的功能。
该系统可以成功地从前两个版本迁移而来，没有任何麻烦。
因此，必须通过具体执行与支持向后兼容性相关的测试来确保系统的向后兼容性。需要设计与向后兼容性相关的测试，并将其包含在“测试规范”文档中以供执行。
回滚测试
如果在执行迁移时出现任何问题，或者在迁移过程中的任何时间出现迁移失败，那么系统应该有可能回滚到旧系统并快速恢复其功能，而不会影响用户和先前支持的功能。
因此，为了验证这一点，需要将迁移故障测试方案设计为异常测试的一部分，并且需要测试回滚机制。恢复到旧系统所需的总时间也需要记录并在测试结果中报告。
回滚后，应运行主要功能和回归测试（自动化），以确保迁移不会影响任何因素，并且回滚成功地将旧系统恢复到原位。
迁移测试摘要报告
测试摘要报告应在完成测试后生成，并应涵盖作为迁移各个阶段的一部分而执行的各种测试/场景的摘要报告，以及结果状态（通过/失败）和测试日志。
应当明确报告以下活动记录的时间：
迁移总时间。
应用程序的停机时间。
迁移10000条记录所花费的时间。
用于回滚的时间。
除上述信息外，还可以报告任何意见/建议。
数据迁移测试中的挑战
该测试面临的挑战主要是数据。以下是其中的一些：
1、数据质量
我们可能会发现在旧的应用程序中使用的数据在新的/升级的应用程序中质量很差。在这种情况下，必须提高数据质量以满足业务标准。
诸如假设，迁移后的数据转换，在旧版应用程序本身中输入的数据等因素都是无效的，不良的数据分析等会导致不良的数据质量。这会导致高昂的运营成本，增加的数据集成风险以及与业务目的的背离。
2、数据不匹配
从旧版迁移到新/升级版应用程序的数据可能在新版中不匹配。这可能是由于数据类型，数据存储格式的更改，可能会重新定义使用数据的目的。
这导致需要付出巨大的努力来修改必要的更改，以纠正不匹配的数据或接受它并对其进行调整。
3、数据丢失
从旧版迁移到新/升级的应用程序时，数据可能会丢失。这可以是必填字段，也可以是非必填字段。如果丢失的数据是针对非必填字段的，则其记录将仍然有效，并且可以再次更新。
但是，如果必填字段的数据丢失，则记录本身将变为无效并且无法撤回。这将导致巨大的数据丢失，如果捕获正确，则必须从备份数据库或审核日志中进行检索。
4、数据量
在迁移活动的停机时间窗口内迁移需要大量时间的海量数据。例如：电信行业的刮刮卡，智能网络平台上的用户等，这里的挑战是，到时候，清除旧数据，将创建大量新数据，需要再次迁移。自动化是海量数据迁移的解决方案。
5、真实环境仿真（带有实际数据）
在测试实验室中模拟真实环境是另一个真正的挑战，测试人员会在真实数据和真实系统中遇到不同种类的问题，而这些问题在测试期间不会遇到。
因此，在执行数据迁移测试时，数据采样，真实环境的复制，识别与迁移有关的数据量非常重要。
6、模拟数据量
团队需要非常仔细地研究真实系统中的数据，并应提出典型的数据分析和采样方法。
例如：年龄段在10岁以下，10-30岁以下的用户，尽可能从真实环境获取数据，如果没有，则需要在测试环境中进行数据创建。需要使用自动化工具来创建大量数据。如果无法模拟容量，则可以在适用情况下使用外推法。
缓解数据迁移风险的提示
下面给出了一些技巧，可以减轻数据迁移风险：
标准化旧系统中使用的数据，以便在迁移时，标准数据将在新系统中可用；
增强数据质量，以便在迁移时可以进行定性数据测试，从而为最终用户带来测试的感觉；
在迁移之前清理数据，以便在迁移时，新系统中不会出现重复的数据，这也使整个系统保持干净；
重新检查约束条件，存储过程，复杂查询以产生准确的结果，以便在迁移时也可以在新系统中返回正确的数据；
确定正确的自动化工具，以便在新系统中与旧系统相比执行数据检查/记录检查。
结论
因此，考虑到执行数据迁移测试所涉及的复杂性，请记住在测试期间验证中任何方面的小失误都将导致生产中迁移失败的风险，因此进行仔细而透彻的研究非常重要。迁移前后的系统分析，使用强大的工具以及熟练且训练有素的测试人员来计划和设计有效的迁移策略。
正如我们所知，迁移对应用程序的质量有着巨大的影响，整个团队必须投入大量的精力来验证整个系统的各个方面，如功能、性能、安全性、可用性、可用性、可靠性、兼容性等，从而确保成功的“迁移测试”。
最后：
未来的你肯定会感谢现在拼命的自己！
在这里推荐一个我自己创建的软件测试交流群，QQ：642830685，群中会不定期的分享软件测试资源以及测试面试题还有行业资讯，大家可以在群中积极交流技术，还有大佬为你解答问题。