1.旧版本升级到新版本，这种无话可说。
2.安卓研发要求测试【新版本】的升级功能，担心新发布的版本在下次迭代不能升级了。
测试圈的同学，遇到过这样的问题吗？
测试圈的同学谈谈你们公司 app 升级测试覆盖度是怎么做的，请各抒己见
一般升级测试主要是：
1.不跨版本 0.1 到 0.2 做测试 (包括已登陆未登录 已登陆要看数据保留)
2.跨版本 0.1 到 0.3 中间有 0.2 升级看是不是提示 0.3 而不是先 0.2 再 0.3
第二个维度
3.强制更新
4.非强制
和 1.2 这两点就是交叉的 例如 0.1 强制 0.2 而非强制 0.3 要看提示 安装 0.2 的版本再看提示
如果版本稳定 升级一般就不用看了
如果升级模块有改动 就需要让开发在上线的这个版本 再打一个高版本 要验证马上上线的版本升级没有问题 不然上线了以后下次升不了 就完蛋套了
建议你们公司讨论评审是否需要啊专门做 App 的升级特性测试
看是否之前有相关升级的问题
多数公司会在灰度环境进行一下升级验证，保证新老数据兼容，可以正常登陆就好。
如果评审以后有升级特性的专项测试，
- 升级、卸载和更新，以及对应的方式、检查和基本操作
- 版本升级树（对应的版本配套表，是否支持间隔多个版本一步升级到位）
- 升级场景的备选流覆盖
如果升级模块有优化，新版本是需要测试升级的，做法是打个更高版本的包
一般升级测试主要是：
1.不跨版本 0.1 到 0.2 做测试 (包括已登陆未登录 已登陆要看数据保留)
2.跨版本 0.1 到 0.3 中间有 0.2 升级看是不是提示 0.3 而不是先 0.2 再 0.3
第二个维度
3.强制更新
4.非强制
和 1.2 这两点就是交叉的 例如 0.1 强制 0.2 而非强制 0.3 要看提示 安装 0.2 的版本再看提示
如果版本稳定 升级一般就不用看了
如果升级模块有改动 就需要让开发在上线的这个版本 再打一个高版本 要验证马上上线的版本升级没有问题 不然上线了以后下次升不了 就完蛋套了
我理解 APP 升级有 2 种情况，以安卓为例：
- 热更新（云更）
- 旧版本覆盖安装
我们基本上都是通过提高版本号来测试升级功能，包括云更和 APP 主版本更新
增量覆盖率