測試如何判斷是前端的bug還是後端的bug

  軟件測試工程師的職責是發現BUG，此外，如何體現個人價值？那麼我們試想，只提出問題而不去解決，問題就永遠得不到閉環。所以，一個資深的測試人員的基本功應該是這樣的：深挖業務和功能需求，找出BUG，定位BUG，提出解決方案。這裏我們就來說說，當我們找到了BUG，應該把BUG提交給誰去解決，這屬於BUG定位的問題。

一.爲什麼要區分前端/後端BUG？

  如果是一個多人開發的系統，不能明確定位到這個bug是誰造成的，容易提交給錯誤的開發人員，我們又不可能把這些bug同時提交給前端和後端一起去解決，同時提交給前後端開發人員，每個人都會有依賴心理，就像我們在家裏一樣，兄弟姐妹多的，幹家務活總會想着給對方做，一樣的道理。bug會像皮球一樣被開發踢來踢去，耽誤開發解決bug的時間。

  另外，如果團隊規模較大，或者由各地的項目組拼湊而成，勢必會增加溝通成本，這更需要我們在類似禪道或者Jira等項目管理軟件中提交bug時，先指明是誰的bug，避免互相踢皮球的現象。

  所以測試必須要自己學會區分出是前端還是後端bug，就好像時下流行的詞“垃圾分類”，經過bug分類處理，整個團隊的效率都會有所提高。

  但說實話，能真正區分並準確判斷是什麼錯誤需要很有經驗的測試，並且也需要測試懂開發技能。目前我這方面能力真的欠缺，我也需要加油~。雖然初級中級的測試不能做到完美區分所有bug，但一定要學會簡單的區分bug的能力。

  所以，爲了提高團隊效率，測試人員尤其要做好bug分類。在測試過程中，如何判斷是前端的bug還是後端的bug？

二.如何定位前端/後端BUG?

通常可以利用抓包工具來進行分析。可以從三個方面進行分析：請求接口，傳參，響應。

1. 請求接口url是否正確

如果請求的接口url錯誤，爲前端的bug

2. 傳參是否正確

如果傳參不正確，爲前端的bug

3. 請求接口url和傳參都正確，查看響應是否正確

如果響應內容不正確，爲後端bug

4. 也可以在瀏覽器控制檯輸入js代碼調試進行分析

如果定位爲後端的bug，可以進一步通過以下方法精確定位是哪裏出bug

1. 查看報錯日誌，通過日誌分析問題點

2. 查看數據庫確認數據的正確性

3. 查看緩存是否正確

前後端BUG各有什麼樣的特點？

前端BUG	後端BUG
界面相關	業務邏輯相關
佈局相關	性能相關
兼容性相關	數據相關
交互相關	安全性相關

定位BUG屬於前端還是後端，有什麼方法？

這裏提供了幾個方法，可以給大家一個思路，讓大家能在學習和工作中瞭解如何去區分BUG屬於前端還是後端。

接口查看法

這種方法是最常用的，我們必須掌握的，常用於查看是後端返回給前端的數據有誤，還是前端顯示有誤。

大多數瀏覽器都有自帶的接口查看工具，如Chrome，FireFox等都可以通過F12開啓抓包，在NetWork中可以看到當前頁面發送的每個http請求。要想通過接口查看法來判斷，你需要先了解Chrome瀏覽器的Network面板介紹。

日誌查看法

當我們發現一個bug，並不確定這個bug屬於前端還是後端，可以查看後端服務的日誌，復現bug時，查看日誌中有沒有相關信息。基本可以認爲，如果日誌沒有輸出，很可能這個功能並沒有與後端交互，也就不存在後端的問題。反之，如果日誌有輸出，可以進一步查看有無錯誤日誌信息，進一步分析。

經驗法

經驗法就只能是慢慢積累了。負責的項目多了，自然對功能的實現過程有了解，也就明白如何分類bug了。在平常的工作和實踐中慢慢總結，不要只是一味的點點點測測測，總結覆盤很重要。