系统升级测试模型

系统升级测试

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

1.1升级测试 vs. 全新安装测试

相对于软件全新安装来说，升级测试更为复杂，主要的区别如下：

类别	全新安装	升级测试
关注版本	一个（当前版本）	多个（多个旧版本、当前版本）
测试前准备	没有或很少	旧版本备份（数据、配置等）、模拟数据、模拟客户环境等
执行过程复杂度	低（默认参数执行安装）	高（版本验证、新旧版本区别、参数的增减修改等等）
执行后验证	回归测试	数据迁移和更新验证、新功能验证，回归测试

从图表中可见，相对全新安装，升级测试需要考虑的方面多且复杂，测试执行也需要更多的资源。

1.2升级测试中面临的问题

升级测试很容易做，但做好却很难。我们经常会在升级测试中面临各种各样的困扰：

1. 如何准备升级前环境？
2. 客户环境是怎样的？
3. 怎样创造数据？
4. 应该做到升级路径全覆盖还是选择性覆盖？
5. 升级后如何验证升级成功？
6. 升级后如何回归？

。。。。。。

面对这么多问题，一开始总会让我们无所适从，那么如何打开思路，进行高效升级测试呢？这就提到了升级测试模型。

2 升级测试模型

升级测试模型主要包括几个测试阶段：前期准备阶段、升级过程测试阶段以及后续的回归测试阶段。每个阶段之间都有强关联，在测试的过程中需要特别注意，下面对各个阶段进行展开介绍。

2.1升级前准备

升级测试前期准备主要包括：升级流程分析、环境搭建、数据准备以及备份策略。

 

• 升级流程分析：升级流程分析是测试准备中的一个重要关注点，就像产品功能测试的需求一样，升级流程是很重要的升级测试需求来源。对于不同方式的升级流程而言，需要有不同的测试策略，比如对于以下的升级流程：

1. 文件替换升级：需要更关注文件替换后的版本更新，数据保留，回归策略等
2. 卸载-》安装-》数据迁移：需要关注卸载安装过程、数据的完整性，回归策略等

通过分析升级流程，画出软件升级的流程图，并根据流程图中的判断逻辑创建逻辑路径覆盖测试用例，不仅清晰而且不容易遗漏。（下图来自互联网）

所以在开展升级测试之前一定要对测试流程进行详细的分析，以便在之后的升级测试中做到有的放矢。

• 环境搭建：对于升级前环境的搭建需要遵循20/80原则，因为不可能罗列所有用户环境并且每个都进行测试，建议的搭建策略：

1. 按照产品安装文档进行环境搭建
2. 分析客户环境，对OS配置、第三方软件及版本、产品旧版本、产品部署方式进行分析，选取具有代表性的环境配置以及典型的升级路径

• 数据准备：升级前数据的准备对升级测试中数据完整性起到了决定性的作用，可以通过以下几种途径来提高数据的覆盖率：

1. 分析用户使用场景，罗列常用场景并进行端到端的数据模拟
2. 分析客户数据库，针对数据表进行分析，获得常用场景
3. 如果版本合适，利用客户的数据库进行测试

• 备份策略：测试环境搭建好之后需要对数据库、配置文件等进行备份，以便在后续测试中减少重复准备工作和进行升级前后的比较工作。

2.2升级过程验证

升级过程测试阶段依赖于升级前准备中的升级流程分析，不同的升级流程对升级过程的关注点也不同，本模型中罗列的是一些具有通用性的升级过程阶段：版本检查、软件依赖检查、安装参数检查、备份机制、产品模块更新、用户数据保留、文件版本检查、升级日志及失败重试机制。

下面着重介绍比较重要的几个验证阶段:

• 软件依赖检查：对于大型的软件系统而言，一般都有所依赖的第三方软件，比如说数据库、.NET等。产品新旧版本之间可能用到的第三方软件产品或者版本不同（在升级前准备阶段的环境搭建中罗列），针对这种情况，升级程序需要提供对第三方软件的检测，尽早给出提示信息，避免产品升级之后产品不能工作的情况发生。

• 产品模块更新：产品模块的更新包括模块的添加、更新和删除。该部分的验证需要更多依赖对于产品不同版本之间的分析和理解：

1. 对于升级前版本存在、新版本删除的模块，在升级之后需要删除，包括安装目录、数据库表、配置文件等。
2. 对于升级前版本不存在的模块，升级后需要正确安装
3. 对于需要更新的模块，需要验证安装文件是否更新

• 用户数据保留（完整性）：用户数据的验证主要包括数据库和配置文件的验证，主要的验证方式：

1. 数据库数据验证：

a)       升级后新版本和之前版本数据库中用户数据的比较（检查用户数据是否保留）

b)      升级后新版本和全新安装新版本进行比较（检查数据库结构是否一致）

c)        升级后新版本和全新安装新版本数据库默认数据进行比较（验证默认数据的准确性）

对于数据库的验证包括数据库的结构和数据的验证：结构包括表、索引、视图、存储过程以及agent job等；数据的验证主要包括对主要数据表的数据进行验证。

因为这一部分是比较容易出问题的，这里罗列一些比较好的实践和注意点：

1)      针对数据库比较庞大的系统，具体分析数据库，获取关注的数据库表，忽略不关注表（比如一些可以删除的history或者log表）的数据比较。

2)      某些情况下，数据库在升级之后一些数据的id会变化，需要确保以该id为foreign key的列也得到相应的更新

3)      针对某些数据变化的列，需要特别注意分析业务逻辑判断是否需要更改，比如某列的默认值为0，用户在使用过程中修改为1，而新版本的默认值为5，这就需要判断升级后是保留用户原系统的值1，还是使用新系统的默认值5，这是需要特别注意的

另外针对数据库的比较有很多好用的工具，如Visual Studio自带的数据库比较、DB Comparer等。

1. 配置文件的验证：

a)       升级后新版本和之前版本配置文件进行比较（保证用户在之前版本中的配置保留）

b)      升级后新版本和全新安装新版本配置进行比较（保证配置结构和数据正确）

2.3非功能测试和负面测试

                               

                非功能性测试：这里主要列出了性能方面的时间以及内存消耗。这部分在数据库过大的情况下数据迁移比较容易出现时间过长、内存占用过大的情况。

                负面测试：主要来验证升级程序针对一些打断或者边缘情况的处理能力，保证能够失败重试，或者即使不能升级成功也可以恢复到升级前的状态

2.4回归测试

经过了升级过程的验证，新版本已经安装成功，这时候就需要验证新版本是否能够工作正常。回归测试的级别和策略需要视产品性质而定，一般分为：

1. BVT验证：最基本的验证测试，用来保证安装完成后基本工作工作正常
2. 基于改动的功能验证：该部分需要对升级前后的产品差异有清晰的了解，针对相应的改动有侧重点的开展测试
3. 新功能验证：针对新版本的新特性进行测试
4. 用户数据验证：有了对升级过程中的数据完整性的验证，可以保证用户数据得以保留，这样还不够，需要通过客户端进行数据展现，保证展现正常

3总结

      升级测试模型提供了升级测试开展的一个突破口，针对升级过程中的前期准备，升级过程验证以及后续升级完成后的回归测试打开了一些思路，并且对1.2中升级测试中的问题提出了一些解决方案，但罗列的各个检测点不一定适用于所有的产品，大家可以在具体的测试过程中有所取舍。

附录：升级测试模型（upgrade testing model)