前段时间，有不少网友反映，自己收到了奇怪的短信。短信的内容十分诡异，是一连串的短信内容是一连串诡异数字，随后在网上引发热议。 

      收到数字短信的网友覆盖广泛，有北京、上海、广州、天津、南京、杭州、石家庄、合肥、青岛等，涉及多个省份的多个城市，短信内容为循环的13次“1234567890”加1次“123456789@”。 

令人奇怪的是，收到诡异短信有136、137号段，而且从网友反映来看以136号段居多；发送方则基本都是130号段，且与本机号码只相差一个数字，就是把6换成了0，不少网友称后8位都相同，换言之两个号码仅有一个数字的差别。 

在收到短信后，有网友第一时间进行了回复，却发现发送的号码为空号，根据分析，136主要是移动号段，130大多属于联通号段，于是网友纷纷猜测是否是联通内部系统的问题。 

发现问题后，中国移动公司立即启动应急响应流程，对相关短信进行拦截处理。并在次日，发布了处理报告： 

经协同中国联通核实，原因为中国联通山东分公司进行系统升级测试所致，中国联通在定位原因后已迅速进行了相应处置。 

随后，中国联通官方微博也发布消息称：

      其实这次事件的起因主要在于对升级测试的疏忽，我们都知道，升级测试是软件测试中非常重要的一环，需要考虑的方面有很多，比如用户数据是否被完整保存，升级失败如何恢复等都对测试人员制定测试策略和编写测试用例带来了一定的挑战。 

因此如何做好升级测试对一个测试员来说至关重要，本期，借着这个话题来给大家谈谈如何做好升级测试。

如何做好升级测试？

      系统升级测试是指测试系统是否能被正确地升级，它包含两个方面的内容，一是升级后系统的功能是否被正确地升级;二是升级的方式。不同的升级方式显然带来的成本是不一样的，而软件升级方式无非包括以下三种：

       (1)提供网络安装包的下载，由客户自己下载安装。

(2) 网络在线升级。

(3) 技术支持工程师现场升级。

       作为企业来说，网络在线升级是最好的方式。升级测试很容易做，但做好却很难。我们经常会在升级测试中面临各种各样的困扰：

       1.  如何准备升级前环境？

2.  客户环境是怎样的？

3.  怎样创造数据？

4.  应该做到升级路径全覆盖还是选择性覆盖？

5.  升级后如何验证升级成功？

6.  升级后如何回归？

。。。。。。

下面我们就来谈谈如何高效的进行升级测试。

       升级前的准备：

       在升级前，我们需要准备的步骤有三点

       1、模拟用户场景生成测试数据

       1）应用系统或软件产品一般都需要进行不同阶段的验证工作，包括原型功能论证、功能测试、性能测试等，这些测试、论证场景都可能涉及到测试数据的准备。

       2）根据用户的业务需求、数据预置约束条件、数据间层级关联等条件，生成对应的模拟验证数据。一般来说，按照用户要求模拟数据应该做到：数据量可控、充分的随机性、保持数据间特定的逻辑关联关系（包括直接关联或隐含关联）。

       2、模拟用户环境搭建

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

       1）按照产品安装文档进行环境搭建

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

       3、备份工作

       最后，我们还需要尽可能多的备份原始数据，其中包括数据库备份，配置文件备份等等，如果有条件的话还可以创建环境的镜像。

       升级过程：

       部署模式

对于部署模式我们需要考虑是部署模式，如果是手机APP的话就需要思考是用simulator还是真机的情况。

       版本检查

需要清晰的定义版本，对于哪些版本能够做升级需要明确定义

       前置条件检查

在检查完版本后，我们还需要对产品依赖的第三方进行检查，首先需要确定版本需要的第三方软件是否安装，版本对吗，等问题，进行严格检查，预防安装之后的不可逆性质。

       安装参数的检查与更新

       大型软件一般在安装的过程中都会有参数配置，这个阶段我们需要检查包括之前版本的默认参数，新版本对之前版本默认参数值的修改以及新版本新添加的参数值等。

       备份策略

       在升级之前，我们需要对用户配置、用户文件和用户数据进行备份机

       产品模块更新

       我们需要查看旧版本存在新版本删除的模块是否完全卸载，同时确定新增加的版块是否正确安装，产品模块的更新包括模块的添加、更新和删除。该部分的验证需要更多依赖对于产品不同版本之间的分析和理解：

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

       数据库数据验证：

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

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

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

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

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

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

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

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

       文件版本检查

检查升级后文件版本是否更新，新增文件是否被正确创建，需要删除的文件在升级后是否正确删除。

       产品文件更新

安装完成之后要保证产品的文件版本得到更新，需要删除和添加的文件也都正确

       日志管理

日志也是比较重要的一块，日志的详细程度可以根据产品来定，目的是升级失败后能够很好很快的定位问题

写在最后

       结合部分项目中的实际情况和一些文章总结整理出了升级测试的阶段和方式。在实际的项目中大家可以结合实际情况进行选择。

更多软件测试相关推荐：

软件测试更多干货文章

软件测试就业培训