前言前端
面試的時候每每容易被面試官問到:「說說你遇到過的比較重大或經典的Bug有哪些,能說一說嗎?」
我被問時腦海的反應是:「尼瑪,這個我歷來沒有刻意記!一時半會咋想得起來,而後仍是沒想起來或者是隨意給了一個並不符合指望的回覆」,各類不靠譜。
最近在測試過程當中默默然發現一個一直存在、但一直未被人發現的Bug,把它記錄起來吧!面試
背景後端
咱們有金卡服務,針對VIP付費用戶。
開通金卡服務後,經理人的簡歷在被獵頭或企業搜索到時,經理人頁面會統計「簡歷被搜索到:*次」,搜索到時次數會+1,統計的數據依據由前端發給後端。測試
發現spa
在某次上線測試過程當中發現,獵頭或企業搜索到個人簡歷後,個人被搜索到次數並無增長。
同時,經過查詢數據發現:最近5天之內開通金卡的經理人,他們的簡歷竟然沒有被任何獵頭和企業搜索到,但開通6天以上的經理人有零星的被人搜索到。
到這裏,仍然沒法解釋形成這種現象的緣由是什麼,最後,經過檢查代碼發現,發現……搜索
緣由簡歷
發現,前端向平臺發送的數據是錯誤的。
平臺在有一次上線中,將統計簡歷搜索次數的參數由「簡歷ID」變成了「用戶ID」,而獵頭或企業搜索到相關簡歷時,前端向平臺發送的數據仍然是「簡歷ID」而不是「用戶ID」。
這樣作經過代碼檢查是沒法看出錯誤的,由於用戶ID和簡歷ID都是由一串數字組成且長度都同一區間內,因此程序處理十分正常。
同時因爲二者有許多重疊的ID,就出現了咱們看到的開通6天以上的經理人會零星有被獵頭或企業搜索到。數據類型
總結程序
這個問題之因此存在並長時間未被發現,有如下幾個問題:
# 底層平臺改動後,對於其影響的區域未能準肯定位、修改、測試,致使部分數據處理不正確
# 功能項長時間未改動,同時迴歸測試未能覆蓋,致使出現問題時,沒法被發現
# 這個問題最特殊、最可怕的不是他們的數據類型一致,而是他們有大部分數據是相同的(使得問題沒法暴露)統計