1. F12下如何查看bug屬於前端還是後端
一般前後端的數據流程是，前端組裝數據向後端發起請求，後端進行處理返回響應數據給前端，前端對響應數據前端效果展示。
可以分析是在哪個節點引發的Bug，從而判斷是前端還是後端問題。
比如，前端發送請求是，數據組裝有問題，導致後端返回報錯，這個是屬於前端問題。
而如果前端發送請求數據沒問題，後端返回數據不對或者報錯，可以判斷為後端問題。
2. 怎樣判斷是前端bug還是後端bug
這種情況下，但凡出問題，一般都是後端開發的問題。因為前端只處理用戶體驗、排版、樣式等。
現在前後端分離的技術越來越成熟，加上App、小程序等多種類型的前端，前端不僅僅是樣式了尺桐，界面上的數據顯示和處理都會由前端人員去完成。而後端開發專注於介面，前後端之間通過介面（協議）傳遞鏈孝數據。
那麼如果你在測試的時候，發現界面上的數據錯誤。這時候你去找前端，前端就會告訴你是後端的問題（有時候bug都不會看#手陵喚坦動捂臉(*/ω＼*)）；你去找後端吧，後端又告訴，這是前端的問題。於是你站在中間，一臉懵逼！
這時候就是抓包工具啦，通過抓包工具分析介面傳遞的數據，如果介面返回的數據是正確的（參考需求和介面文檔），那麼就可能是前端顯示的問題了，這時候後端至少是無辜的。
3. fiddler怎麼定位前端bug還是後端bug
1.發現bug之後，重現bug的時候使用fiddler抓包去分析
2.如果前端提交的數據在fiddler中顯示有誤，那麼就是前端的bug
3.如果在前端提交的數據在fiddler中顯示無誤，那麼就是後台的bug
4.除了fiddler等抓包工具外，還可以通過後台的日誌去判斷
4. 測試人員如何判斷是前端的bug還是後端的bug
通常可以利用抓包工具來進行分析。可以從三個方面進行分析：請求介面，傳參，響應。
如果請求的介面url錯誤，為 前端 的bug
如果傳參不正確，為 前端 的bug
如果響應內容不正確，為 後端 bug
如果定位為後端的bug，可以進一步通過以下方法精確定位是哪裡出bug
前端BUG 後端BUG
界面相關 業務邏輯相關
布局相關 性能相關
兼容性相關 數據相關
交互相關 安全性相關
這里提供了幾個方法，可以給大家一個思路，讓大家能在學習和工作中了解如何去區分BUG屬於前端還是後端。
這種方法是最常用的，我們必須掌握的，常用於查看是後端返回給前端的數據有誤，還是前端顯示有誤。
大多數瀏覽器都有自帶的介面查看工具，如Chrome，FireFox等都可以通過F12開啟抓包，在NetWork中可以看到當前頁面發送的每個http請求。要想通過介面查看法來判斷，你需要先了解Chrome瀏覽器的Network面板介紹。
當我們發現一個bug，並不確定這個bug屬於前端還是後端，可以查看後端服務的日誌，復現bug時，查看日誌中有沒有相關信息。基本可以認為，如果日誌沒有輸出，很可能這個功能並沒有與後端交互，也就不存在後端的問題。反之，如果日誌有輸出，可以進一步查看有無錯誤日誌信息，進一步分析。
經驗法就只能是慢慢積累了。負責的項目多了，自然對功能的實現過程有了解，也就明白如何分類bug了。在平常的工作和實踐中慢慢總結，不要只是一味的點點點測測測，總結復盤很重要。
5. 怎樣判斷是前端bug還是後端bug
可以從請求跟響應這賀悄一過程判斷，如果前端已經把數據發送給了後端，後端沒有返回數據則是後端問題，如果前端在用戶輸入數據之後發送請求，前端沒有帶數據在請求中就是前端的問題，或者說後台已經傳回來了數據，但是到鉛拍啟前端沒有顯示出來。這個也是槐如前端問題。具體的話可以在瀏覽器中debug調試看看
6. 如何判斷一個缺陷是屬於前端還是後端的
後端是寫介面的，前端是寫界面的。出現缺陷時可以用postman之類的測試軟體檢測一下後端介面，若數據響應正確，則是前端的鍋，否則是後端的鍋。也不排除部分特殊情況，具體視情況而定。
7. 找到一個bug，通過f12，怎麼判斷bug是前端還是後台的
比較前後約定介面地址、參數、返回欄位頁面渲染等，錯誤、缺失則是前端bug。
若上述正確，則大概率是後台bug。
8. 如何分析定位一個問題是前端還是後端引起的
1.首先，記錄問題本身錯誤信息，確認和後台通訊介面
2.通過抓包工具（比如fiddler）復現當前存在問題進行抓包
3.結合介面相關文檔說明，對抓包數據進行解析
4.驗證解析結果，分析如果請求無誤，響應返回結果有誤，且結果和問題報錯信息一致則為後台問題；若請求無誤，響應結果也正確，則為前端問題，如果想系統的學習測試相關的技術，可以了解一下黑馬程序員的軟體測試課程，裡面講的非常詳細。
9. 小程序測試bug怎麼區分前段還是後端
進入調試頁面，如果是瀏覽器，按F12，然後看報錯信息，如果是介面報錯就是後端問題，如果是控制台報錯，就是前端問題