web应用数据库测试 数据迁移测试需要注意哪些点？ 测试过程中可能存在哪些风险？

有同学可能会问：数据迁移测试需要注意哪些点？ 测试过程中可能存在哪些风险？

首先web应用数据库测试，需要关注数据迁移的技术细节。 数据迁移通常有两种类型，同类型数据库的迁移和异类型数据库的迁移。 不同类型的数据库迁移可能涉及表结构的改变、编码和语法的差异，这会增加迁移的难度。 从表结构来看，有的迁移涉及直接复制表，有的迁移涉及表结构的拆分和合并。 测试后者时，需要关注每个表的字段、类型、长度和映射的变化。 迁移数据的规模也会影响迁移的结果。 随着数据量的增加，数据库表迁移的准确性变得更加困难。

另外，还需要关注迁移时数据的业务状况。 一般来说，在迁移过程中，服务器应用程序会提前停止服务并进行必要的数据检查，以避免迁移过程中出现新的服务或操作系统带来的迁移问题。 如果迁移涉及到表结构的改变，如增加、修改、删除表字段等变化，测试时需要关注各个表的修正以及数据和报表的变化。

最后，需要关注迁移点前后业务规则的变化。 除了考虑新系统中的规则变化外，还需要考虑旧数据迁移后规则适配的需要。 例如，如果旧系统没有新系统有的字段，请验证是否给出了正确的默认值。 保证旧系统数据迁移后业务的可用性和连续性，避免迁移后需要回滚测试。

接下来我们将详细介绍数据迁移的测试策略和测试实现。 废话不多说，下面开始实际操作吧~

迁移测试验证策略和计划 1.需要熟悉迁移计划

了解新旧系统的上线计划，以及如何迁移数据以及如何处理现有的兼容数据。 新旧系统切换时是否关闭批处理和日终初批处理服务。 上线后，旧的系统设备如何处理，是丢弃还是继续使用。 在数据整合方面，流程如何处理，账户如何迁移。 数据同步方面，了解同步时间策略和同步范围策略，是全量同步还是增量同步。

以商业票务系统为例，迁移的总体技术方案是编写迁移shell脚本。 首先在旧数据库中建立一个与新数据库中业务表字段相同的临时表。 将旧数据库中的数据过滤处理成临时表，然后将临时表中的数据导出到表数据文件中，使用sqlldr将informix数据文件导入到oracle数据库中。 现有数据一次性迁移，增量数据实时迁移。 迁移时间是在一天开始之后。 新系统上线后，仍使用旧系统。 因此，在测试时，不仅需要对新系统中迁移的数据进行业务验证，还需要对旧系统进行回归验证。

2.需要了解迁移范围和迁移规则

熟悉迁移方案后，需要划定迁移范围，进行有针对性的测试和验证，分析是否涉及基础数据迁移、历史业务数据迁移、过程中是否涉及数据迁移。

1. 注意迁移数据的类型和状态。 不同类型的数据测试有不同的关注点。 例如：基础数据迁移后，需要关注新旧系统的数据一致性。 纯历史数据迁移后，除了数据一致性之外，还需要关注迁移后的新系统。 系统查询、业务是否正常。 流程中的数据需要关注各个环节的状态以及正在进行的业务是否可以后续处理。

2、了解数据迁移规则、数据库变更点、字段类型、长度等字段变化、映射关系，并根据规则设计测试用例，保证迁移后映射正确。

3、关注关联系统提供的相关文件，分析迁移涉及的关联系统数量以及对应的卸载文件，验证卸载后文件到关联系统的数据量和字段的正确性移民。 特别需要注意的是，编码方式可能会发生变化，需要及时与上下游系统同步制定解决方案，避免乱码的产生。

3.注意备份和回滚计划

包括数据备份和回滚以及应用程序备份和回滚。 如果迁移失败或者出现迁移问题，可以及时回滚迁移。 迁移过程中应考虑特殊情况。 例如，在该商业发票系统中，如果在生产过程中发现维护错误或记录缺失，可以通过新设置的维护功能进行手动维护。

4.制定数据迁移测试计划

测试主要通过技术手段和业务手段的验证来保证迁移的正确性。 测试前，根据每轮SIT测试计划规划数据迁移验证时间。 通常三轮SIT中间安排两轮迁移测试。 如果有UAT5回归测试web应用数据库测试，可以在回归环境中验证一轮。 迁移涉及重置环境。 如果有外部联调单位，迁移测试日程需要根据联调单位进行调整。

经验总结：

技术水平主要验证以下几点：

① 数据量0丢失，包括数据迁移多了还是少了。 测试基于根据迁移规则过滤数据量，并在迁移前后进行迁移前和迁移后SQL检查。

②数据库测试点：数据库表、字段处理规则； 字段映射、迁移规则验证。

③ 检查迁移日志，检查分步迁移处理是否合理，数据记录是否正确。

④ 迁移初始值，如特殊序列号、业务ID、账户ID等序列号的配置和处理。

⑤ 考虑异常情况、异常数据、异常事务、异常处理情况。

业务层面主要验证以下几点：

① 登记报表功能及数据准确性；

②功能可用性；

③业务连续性。

迁移测试准备和测试实施

迁移测试准备：

测试数据准备：数据预嵌入是测试前非常重要的准备步骤，它决定是否有足够、完整的数据来满足迁移测试。 确认迁移方案和方案后，准备迁移测试的数据。 对于复杂的场景，一定要对场景表进行整理，并根据整理后的场景表嵌入数据。 嵌入数据后，需要确认嵌入数据的完整性，避免切换系统。 以后无法添加所需的数据。 这部分数据可以在进入SIT测试时先进行验证，因为有些数据是及时的，比如账单可能到期了，无法用于后续的业务连续性测试。

迁移前数据备份：迁移前导出并备份相关业务报表数据，并在后续迁移测试时进行验证。 开发还会在迁移前嵌入数据库备份，以防止迁移出现需要回滚的问题。

迁移测试实施示例：

以商票系统为例，我们首先进行数据量验证，涉及到以下两个方面：

① 验证新旧系统业务表/公共数据表的查询、统计、前后端比对；

② 确保涉及公共机构表数据和用户数据的数据准确性。

其次，验证数据准确性：

① 确保数据不丢失，并根据迁移规则过滤数据量，保证迁移前数量与迁移后数量一致；

②数据库测试点，通过对比迁移前后的数据库表、字段处理规则、字段映射、迁移规则等进行验证。

③公开表中涉及的机构权限和用户数据位置准确。

三是登记报告核查，主要涉及核查总行、分行等机构的销售登记/日末余额登记表字段是否正确，总数是否正确； 最后进行功能可用性验证和业务连续性验证。

功能可用性验证和业务连续性验证主要验证以下几个方面：

① 新系统中旧数据和新数据的运行过程是否受到阻碍； 旧系统在新系统取票界面可以正常取票，其他差异化票务业务流程不受影响。

② 可以查询旧数据，也可以查询新数据； 迁移后新数据/旧数据可以在新系统寄存器中查询，旧数据可以在旧寄存器中查询。

③业务连续性验证涉及票据迁移（传统票据贴现后），可以保证后端业务能够正常开展； 涉及公共数据，保证用户或组织下的相关业务能够正常开展。

④最后，特殊情况和异常验证，流程中的数据（在途业务的处理），流程中的数据需要关注各个环节的状态，关注在途业务是否可以处理之后。

最后：下面完整的软件测试视频教程已经编译并上传。 有需要的朋友可以自行获取【保证100%免费】

软件测试面试文档

我们必须学习才能找到一份高薪工作。 以下面试题是来自阿里巴巴、腾讯、字节等一线互联网公司的最新面试材料，部分字节老板给出了权威答案。 做完这套相信大家都能根据面试信息找到满意的工作。