測試人員如何看待偶現Bug

測試人員如何看待偶現Bug

無論開發還是測試，最頭疼的就是偶現Bug。找不到復現規律，自然也找不到修復的手段。對於測試人員應該怎麼看待偶現Bug呢？

筆者認為，在軟體領域，並沒有偶現Bug，所謂偶現只是沒有找到復現規律而已。所以當測試中遇到感覺是偶現Bug時，一定要做到「竭盡所能」的去找復現規律。如果測試人員能夠找到Bug的復現規律，問題已經解決一半了。

筆者曾經處理過一個Bug，實際是其他測試人員提出的現場測試問題，Bug現象是電路相關的交叉信息會莫名其妙的丟失，丟失只在上層軟體，而實際業務沒有影響。由於一直以來對偶現Bug都比較有興趣，筆者在復現時就著重分析了下，不過問題不會因為你努力就會解決，結果就是你越去復現就越找不到規律。過了幾天，配置其他業務時，忽然出現了該現象。於是筆者拚命回憶之前做的操作，多次嘗試，發現時只要配置了其他板卡的業務基礎配置，就會出現該問題。趕緊聯繫開發，最後定位是資料庫更新腳本的「like」語句寫的有問題，更新「1%」會把1槽位、11槽位、12槽位等等都會更新，結果就會影響其他板卡的電路交叉。

從這個Bug之後，筆者更堅信了沒有真正「偶現」Bug，測試人員在發現Bug之後，找到Bug復現規律是很有意義，也很有挑戰的工作，不亞於開發對程序進行調試。

首先，從戰略上不能認可「偶現」的存在，有信心、決心和耐心尋找復現規律。

第二，現象出現後，要仔細回憶所有可能的操作，不要放過任何可疑的配置過程。

第三，根據回憶的過程，儘可能多的進行嘗試，去除無用的操作，找到其中的規律。有些偶現Bug非常噁心，只有第一次配置才會出現，這需要測試人員有想像力，有耐心。這個過程可能是反反覆復很多次的嘗試，也不一定有結果，需要測試人員「不拋棄，不放棄」。

第四，與開發人員討論，給出從代碼層次的建議，之後進行驗證。需要注意的是，開發同學說的也不一定全對，倒不是故意說錯，畢竟系統複雜，模塊間互相影響，只有實踐才是硬道理。

一個偶現Bug，對項目是很有價值的。曾經有一個項目經理和我說過一句話「我們不怕必現的Bug，就怕偶發的，因為不知道怎麼修復。」換句話說，如果找到必現規律，代碼上總會有各種方法進行解決，實在不行可以用「If-Else」搞定。所以，偶現Bug對於項目是很寶貴的財富。

對於個人而言，偶現Bug的定位對測試人員的能力提升非常有幫助，需要強大的記憶力，模塊間的聯想能力，排除無用因素的能力。可以說，一個偶現Bug如果能最終找到復現規律，會讓測試人員對相關的模塊、開發技術都有更深的認識。而把找規律養成習慣，形成自己的方法論，是職業素養的提高，更是測試技術的升華。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！