如何判定一個bug是前端bug還是後端bug

首先需要了解一個頁面的請求過程：

以http請求為例：

1、使用者在前端頁面操作，如點選某個提交按鈕

2、頁面攜帶資料進行請求，訪問具體功能介面

3、由後端服務執行相應的業務邏輯，如涉及資料，再去請求並組裝資料返給前端

4、前端頁面進行渲染和展示對應的頁面和資料

前後端bug各有什麼特點？

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

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

一、前端問題

1、介面相關

常見的介面相關問題有：排版錯亂、文字錯誤、資料錯誤、相容性問題

文字錯誤的問題又包含功能文字及提示文字，功能文字即對話方塊或彈框中的標題文字；提示文字即前端給出的文案提示；

資料錯誤的問題又包含列表欄位錯誤、表單欄位錯誤等，這種情況下可以檢視前端是否參與計算，或是有無進行過欄位配置管理，一般情況下可以先提交給前端；

瀏覽器相容問題比較常見，如果使用了UI框架 ，則前端問題常見於框架問題。

2、功能相關

功能相關的又包含功能實現錯誤或不完整以及邏輯錯誤等。

功能問題可以通過抓包檢視請求的方式來初步判斷，如無請求，則初步判斷為前端Bug；若抓包中有請求，則可以通過不同的狀態碼來判斷，有請求的情況下可以初步判斷為後端Bug

邏輯錯誤問題需要與開發人員溝通確認

3、效能相關

常見的問題如頁面開啟較慢，表單開啟慢等，一般情況下可以通過抓包來檢視請求，如果請求耗時較小，則初步斷定為前端問題；否則可以結合其他資訊排查為後端問題。另外，效能相關的問題出現後建議通過工具來評估整體的效能，可以進一步定位是哪個部分的問題。

二、後端問題

通常後端問題常見於業務邏輯、資料問題以及安全相關的問題與效能問題

如果前端功能實現導致後端返回的資料出錯，則可以初步判斷為前端問題；但如果檢視後端返回的介面資料不一致或是出現報錯資訊，則判斷為後端問題；

另外，後端問題多數可以通過查詢錯誤日誌資訊來排查原因，若沒有輸出日誌，則可能為前端問題；不存在互動的情況下更多偏向於前端問題。有些資訊不會展示在前臺，需要結合服務端日誌資訊一起排查定位了。在定位的過程中可以記錄下相關SQL的問題，服務端的問題以及程式碼問題，以便於日後檢視。

1、經驗法

例如： 網頁上的某個圖片的解析度不對，如果我們瞭解實現過程，可以想到一般情況下，是根據某個地址去伺服器取圖片的，資料庫一般只儲存地址，那麼圖片能正確顯示，就說明後端的基本功能是滿足需求的。如果具體圖片解析度有誤，最可能的原因是前端顯示過程出了差錯。

2、查日誌

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

3、查介面

這種方法常用於檢視是後端返回給前端的資料有誤，還是前端顯示有誤。 大多數瀏覽器都有自帶的介面檢視工具，如Chrome，FireFox等都可以通過F12開啟抓包，在NetWork中可以看到當前頁面傳送的每個http請求。 我們需要對比通過後端介面拿到的資料和前端顯示的資料，來確認問題出在哪裡。如果資料錯了，頁面顯示是錯的，也是正常的，先從後端入手去解決。

測試用例的內容

1.用例編號（命名）

2.所屬模組

3.用例標題（某人在某種情況下做了什麼，得到什麼結果）

4.優先順序

5.前置條件

6.操作步驟

7.測試資料

8.預期結果

9.實際結果

10.輔助內容

a、通過與否
b、bugid
c、編寫人員
d、編寫時間
d、測試人員測試時間
e、備註

缺陷的嚴重程度

1.嚴重
2.一般
3.次要
4.輕微

缺陷報告的核心要素

1.缺陷編號

2.缺陷狀態

3.缺陷標題

4.重現步驟

5.嚴重程度

6.優先順序

7.缺陷型別

8.測試環境