系统升级测试
随着软件行业敏捷开发的推进，软件的版本迭代越来越快，升级测试在软件测试中也变得越来越重要。升级测试是安装测试的一个分支，主要检验软件从低版本升级到高版本的能力，关注升级过程是否成功，用户数据是否得以保留或更新，升级后系统文件是否更新、系统功能是否正常。
1.1升级测试 vs. 全新安装测试
相对于软件全新安装来说，升级测试更为复杂，主要的区别如下：
| 类别 |
全新安装 |
升级测试 |
| 关注版本 |
一个（当前版本） |
多个（多个旧版本、当前版本） |
| 测试前准备 |
没有或很少 |
旧版本备份（数据、配置等）、模拟数据、模拟客户环境等 |
| 执行过程复杂度 |
低（默认参数执行安装） |
高（版本验证、新旧版本区别、参数的增减修改等等） |
| 执行后验证 |
回归测试 |
数据迁移和更新验证、新功能验证，回归测试 |
从图表中可见，相对全新安装，升级测试需要考虑的方面多且复杂，测试执行也需要更多的资源。
1.2升级测试中面临的问题
升级测试很容易做，但做好却很难。我们经常会在升级测试中面临各种各样的困扰：
- 如何准备升级前环境？
- 客户环境是怎样的？
- 怎样创造数据？
- 应该做到升级路径全覆盖还是选择性覆盖？
- 升级后如何验证升级成功？
- 升级后如何回归？
。。。。。。
面对这么多问题，一开始总会让我们无所适从，那么如何打开思路，进行高效升级测试呢？这就提到了升级测试模型。
2 升级测试模型
升级测试模型主要包括几个测试阶段：前期准备阶段、升级过程测试阶段以及后续的回归测试阶段。每个阶段之间都有强关联，在测试的过程中需要特别注意，下面对各个阶段进行展开介绍。
2.1升级前准备
升级测试前期准备主要包括：升级流程分析、环境搭建、数据准备以及备份策略。
- 升级流程分析：升级流程分析是测试准备中的一个重要关注点，就像产品功能测试的需求一样，升级流程是很重要的升级测试需求来源。对于不同方式的升级流程而言，需要有不同的测试策略，比如对于以下的升级流程：
- 文件替换升级：需要更关注文件替换后的版本更新，数据保留，回归策略等
- 卸载-》安装-》数据迁移：需要关注卸载安装过程、数据的完整性，回归策略等
通过分析升级流程，画出软件升级的流程图，并根据流程图中的判断逻辑创建逻辑路径覆盖测试用例，不仅清晰而且不容易遗漏。（下图来自互联网）
所以在开展升级测试之前一定要对测试流程进行详细的分析，以便在之后的升级测试中做到有的放矢。
- 环境搭建：对于升级前环境的搭建需要遵循20/80原则，因为不可能罗列所有用户环境并且每个都进行测试，建议的搭建策略：
- 按照产品安装文档进行环境搭建
- 分析客户环境，对OS配置、第三方软件及版本、产品旧版本、产品部署方式进行分析，选取具有代表性的环境配置以及典型的升级路径
- 数据准备：升级前数据的准备对升级测试中数据完整性起到了决定性的作用，可以通过以下几种途径来提高数据的覆盖率：
- 分析用户使用场景，罗列常用场景并进行端到端的数据模拟
- 分析客户数据库，针对数据表进行分析，获得常用场景
- 如果版本合适，利用客户的数据库进行测试
- 备份策略：测试环境搭建好之后需要对数据库、配置文件等进行备份，以便在后续测试中减少重复准备工作和进行升级前后的比较工作。
2.2升级过程验证
升级过程测试阶段依赖于升级前准备中的升级流程分析，不同的升级流程对升级过程的关注点也不同，本模型中罗列的是一些具有通用性的升级过程阶段：版本检查、软件依赖检查、安装参数检查、备份机制、产品模块更新、用户数据保留、文件版本检查、升级日志及失败重试机制。
下面着重介绍比较重要的几个验证阶段:
- 软件依赖检查：对于大型的软件系统而言，一般都有所依赖的第三方软件，比如说数据库、.NET等。产品新旧版本之间可能用到的第三方软件产品或者版本不同（在升级前准备阶段的环境搭建中罗列），针对这种情况，升级程序需要提供对第三方软件的检测，尽早给出提示信息，避免产品升级之后产品不能工作的情况发生。
- 产品模块更新：产品模块的更新包括模块的添加、更新和删除。该部分的验证需要更多依赖对于产品不同版本之间的分析和理解：
- 对于升级前版本存在、新版本删除的模块，在升级之后需要删除，包括安装目录、数据库表、配置文件等。
- 对于升级前版本不存在的模块，升级后需要正确安装
- 对于需要更新的模块，需要验证安装文件是否更新
- 用户数据保留（完整性）：用户数据的验证主要包括数据库和配置文件的验证，主要的验证方式：
- 数据库数据验证：
a) 升级后新版本和之前版本数据库中用户数据的比较（检查用户数据是否保留）
b) 升级后新版本和全新安装新版本进行比较（检查数据库结构是否一致）
c) 升级后新版本和全新安装新版本数据库默认数据进行比较（验证默认数据的准确性）
对于数据库的验证包括数据库的结构和数据的验证：结构包括表、索引、视图、存储过程以及agent job等；数据的验证主要包括对主要数据表的数据进行验证。
因为这一部分是比较容易出问题的，这里罗列一些比较好的实践和注意点：
1) 针对数据库比较庞大的系统，具体分析数据库，获取关注的数据库表，忽略不关注表（比如一些可以删除的history或者log表）的数据比较。
2) 某些情况下，数据库在升级之后一些数据的id会变化，需要确保以该id为foreign key的列也得到相应的更新
3) 针对某些数据变化的列，需要特别注意分析业务逻辑判断是否需要更改，比如某列的默认值为0，用户在使用过程中修改为1，而新版本的默认值为5，这就需要判断升级后是保留用户原系统的值1，还是使用新系统的默认值5，这是需要特别注意的
另外针对数据库的比较有很多好用的工具，如Visual Studio自带的数据库比较、DB Comparer等。
- 配置文件的验证：
a) 升级后新版本和之前版本配置文件进行比较（保证用户在之前版本中的配置保留）
b) 升级后新版本和全新安装新版本配置进行比较（保证配置结构和数据正确）
2.3非功能测试和负面测试
非功能性测试：这里主要列出了性能方面的时间以及内存消耗。这部分在数据库过大的情况下数据迁移比较容易出现时间过长、内存占用过大的情况。
负面测试：主要来验证升级程序针对一些打断或者边缘情况的处理能力，保证能够失败重试，或者即使不能升级成功也可以恢复到升级前的状态
2.4回归测试
经过了升级过程的验证，新版本已经安装成功，这时候就需要验证新版本是否能够工作正常。回归测试的级别和策略需要视产品性质而定，一般分为：
- BVT验证：最基本的验证测试，用来保证安装完成后基本工作工作正常
- 基于改动的功能验证：该部分需要对升级前后的产品差异有清晰的了解，针对相应的改动有侧重点的开展测试
- 新功能验证：针对新版本的新特性进行测试
- 用户数据验证：有了对升级过程中的数据完整性的验证，可以保证用户数据得以保留，这样还不够，需要通过客户端进行数据展现，保证展现正常
3总结
升级测试模型提供了升级测试开展的一个突破口，针对升级过程中的前期准备，升级过程验证以及后续升级完成后的回归测试打开了一些思路，并且对1.2中升级测试中的问题提出了一些解决方案，但罗列的各个检测点不一定适用于所有的产品，大家可以在具体的测试过程中有所取舍。
附录：升级测试模型（upgrade testing model)
