3月25日，阿里的淘宝APP在IOS系统上出现BUG：
在打开淘宝APP以后，用户就会收到系统弹窗通知：“您使用的程序是测试/内测版本，将于当地时间2020-03-28到期，到期后将无法使用，请尽快下载最新版本。”
而且，很多网友发现，把手机时间设置为3月28日18时后，淘宝APP仍然会弹跳出一个页面，并提示“您使用的程序是测试内测版本，目前已经过期，请更新到最新版本”。点击确认后，APP会自动闪退，用户无法浏览淘宝页面。
这也就意味着，如果到28号仍然无法修复这个bug，淘宝这个APP将不能再被使用了！所以，事故的严重级别大家应该不言而喻了！
事故发生后，有ios用户声称，在3月24日上午，她登陆淘宝时就发现有该提示，当时她误以为自己的APP版本是测试版，本来准备到应用商店更新至最新版本，结果却发现：她使用的版本就是最新版本。
所以，像该用户的操作也是普遍常规用户的操作思维，因此，此事故让淘宝的卸载率直线上升！！据可靠消息称，APP的卸载率也是被纳入员工绩效考核的一个重要标准，所以，淘宝为此做了紧急处理了：于是用户发现，后来打开淘宝发现了在1s~2s内弹出该提示信息，然后提示框瞬间消失。也就是只能将就着先让它出来，然后给他加一行代码让他快点消失，治标不治本，只是为了从某种程度上减少淘宝APP的卸载量而已。
所以，不管是从事故严重程度，还是从修复的难易程度上来看，这个事故在阿里都属于S1级别，bug级别属于阿里最高P0级别！！！
那么，阿里淘宝如此严重的bug，到底是谁的锅呢？
测试的锅？
可能大家一看到线上bug，自然第一想到的就是测试的锅！没办法，谁让测试是质量的把关者呢？专业背锅几十年，也习惯了。但是，这个事故真的是测试的责任么？
从苹果商店的更新历史可以发现，这个有问题的APP版本（9.5.7）是一周前发布的。
也就是发布之后的一周内都没有问题任何问题，然后代码里有一个“定时器”，到了“3.25”这个日子，就弹出这个alert消息。
所以如果从测试方面找原因的话，测试也是比较委屈的。毕竟任何一个测试也很难想到要去设计用例检查手机的时间并且是遍历今后的每一天吧？万一代码设置的定时器是特定的某个小时、特定的某分钟，再给我100万个测试人员也无法完成的任务。
所以这个锅测试背的是有点冤的！！
开发的锅？运维的锅？
从bug现象来看，比较直观的判断应该是发布的版本不对。 发到苹果商店的应该是正式版本，这个弹框提示信息来看是内部测试版本。
我们从项目流程上来分析一下：
首先，开发编写完代码后提测一个内部版本，测试就是在该内部版本上进行测试，保证功能和非功能的需求都被满足了之后，测试出测试报告告知可以上线了；
然后，由开发将测试版本重新打包为正式版本，基本代码是不再修改的，只是重新换个版本号，不再是内侧版本，而是正式发布的版本号。
最后就是上线了。负责上线的有些公司是开发人员，有些公司是运维人员。
所以，如果真的是发错版本这种低级错误，基本就是开发或者运维人员的责任了！不过，如果不是故意而为之，那么相关的开发或运维人员也太不专业了，这个锅背的一点都不委屈！
对考核制度的报复性行为？
当然，在BUG出现后，坊间有消息称，今天是3月25日，而在阿里有一个潜规则——绩效被打3.25分意味着公司冷处理，连年终奖都拿不到了。因此怀疑是之前的iOS端开发工作人员因为被打了3.25的绩效分数，报复性留下的隐患。那么有意给代码里埋一个“定时雷”，那也是防不胜防，所以很多网友笑称“得罪谁也别得罪开发！”。当然，这个传言被淘宝官微辟谣了：“大家连接WiFi，更新手机淘宝到最新版就好了。”对于上述坊间说法，淘宝官微并没有给出其他解释，仅在网传图片上打上了“纯属谣言”。
不过也不得不佩服淘宝的紧急处理能力，在3.25号8点左右更新了一版本（9.5.15版本），更新后已经解决了这个问题。
后话
这个事故在互联网行业也算起引起了不小的轰动，bug的具体根本原因恐怕也只有淘宝自己知道了，不过可以肯定的是，淘宝整个项目团队相关的人员，肯定都需要为这个事故付出一定的代价。
作为测试从业者除了吃瓜之外，也不禁心里一阵唏嘘。淘宝如此大的团队，都各种新奇bug都层出不穷，以后的测试工作中，恐怕也要让自己的测试思维和测试方法不断与时俱进了！
原文地址：https://www.cnblogs.com/tricy-nmb/p/12573873.html