測試如何定位判斷是前端的bug還是后端bug

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

前后端分離的優點是什么？

1. 徹底解放前端。前端不再需要向后台提供模板或是后台在前端HTML嵌入后台代碼
2. 提高工作效率，分工更加明確。前端只關注前端的事，后台只關心后台的的話，兩者開發可以同時進行，在后台還沒有時間提供接口的時候，前端可以將數據寫死或者調用本地的JSON文件即可，頁面的增加和路由的修改也不必再去麻煩后端，開發更加靈活
3. 局部性能提升。通過前端路由的配置，我們可以實現頁面的按需加載，無需一開始加載首頁便加載網站的所有的資源，服務器也不再需要解析前端頁面，在頁面交互及用戶體驗上有所提升
4. 降低維護成本。通過目前主流的前端MTV框架，我們可以非常快速的定位 及發現問題的所在，客戶端的問題不再需要后台人員參與及調式，代碼重構及可維護增強
5. 實現高內聚低耦合

為什么要區分前端/后端BUG？

現在，市場上很多應用都是前后端分離開發的。如果是一個多人開發的系統。不能明確定位到這個BUG是誰造成的，任意提交給錯誤的開發人員，我們又不可能把這些bug同時提交給前端和后端一起去解決，同時提交給提交給前后端開發人員，每個人都會有依賴心理，就像'三個和尚沒水喝的道理是一樣的'。同樣的道理，Bug會像皮球一樣被開發踢來踢去，耽誤解決bug時間，影響項目進度。

​ 另外，如果團隊規模較大，或者由各地的項目組拼湊而成，勢必會增加溝通成本，這更需要我們類似禪道或者Jira等項目管理軟件中提交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了。在平常的工作和實踐中慢慢總結，不要只是一味的點點點測測測，總結復盤很重要。