背景
项目中当开完成新版本，比如说v_x.0.1的开发，如果需要进行环境部署，需要考虑线上环境的部署方式，而不是直接找一台新的服务器部署v_x.0.1服务即可，通常会有这两种升级方案
停服升级
通过nginx或网关将客户端对外的入口流量权重配置为0，这时遇到新的用户访问会被拒绝处理，比方说web页面返回5XX状态码。
具体停服升级的过程：
客户端流量权重调配为0
检查服务是否存在未处理完成的请求（查看日志、数据库）
通过kill -9等实例下线方式进行进行服务资源回收
升级数据库（字段更新、表更新、历史数据处理、增量数据处理）
直连物理机部署v_x.0.1服务/应用 或者 通过云原生平台进行容器化应用的部署
客户端流量权重调配为100%
优势：可以满足各种兼容性问题的升级方案
劣势：影响用户在指定时间段的应用使用
平滑升级（滚动升级）
会在新的容器或物理机部署新版本服务，再进行旧版本的实例回收。
具体升级过程：
先进行数据库升级
准备新的物理机或容器部署新版本服务
通过客户端的流量权重控制将流量全量转发到新版本
检查旧版本服务是否存在未处理的业务数据
旧版本服务实例/容器回收
优势：不影响线上用户的正常使用
劣势：数据库、服务需要满足向上兼容、向下兼容
测试面
测试的形式：测试用例文档、word编写专项测试方案
服务部署文档/升级文档内容：
项目背景
源码信息（代码分支信息、代码仓库路径）
改动点、影响面
部署流程
项目包拉取
数据库sql脚本
依赖项启动
启动配置项修改
执行方法（java -jar、go、sh、流水线执行）
回滚方案
测试关注点：历史数据能否在新版本下正常运行，新版本数据在服务回滚后是否能够在旧版本下正常运行，是否能根据开发所提供的升级文档实现版本迭代。
测试手段：
编写数据升级测试策略和具体的测试用例，并进行评审。
评估存在版本迭代需求，后端服务提测，测试可以开始介入进行数据升级测试。
前置准备好服务器搭建上一个版本的被测项目。
围绕测试用例构建历史数据。（用例前置）
根据开发提供的部署文档完成服务升级。（文档正确性）
验证历史数据是否能够向下兼容。（用例执行）
构建新版本的业务数据。（用例前置）
回滚策略校验。（文档正确性）
验证新版本业务数据是否能够向上兼容。（用例执行）
策略优先级：高
用例设计：
需要先提炼业务的核心数据类型，每种类型都需要针对性设计版本迭代的测试用例
历史数据能够在新版本正常使用：
注意：历史数据需要覆盖所有业务逻辑的数据
【前置】准备好历史版本的数据
【操作步骤】
用例1：在新版本，找到历史数据的业务查询入口，进行数据查询
用例2：在新版本，找到历史数据的业务更新入口，进行数据更新
用例3：在新版本，找到历史数据的业务删除入口，进行数据删除
【期望】
历史业务数据可以在新版本正常处理
新版本数据能够在历史版本正常使用：
注意：新版本数据需要覆盖所有业务逻辑的数据
【前置】准备好新版本版本的数据
【操作步骤】
用例1：在回滚到历史版本，找到数据的业务查询入口，进行新版本数据查询
用例2：在回滚到历史版本，找到数据的业务更新入口，进行新版本数据更新
用例3：在回滚到历史版本，找到数据的业务删除入口，进行新版本数据删除
【期望】
新版本业务数据可以在历史版本正常处理
