弄清楚如何定位和分類bug之前，需要了解一個頁面的請求過程，以http請求為例： 1、使用者在前端頁面操作，如點選某個提交按鈕 2、頁面攜帶資料進行請求，訪問具體功能介面 3、由後端服務執行相應的業務邏輯，如涉及資料，再去請求並組裝資料返給前端 4、前端頁面進行渲染和展示對應的頁面和資料 前後端bug各有什麼特點？

前端bug特點 1， 介面相關 2，佈局相關 3，相容性相關

後端bug特點 1，業務邏輯相關 2，效能相關 3，資料相關 4，安全性相關

如何定位前後端bug

1、經驗法 軟體測試人員應不斷精進自己的技能，負責的專案多了，自然對功能的實現過程有了解，也就明白如何分類bug了。 例如： 網頁上的某個圖片的解析度不對，如果我們瞭解實現過程，可以想到一般情況下，是根據某個地址去伺服器取圖片的，資料庫一般只儲存地址，那麼圖片能正確顯示，就說明後端的基本功能是滿足需求的。如果具體圖片解析度有誤，最可能的原因是前端顯示過程出了差錯。

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

3、查介面 這種方法常用於檢視是後端返回給前端的資料有誤，還是前端顯示有誤。 大多數瀏覽器都有自帶的介面檢視工具，如Chrome，FireFox等都可以通過F12開啟抓包，在NetWork中可以看到當前頁面傳送的每個http請求。 我們需要對比通過後端介面拿到的資料和前端顯示的資料，來確認問題出在哪裡。如果資料錯了，頁面顯示是錯的，也是正常的，先從後端入手去解決。如果資料對了，但是顯示錯了，就需要問問前端的開發人員了。 溝通很重要 我們在定位BUG的過程中，最不能忽略的一個問題是和開發人員的溝通，有時候忙活半天，不如一問一答。經驗和技術的成長也都離不開合理高效的溝通。 經驗和小結 出現樣式的問題基本都是CSS的BUG 出現文字的問題基本上都是html的BUG 出現互動類的問題基本上都是Javascript的BUG 其他問題先溝通，再定位