这两天被手淘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中收集用户的评论。
总之，一个问题，越早被“自己人”发现，就能将风险降到最低，影响降到最小。
### 写在最后
瓜吃完了，不知道你有没有什么想法或者感受？可以在评论区留言，或者去知识星球「测试开发技术圈」（目前限时免费开放中）进行交流。
