測試背黑鍋姿式

朋友講了個案例

組內有一位成員發現線上缺陷很是高興，指着其餘組員說，大家怎麼測試的，這麼簡單的問題都漏了。（聲明這位組員不是leader，即使是也有問題，原則上來講用「大家」已經劃清了界線。）而後讓這位組員參與排查問題，獲得的答覆是：我只參與提問，大家去查。

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

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

本質：爲何同一套代碼，兩個環境不一致？

通過日誌排查，發現測試環境的日誌顯示正常，到了預發佈環境，少了一些參數，能夠推斷是因爲代碼不一致致使的。代碼不一致的話，那確定是修改了代碼，研發同窗不會偷偷提交無效代碼的，要有這個基本信任，拿到版本庫日誌對比就水落石出了。

教訓是什麼？

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

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

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

再想一想

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