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都層出不窮，以后的測試工作中，恐怕也要讓自己的測試思維和測試方法不斷與時俱進了！