如何判定一個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.測試環境