GeneralUpdate自动升级测试
GeneralUpdate自动升级测试
1.概要
在企业产品发布到市场之前需要对功能进行测试，在大部分公司里自动升级功能不像产品功能一样有需求文档或者业务说明等文档。通常的要求就是能正常升级公司产品或能增量更新节约流量即可。这时候对测试经验不足的人员来说测试不充分或者大家都没有考虑到将会造成很多麻烦。（这里只是提供一种测试的思路，并非专业测试指导请辩证看待）
GeneralUpdate开源项目地址和介绍：
- https://gitee.com/GeneralLibrary/GeneralUpdate
收集问题的地址：
- https://gitee.com/GeneralLibrary/GeneralUpdate/issues/I7N3VA
- https://github.com/GeneralLibrary/GeneralUpdate/issues/9
2.详细内容
1.测试版本升级顺序
假设市场上所有的客户现在使用的程序版本是v1.0.0.0，我们即将发布v2.0.0.0。在发布之前就需要在测试环境中将两个版本升级测试一下。
- 下载更新包时
- 正在更新文件时
- 强制中断程序运行、断网、直接断电、模拟弱网、模拟崩溃等
2.加密文件无法升级
在GeneralUpdate中在两个版本中提取二进制差分更新补丁文件时，会出现加密文件无法被差分算法识别的情况这个时候需要考虑在生成差分补丁包时，将加密过的文件加入到（SetBlacklist）黑名单中或者考虑直接覆盖（直接打在压缩包里）。
3.失败回滚或者重新升级？
这方面也是企业中大家最在意的一点，自动升级虽然能带来诸多好处。但是升级失败会直接导致客户端根本没法使用这是非常致命的，后续我会考虑在GeneralUpdate中新增两种策略来解决这个问题。
- 策略一
升级之前将需要被更新的文件或目录进行备份，如果更新失败第二次启动则会将备份文件还原至原来的目录，并关闭自动升级的开关以防止文件还原之后再次进行自动升级。
- 策略二
这个是我内心中比较推荐的升级方式，因为自动升级程序的意义就是升级而不是回滚。目前初步的想法是新增遗言机制。为解决在更新时遇到异常情况，导致文件损坏更新的问题。1.每次更新完成，需返回给服务器更新状态。如果客户端在30分钟内没有任何反馈则判定为毁坏性更新失败。（文件损坏）2.升级程序每次启动时会读取上一次更新的遗言，如果上次更新为失败自动化下载、安装客户端安装包（压缩包）3.或者新增更新守护进程接收实时推送自动化下载、安装客户端安装包（压缩包）
4.项目结构调整
如果开发人员对项目结构发生了一些结构性质的修改。例如基于IoC思想搭建的客户端程序，例如Prism框架如果开发人员把其中的一个Module更换了文件夹的位置或者文件夹名称修改了，导致用户的客户端更新了之后IoC容器启动之后找不到该DLL的异常情况。更新时需要考虑到文件路径变化的问题。测试人员也有责任例行询问是否有该种类的变化。
5.作为最后闭环流程再测试
这个事项是非常需要注意的，如果前面就把自动升级先测试了。如果后续有bug修复或者其他变动都有可能会造成未知的异常情况出现。所以作为最后的闭环流程进行测试是比较推荐的（如有特殊情况按需要调整即可）。
6.弱网环境测试
弱网环境模拟可以借助NetLimiter和Clumsy来进行测试，具体使用方法可以参考我的这篇文章。
7.灰度发布
版本发布之前就需要做好测试。
- 如果面对的客户群体庞大则需要小范围的灰度发布，如果没有问题再选择发布给市场上所有客户。
- 如果是灰度升级版本，这个时候就不要设置为强制更新的版本了。让用户自己选择是否升级。
8.精准升级
在GeneralUpdate中目前已有的基于Signal R接收推送最新版本更新的方式。假设在市场上有很多客户，每个客户有很多台设备。那么其中客户A有10台电脑，只有其中一台电脑因为硬件或者软件环境出现了问题导致客户端的功能异常。这个时候需要紧急针对该台设备的情况进行修复，这个时候并不清楚这个修改会不会对现在已经正常运行的客户端程序有影响。这个时候可以考虑使用一对一的升级方式精准升级某台出问题的电脑。
9.老配置兼容新版本
在市场上如果存在各个分支的版本时，每次自动更新升级还需要考虑到本地配置文件的问题。如果升级到新版本的程序之后需要读配置文件这个时候，老版本的配置文件兼容不了也会造成问题。这个时候测试人员也需要注意该种场景。
规避这种问题的方式可以把大部分容易变动的配置放到服务端每次登录的时候去读取。把不容易变化的配置保存到本地。
10.自动化测试
自动升级的自动测试化测试的脚本编写也非常重要，在多分支、多版本的升级测试中节省时间,增加测试的准确性。
腾讯云开发者
