服务升级保障
正常的版本测试工作中，测试测收到一个新功能的测试版本，提测的单子里一般会的内容如下：
1、测试版本中涉及到的各个服务的提测版本（代码仓库的镜像版本号）
2、新增/修改的库表SQL执行文件（包含旧数据的处理）
3、提测版本覆盖的需求列表
4、各服务新增的配置项等
接下来，你认为测试工作的第一步是做什么呢？
数据是软件程序的原料，遵循数据先行的法则。首先，我们会先进行数据升级测试。目的是进行新功能版本的向上兼容性测试。即更新了表结构，新增了表字段，对旧数据做了新SQL的处理。数据结构是否可以兼容已上线版本。
服务升级保障的工作的第一步是进行服务升级测试，具体流程如下：
1、执行SQL，更新表结构，旧数据的处理
2、接口自动化脚本回归测试，进行数据的向上兼容测试
3、申请一个新的服务器，部署新的迭代版本
4、Nginx 把用户流量按权重的方式放量到新版本的服务中，进行平滑的版本切换
服务回滚策略
代码测试完成后，接下来就要进行系统的部署，在部署系统时，要考虑当前代码逻辑出现错误后如何快速恢复，总结为部署版本化、小版本增量发布、大版本灰度发布、架构升级并发发布。项目代码改动的规模以及涉及的影响去进行不同的部署。核心就是尽量小的减少部署可能带来的影响的同时，去降低部署失败后，如何去快速恢复。
部署版本化
将上一版本的包记录到部署系统中，在发布时应该采用全量发布，避免增量发布，必要可以之前全量版本回滚，不会受到限制。
小版本增量发布
比如修付小bug，添加一些简单的逻辑，这些都属于小问题。增量发布就是比如有10台服务器，先发布一台，没有问题了，再发布10台，最后全量发布。
大版本灰度发布
页面改版，添加新功能，大的改动，都需要进行灰度发布，一般情况是两个版本并行跑一段时间，一些用户访问老版本，一些访问新版本，测试成功后再全量发布。
架构升级并发布
架构升级时，很多问题都不确定，因为这时候新旧集群都会同时，存在，并且流量会慢慢迁移到新版本集群，老版本的部分功能，也可能继续运行，如果涉及到业务功能的大变动，这时候需要旧版本调用新版本提供的接口，后面会慢慢下线。
如出现服务回滚的情况，测试人员需要进行回滚测试，测试流程如下：
1、新起一个服务，系统版本部署老的版本（运维操作）
2、执行自动化的脚本测试，数据的向下兼容
3、执行SQL文件，还原表结构
4、执行自动化的脚本测试
