移动测试基础 一个升级 bug 问题探讨,如何从设计角度来避免问题发生。

OBJ · 2018年01月16日 · 最后由 rrrrzzz 回复于 2018年03月06日 · 2482 次阅读

1.问题现象:
某天,发布新版安卓版本后,一位重要级用户在使用过程中提示升级,点击升级后提示升级版本比当前版本过低。

2.问题原因确认:
A.一次数据库配置升级数据,配置的版本为 1.6 ,正确版本应该为 1.3 ;
B.安卓端下载存储的方式是:根据配置的版本号来存储,如数据库配置的版本是 1.6(接口请求返回),
则存储到安卓手机上的文件名称是:XXXX_1.6.APK , 大致这样一个规则生成的 ;
C.问题手机中因上上次升级中存储了安装文件 XXXX_1.6.APK(安装后未删除);导致实际版本为升级
1.6 过程中,安卓端下载逻辑判断,认为已经从服务端把最新的文件下载下来了,安装过程中实际
版本是比当前版本低,导致升级不成功;

3.我想到问题解决:
方法一:每次下载时候,判断本地是否有文件,有直接删除后,重新下载;
存在问题:客户体验不好。
方法二:核对版本信息的时候,服务端传递一个 md5 值,安装之前比较 md5 值是否符合,不符合,删除同
文件名后重新下载,符合则安装;
存在问题:逻辑判断稍复杂,计算 md5 可能影响性能,卡顿?

不知道大家对这种问题,从设计逻辑上怎么解决。

共收到 8 条回复 时间 点赞

其实版本号就是一个通用的标记,没必要为了运维可能出现的错误来复杂化。 因为即使使用了你提到的几种方法,也无法避免运维配置错误的问题。

楼主所说的设计,是指即使出现这类配置错误都能进行更新而不影响用户么?
md5 判断应该可行,不过存在问题是可能要比较一系列的 md5(如果版本升级频繁的话),可能会影响性能。设计上可以加个动画或者小进度(版本校验中...)之类的,毕竟版本升级一般用户也不会期望是一两秒就下载完成的。

从测试角度上,如果不做修改,可以加一个生产环境推送后进行一个版本升级和冒烟的自动回归,这样可以尽早发现配置或者发布时存在的问题而不是等到被 “重要” 用户遇到了被喷。。。
ps,貌似版本升级相关的测试经常容易被遗漏的说。。。

如果完全不用这种升级呢?全用商店的升级可行吗?类似于苹果的

OBJ #4 · 2018年02月01日 Author
rrrrzzz 回复

全用商店的体验不是很好哦

OBJ #5 · 2018年02月01日 Author
Roger 回复

我们是对这种进行了测试,只是没有去详细了解其升级原理详情(导致配错了,影响后面升级);测试过程中,没有完全保留以前的安装包

OBJ #6 · 2018年02月01日 Author
Jerry li 回复

要说服研发部门支持才行。

这样的问题 不是在发版前线上回归测试就可以发现吗?

OBJ 回复

我倒觉得商店升级体验很好 很烦一打开弹框的 安卓还会自动后台下载安装包

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册