问题描述

在软件产品开发或项目开发过程中，由于新功能和特性的变更，不可避免地会产生版本迭代。为验证软件升级或回退版本后是否可以正常工作，通常需要进行人工的部署测试演练。

在产品发布的版本较多之后，不同用户可能使用不同的旧版本进行升级，继续使用这种人工测试需要对所有小版本进行 n(n-1)/2 次数的验证，当小版本较多时，人工部署验证将变得非常低效，例如：

某软件在V1.X下有10个特性版本，不考虑缺陷修复的情况下，版本号为：V1.0.X，V1.1.X，…，V1.10.X，在最坏的情况下该软件产品所有的特性版本都有用户在使用，在发布第11个特性版本时，需要测试的次数为：

$$C_{11}^{2}$$ - $$C_{10}^{2}$$ = $$A_{11}^{2}$$ / $$A_{2}^{2}$$ - $$A_{10}^{2}$$ / $$A_{2}^{2}$$= 11 * (11 - 1) / 2 - 10 * (10 - 1) / 2 = 55 - 45 = 10

其中$$C_{11}^{{2}$$为新增最新版本所需要测试的总组合数，$$C_{10}}{2}$$为上一版本已经测试覆盖的总组合数。

基于以上现状，非常有必要将软件版本升级回退测试自动化，本文基于此需求背景，探讨一种基于版本控制的软件升级/回退自动化测试流水线系统

本文将围绕以下内容展开介绍：

• 测试制品构建的版本控制
• 测试脚本的版本控制
• 升级/回退验证自动化测试流水线系统

测试制品构建的版本控制

进行软件的版本升级回退验证，首先要对各版本的软件构建制品进行版本控制。软件构建制品的发布形式多种多样，可以为集成安装包（包括但不限于iso、exe、rpm、deb或各种压缩归档文件包），也可以为容器镜像。

无论以何种形式分发（Distribution），都需要在制品命名规则加入版本号，以区分不同版本的软件构建制品。如：software_name-V2.2.0.deb（适用于Debian操作系统的dpkg安装包）或software_name:V2.2.0（Docker容器镜像）。

测试脚本的版本控制

通常使用版本控制工具（如Git）控制测试脚本的版本，针对不同版本的软件制品，设计开发不同版本的测试脚本，并将测试脚本通过打tag的方式增加版本tag，在测试特定版本的软件时，签出特定版本的tag，从而对该版本特有的特性进行测试覆盖。

一些所有版本都需要涉及的基础操作，可以在测试脚本文件名增加特殊的前缀（如[pre-upgrade]或[post-downgrade]等）进行标识，在测试框架中增加规则对这些脚本进行特殊处理（如，仅在升级前执行或进在回退后执行等）。

升级/回退验证自动化测试流水线系统

如图所示，升级/回退验证自动化测试流水线系统分为三个阶段：升级前测试、升级后测试和回退测试。

测试人员或定时任务通过选择或预先设置的升级前后版本启动升级/回退自动化测试。
系统执行升级前测试阶段时，先从制品库拉取并部署升级前版本的制品，然后通过git仓库根据升级前版本获取对应版本的测试用例（脚本、测试剧本等），最后执行升级前版本特性自动化测试。

完成执行升级前测试阶段后，系统开始执行升级后测试：先从制品库拉取升级后版本的制品并进行版本升级，然后通过git仓库根据升级后版本获取对应版本的测试用例（脚本、测试剧本等），最后执行升级后版本特性自动化测试。

完成执行升级后测试阶段后，系统开始执行回退测试：根据之前获取的升级前版本制品执行回退部署，然后执行之前通过git仓库根据升级前版本获取对应版本的测试用例（脚本、测试剧本等）进行回退到旧版本的版本特性自动化测试。

在各个阶段执行自动化测试的同时会自动生成测试报告，最终完成回退测试后系统自动汇总各阶段测试报告并进行统计分析，根据测试结果发送通知给测试人员，并通过特定http服务展示测试结果。

执行升级/回退后版本特性自动化测试流程如下图：

开始测试后测试系统读取下一个测试用例，如果当前测试阶段为升级后或回退后阶段，且用例存在升级/回退后无需再执行的标记，则直接读取下一个用例，否则就执行当前用例，并向测试报告追加此次测试结果。如果执行完当前用例后还有其他用例则继续读取下一个用例并执行，否则结束测试。

总结

通过本文介绍的方法，可以将升级/回退自动化测试用例进行版本管理并组织为自动化测试流水线，将软件在不同版本间的升级/回退以及其后的功能用例进行自动化测试验证，从而节省大量的测试人力成本。