這兩天被手淘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中收集用戶的評論。
總之，一個問題，越早被“自己人”發現，就能將風險降到最低，影響降到最小。
寫在最后
瓜吃完了，不知道你有沒有什么想法或者感受？可以在評論區留言，或者去知識星球「測試開發技術圈」（目前限時免費開放中）進行交流。