朋友講了個案例
組內有一位成員發現線上缺陷非常高興，指着其他組員說，你們怎麼測試的，這麼簡單的問題都漏了。（聲明這位組員不是leader，即便是也有問題，原則上來說用“你們”已經劃清了界線。）然後讓這位組員參與排查問題，得到的答覆是：我只參與提問，你們去查。
現象：測試環境沒問題，生產就出問題了。
測試環境認真走查過沒問題，到了預發佈時，耗時跟進一個嚴重bug，導致時間不足以迴歸其他用例，所以這個功能沒有覆蓋，到了線上就出問題。
本質：爲什麼同一套代碼，兩個環境不一致？
經過日誌排查，發現測試環境的日誌顯示正常，到了預發佈環境，少了一些參數，可以推斷是由於代碼不一致導致的。代碼不一致的話，那肯定是修改了代碼，研發同學不會偷偷提交無效代碼的，要有這個基本信任，拿到版本庫日誌對比就水落石出了。
教訓是什麼？
測試用例不可能窮舉，在有限的時間內完成關鍵用例的測試，則質量程度在研發、測試認可接受範圍內。
研發測試過程中反覆測試一輪是沒有問題的，bug修復後，在預發佈環境，需要將核心用例都走一遍，這個是保本所需，不能放鬆，測試同學也有責任，在這個環節是否嚴格遵守，排除測試組裏面的害羣之馬去認真面對、分析，對測試、研發提出質疑，上線發佈環境，不容許半點質量的放鬆，迴歸用例的集合是一根救命稻草，要狠狠抓住，如果錯過了，更多是測試沒有堅持質量原則。
另外，即將上線發佈前的封包時間也很關鍵，團隊究竟認可什麼時候封包，封包之後的致命bug修復，如何再次合併代碼，這些代碼是否經過嚴格代碼審查以及說明影響範圍，否則還是會被一個魔咒困擾：修復bug的同時會引入新問題。
再想想
一邊吐槽坑爹之人，一邊還是要接受事實：這鍋還是要背。的確在預發佈環節，用例迴歸上掉以輕心了，不可否認。另外，要能夠快速定位問題和取證，通過日誌、版本信息，回放當時問題所在，讓開發、測試同學活的明明白白。