关于手机淘宝3.25bug我的一些思考与建议

2019/04/10 10:10
阅读数 22

这两天被手淘ios版3.25bug刷屏了,影响还是挺大的,仅3.25日当天截止到下午5点在微博上的话题阅读量,已经突破8000万。给广大网友带来一次吃瓜盛宴。我们先简单回顾下这个bug的故事线:

  • 我查看手机淘宝在App Store的更新记录,3.20号发布了一个版本。应该是针对淘宝直播更新的版本。
  • 3.25号凌晨,开始有用户碰到手淘启动后,在页面停留10s钟,会弹出一个弹框“您使用的程序是内测版本,目前已经过期,请更新到最新版本”。
  • 3.25号上午,打开手淘还是能复现,但是弹框会秒消失。推测阿里的工程师,应该使用了IOS热修复技术,但是热修复并不能让弹框消失,只能将弹框隐藏,因此大家会看到弹框秒消失。(热修复,只需要服务端下发一个patch包,然后手淘重启,patch包代码即可生效)。
  • 3.25号16点(通过淘宝官方微博推断的时间),手淘又更新了一个版本,解决弹窗的问题。苹果提供了一个机制,假如上传到App Store的包有明显缺陷,可以撤回,并且替换一个新的包。这个新包的审核速度会非常快。
  • 所以大家现在去App Store上看手淘的发版记录,可以看到一周前发布一个版本,两天前发布一个版本。(写这篇文章时是3.27号)。

至于问题的原因,我不敢妄加揣测,我只能说,3.20号发布了包,但是3.25号突然才出现问题,留给大家的想象空间还是很足的。这里我想来跟大家聊聊,通过这个事件,有哪些我们作为软件测试工程师可以反思的点,避免我们踩同样的坑。

在之前文章中,表达过我的观点:任何线上问题,一定是流程存在漏洞,而不能单纯说是某个人的问题。所以接下来也主要从流程上进行反思。

代码review

我觉得代码review应该有两道防线,第一道防线是推动研发流程中,开发做好代码review。比如某同学A修改了部分代码,那么需要同学B和同学C两个人帮他review代码,并且同学A在提交代码时,要附上谁帮他review代码,领导才允许合并代码。我之前在手淘时,貌似只有发版前修改bug,才有这样的代码review机制。不过,review代码费时、费精力,需要结合公司情况来推动。

第二道防线是我们测试工程师,这要求你有一定的代码基础,你可以不会写代码,但是可以尝试能看懂开发的代码。这个颗粒度可以调节,比如:当你能力还达不到看懂代码时,可以看开发本次提交了哪些文件?有没有不相关的文件;当你有阅读代码的能力时,可以看代码是新增的,还是在原来基础上改的,改动大不大等等。不过,这加重了测试同学的工作压力,后续可以结合精准测试来挖掘每次开发改代码的测试点。

敬畏线上包

我们团队之前也碰到过非常低级但是影响很大的bug,比如有一次将一个测试的升级框发到了线上,造成了用户的大面积投诉。从那时起,团队内部就有了一个行动指南:敬畏线上包

所有发布到线上的包,必然是要经过测试工程师的验证和测试,Android可以直接通过apk安装,但是IOS相对麻烦一些,需要用到testflight,但也是可以验证的。

这样,会很大程度的降低一些非常低级的问题跑到线上的风险。

回归用例库需要不断更新迭代

我觉得多数公司,应该都有自己每次发版上线前的必然要回归的用例库,比如,我们之前团队的发版回归用例有:安装、卸载、升级、各个主页面场景等。

所谓,“一年被蛇咬,十年怕井绳”,比如:这次手机淘宝碰到了时间变化造成的严重bug,那我觉得完全可以将时间维度的变化(比如:一周、一个月、一年)加入到回归用例库,来避免同类的问题再次出现。

所以我觉得,回归用例库只有不断更新迭代,才能不断的完善和提升产品的质量。

舆情监控是产品的体检表

我是特别建议软件测试工程师,在产品发版之后,能从各个渠道了解下用户的反馈。因为这是第一手的资料,能反馈产品从质量到交互设计方方面面的信息。

在手淘,它们有自己完善的舆情监控平台,可以从微博、app反馈等多个渠道收集用户的反馈信息。假如一般的公司没有这样的平台,可以手动去微博搜索、或者去App Store中收集用户的评论。

总之,一个问题,越早被“自己人”发现,就能将风险降到最低,影响降到最小。

写在最后

瓜吃完了,不知道你有没有什么想法或者感受?可以在评论区留言,或者去知识星球「测试开发技术圈」(目前限时免费开放中)进行交流。

原文出处:https://www.cnblogs.com/zhouliweiblog/p/12588560.html

展开阅读全文
ios
打赏
0
0 收藏
分享
加载中
更多评论
打赏
0 评论
0 收藏
0
分享
返回顶部
顶部