转存原作：https://www.cnblogs.com/AlwinXu/p/5836667.html

系统升级测试

随着软件行业敏捷开发的推进，软件的版本迭代越来越快，升级测试在软件测试中也变得越来越重要。升级测试是安装测试的一个分支，主要检验软件从低版本升级到高版本的能力，关注升级过程是否成功，用户数据是否得以保留或更新，升级后系统文件是否更新、系统功能是否正常。

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)