組內有一位成員發現線上缺陷非常高興，指著其他組員說，你們怎麽測試的，這麽簡單的問題都漏了。（聲明這位組員不是leader，即便是也有問題，原則上來說用“你們”已經劃清了界線。）然後讓這位組員參與排查問題，得到的答復是：我只參與提問，你們去查。

現象：測試環境沒問題，生產就出問題了。

測試環境認真走查過沒問題，到了預發布時，耗時跟進一個嚴重bug，導致時間不足以回歸其他用例，所以這個功能沒有覆蓋，到了線上就出問題。

本質：為什麽同一套代碼，兩個環境不一致？

經過日誌排查，發現測試環境的日誌顯示正常，到了預發布環境，少了一些參數，可以推斷是由於代碼不一致導致的。代碼不一致的話，那肯定是修改了代碼，研發同學不會偷偷提交無效代碼的，要有這個基本信任，拿到版本庫日誌對比就水落石出了。

教訓是什麽？

測試用例不可能窮舉，在有限的時間內完成關鍵用例的測試，則質量程度在研發、測試認可接受範圍內。

研發測試過程中反復測試一輪是沒有問題的，bug修復後，在預發布環境，需要將核心用例都走一遍，這個是保本所需，不能放松，測試同學也有責任，在這個環節是否嚴格遵守，排除測試組裏面的害群之馬去認真面對、分析，對測試、研發提出質疑，上線發布環境，不容許半點質量的放松，回歸用例的集合是一根救命稻草，要狠狠抓住，如果錯過了，更多是測試沒有堅持質量原則。

另外，即將上線發布前的封包時間也很關鍵，團隊究竟認可什麽時候封包，封包之後的致命bug修復，如何再次合並代碼，這些代碼是否經過嚴格代碼審查以及說明影響範圍，否則還是會被一個魔咒困擾：修復bug的同時會引入新問題。

再想想

一邊吐槽坑爹之人，一邊還是要接受事實：這鍋還是要背。的確在預發布環節，用例回歸上掉以輕心了，不可否認。另外，要能夠快速定位問題和取證，通過日誌、版本信息，回放當時問題所在，讓開發、測試同學活的明明白白。

測試背黑鍋姿勢