軟體測試人員的BUG論

小熊行走測試江湖多年，對於功能測試可謂是「一路看過千山和萬水」！到底什麼樣的才算測試中的老司機呢？小熊認為如果一個測試人員能夠及時有效的識別並捕捉到BUG， 並且定位，分析，重現的話，那他覺得是個歷害角色。你瞧，看似簡單的一個BUG ，其實包含著大學問呢，下面就讓小熊來嘚啵一下。

01

認識BUG

1、軟體人員之硬實力

首先測試人員要有識別BUG的能力，你要知道怎麼測，用什麼方法測試，標準是什麼。比如常見的界面測試，介面測試、流程測試等，就是所謂的測試人員硬實力。

就說界面測試吧，我們要知道頁面顯示的基本檢查點，比如，欄位大小和樣式是否一致 ，頁面的顯示列表表頭排序是否由主要到次要，顯示列表內容排序是否正確。欄位超長時，頁面是否變形的基本常識。

2、軟體人員之軟實力

良好的邏輯思維和領悟力，可以使測試人員快速的學習和領悟業務知識，然後形成自己的理解，否則流程測試時跟本銜接不上，搞不懂對錯，不斷的問開發，問其它測試，會導致測試的效率和質量都很低，並且別人對測試的印象也大打折扣。搞不好會讓人感覺測試是來添亂的。

如果軟實力和硬實力都很強，那麼測試人員對BUG的識別能力自然會提高。

02

捕捉BUG

1、熟悉業務和測試功能，按用例執行

測試前需要對測試業務和測試流程都了解，理解測試用例的目的，在測試過程中按標準（測試用例）測試，來不斷展開測試。有時小熊也會邊測邊補充測試用例，因為深入測試時，對業務最熟悉。容易會發現測試用例的疏漏。

2、要有一顆懷疑的心

測試人員 要有一顆懷疑的心，凡事都要確認過才相信，不能想當然。

有時候，也會遇到一些情況，感覺不太對勁，但是又不能立馬說出哪裡不對，遇到這種情況，一定要認真分析，不能放過。很多問題就是這樣被忽略了。其實你在仔細想一下，或者問一問，就會發現不妥，這樣一個BUG就被捉住了。

有時候開發人員和測試人員的意見不統一，被開發人員三言兩語的給說服了，兩個人默默的達成一致，然後把測試用例的預期結果就給更改了，然後，一個不該有的BUG就這樣華麗麗的產生了。。。

這是絕對不可取的，小熊是這麼做的，因為小熊所在項目測試用例都是要經過評審的，測試中如果測試的實際結果和預期結果確實不一致，測試人員要拿出專業水平來說服他，但若不能說服開發人員，那麼就找個相對權威的第三方再確認一下，當三個人分析後仍然不能統一意見的，那就找項目經理再確認。這樣才能保證不會放過一個BUG。

3、細心和耐心

無論測試工具多麼繁花似錦，手工測試還是不可避免的，所以測試用例執行一定要到位！

小朋友，請不要偷懶哦，所有偷過的懶在生產上都會被揭穿的，小熊堅信，生產是檢驗質量的唯一標準。

測試過程中，一旦發現問題，如果是頁面上的問題，一定要及時截圖，保留證據。然後下一步，就是要分析 ，定位啦~~

03

分析BUG

對於優秀的測試人員，一般發現問題時，首先去看看日誌，看看資料庫，然後分析一下這個問題是由什麼原因導致的，在什麼場景下出現的，如何重現這個問題，這個問題還可能會有哪些影響。這麼一來二去，你就成了一個分析專家，邏輯思維和業務能力都會在一次次分析中得到提升。

有時候，一個BUG琢磨好久，也想不通，那麼就可以先提出BUG，讓開發去解決。

切記！對於偶然的問題不確定是否能夠再現的，一定要保留現場，保留證據。

04

提出BUG

提BUG單時，要做到語言簡潔、表達清晰，首先把問題場景和問題現象說清楚。

對於流程測試，還需要把測試數據提供一下，我習慣提供測試SQL，為了方便開發分析和確認問題，小熊通常會保留錯誤數據現場，這樣開發看到BUG，很快就能定位，大大提升了解決問題的難度和速度。

小熊喜歡按下面的格式提出問題。尤其是BUG描述那段。

BUG主題：新增用戶頁面的用戶名已存在時，提示SQL錯誤

問題類型：界面問題

功能模塊：用戶管理

經辦人：XXX

BUG描述如下：

【測試步驟】：打開新增用戶頁面，用戶名處錄入已存在的用戶名test1,其要素正確錄入；

【預期結果】：新增失敗，頁面提示用戶test1已存在。

【實際結果】：新增失敗，頁面提示SQL錯誤。如附件截圖所示；

附件：上傳錯誤截圖

嘚啵這麼多，最後總結一下，就是測試人員要有很好的BUG識別、捕捉、分析、提出的能力。

相信你對BUG也有一套自己獨特的看法，歡迎留言交流哦~~

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