这是第一次在项目中遇到迁移测试，虽然时间不长，但是有很多启发，故而整理了这篇文章。文章中提及了许多迁移测试相关的理论，实践部分涉及的比较少。
什么是迁移?
迁移（migration）将旧版环境中的所有资源迁移到新版本的环境中，保证旧版本的功能在新版本的环境中能正常运行，新增功能能够正确部署到新环境中。
迁移测试（migration testing）主要对迁移过程和迁移结果进行验证，保证过程和结果的正确性。
为什么要做迁移？
企业级应用迁移是为了获得更加晚上的功能、更好的性能和用户体验。
企业级应用是为商业组织或大型企业提供特定解决方案的一套完整的系统。该系统包含了支持程序运行的所有组件：操作系统、后台数据库、web服务器、中间件等。
迁移有哪些分类？
根据企业级应用的组成，我们可以把迁移分为以下几类。对于不同类型的迁移，会有不同的测试策略，采取的测试活动也会不同。
应用迁移（Application Migration）是将整个应用程序从一个平台或环境中迁移到另一个中。
应用迁移的例子：
- Migrating an application to Cloud platform
- Migrating an application from ASP to ASP.NET technology, ASP.NET to Windows Azure technology, etc.
测试场景(Test scenario)：
- 应用升级（If the application is upgraded）：
- 验证已有功能没有遭到破坏，新增功能满足需求
- 数据库操作（增、删、改、查）正常
- 替换为新系统（If the application is migrated to new technology）：
- app能正常工作
- 新技术能满足app的兼容性：OS, browser version等
- 数据库操作（增、删、改、查）正常
数据库迁移（Database Migration）是将原数据库中的数据迁移到新的数据库中，迁移过程中要保证数据不丢失，并且在迁移后有效可用。因此，数据格式、类型、值等在数据库迁移中十分重要。
数据库迁移的例子：
- Migrate from one RDBMS to another
- Migrate from RDBMS to MongoDB
- Migrate from informix HC4 to HC6 or HC7
测试场景(Test scenario)：
- 迁移为相同类型数据库（If the migration is to the same type of Database）:
- 数据保持一致，无丢失和冗余
- 验证数据库shema, relationship, table structure保持不变
- 数据库与其它组件的链接正常，包括：application, server, interface, fire wall, network connectivity等
- 查询效率没有降低
- 迁移为不同类型的数据库（If the migration is a different type of Database）:
- 除上述之外，迁移为不同类型的数据库，还要考虑日期、浮点数、十六进制数的转换等
服务器迁移（Server Migration）是将服务器数据从一台服务器中迁移到另一台新的服务器中，迁移过程中服务器的配置信息也要同时迁移。
服务器迁移的例子：
- Migrating from Windows to Mainframe server
- HP BOX to IBM BOX
测试场景(Test scenario)：
- 服务器迁移，通常不单是Production server的迁移，而是包括test server在内的所有服务器的迁移
- 检查应用间的API连接是否正常
- 检查前端服务器的log
- 运行所有测试（包括手工测试），验证系统是否正常运行
- 查看与其它系统的接口是否正常工作
- 检查环境配置
操作系统迁移（OS Migration）会存在大量兼容性的问题，为了解决兼容性问题，配置、接口和组件等都需要重新设计。
操作系统迁移的例子：
- Migrating from Windows to Linux
- Migrating from Windows to Mac
- Migrating to Cloud-based Software as a Server
- Migrating to Cloud-based VMs etc
测试场景(Test scenario)：
- 迁移后检查软硬件的兼容性
- 验证迁移后功能正常运行
- 验证迁移后系统性能没有下降
迁移过程中客户关注的问题？
- 迁移由谁来执行
- 迁移脚本是否足够简单、易用、高效
- 是否会宕机时间，宕机的影响范围有多大
迁移的顺序？
一般情况下，企业级应用迁移的第一步是基础软件的升级和新版本系统应用产品的安装，然后是数据库的迁移，最后迁移应用程序。
通常情况下，迁移都不会单独发生。比如服务器迁移，同时也会迁移应用和数据库；操作系统迁移，也都伴随着应用的基础软件的升级和应用迁移。
迁移测试的分类？
垂直迁移测试是迁移测试的基本方法，所有测试都必须是在完成从旧版本到新版本迁移的系统环境上进行的。
按照迁移的顺序，首先是软件升级测试、数据库迁移测试、应用迁移测试，其次是在迁移之后的环境上进行子系统迁移的测试、集成系统迁移测试、客户定制化迁移测试、功能测试、性能回归测试、迁移扩展性测试。
- 作为一个完整的迁移测试框架，垂直迁移测试需要考虑从底层软件到上层应用的每一个功能点。
- 功能测试：验证迁移之后系统功能的完整性和正确性，是对完成迁移的应用系统的功能回归测试
- 性能测试：比较迁移前后应用的系统的性能测试结果，期望是迁移后系统性能没有下降，各项性能指标都在客户可接受的范围内
水平迁移测试是对垂直迁移测试的补充，主要用于垂直迁移测试框架中的数据库迁移测试和应用迁移测试。
- 垂直迁移测试是水平迁移测试的基础，只有完成了垂直迁移测试框架中的数据库迁移和应用迁移，才能开始水平迁移测试。
- 应用配置信息验证
- 数据库验证
- 加密信息验证
迁移测试实例
-
需求描述
- 一个中台系统，用于从企业内部系统创建和使用外部会议系统。最初这个系统是部署在团队搭建的集群上，后来客户要求我们将服务迁移到企业的云平台上，数据库保留。
-
测试分析
- 从需求上看，这是一个服务器迁移的例子。但是，在迁移服务器的同时，要对旧系统的网关、防火墙、与其它系统的交互等进行更新，也就涉及到了应用迁移。
-
测试需求
- 迁移要不中断开发进程，不影响用户的使用
- 迁移后，系统性能不能下降
-
测试方案
- 测试是在迁移完成后进行的，测试环境（SIT, UAT）和产品环境的迁移是依次进行的，测试在不同环境上的侧重不同
- 运行所有自动化测试，验证系统功能是否正常
- 在测试环境中运行验收测试（包括手动回归），验证系统是否正常工作
- 检查与其它系统的接口是否正常工作
- 验证与数据库的链接是否正常，查询效率没有降低
- 检查用户权限是否正常（客户有独立的用户管理系统）
- 检查系统log
- 在迁移前后的UAT环境中做性能测试，对比系统的性能
- 迁移同时伴随新版本发布，安排在周六晚上进行，不考虑宕机对客户的影响
其它相关迁移测试
- 兼容性测试：开发框架升级、API不兼容、系统间认证
- 安全性测试：在迁移环境进行文件权限认证及敏感数据验证
- 可靠性测试：迁移过程中如果有宕机，减少对系统的影响
Reference
Data Migration Testing Tutorial
Types of Migration Testing: With Test Scenarios for Each Type
