系统升级测试模型

系统升级测试

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

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)