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

試想:

1. 根據需求，用戶頭像應是圓形，但結果是方形，是誰的BUG?

2. 保存用戶信息時，無法保存成功，也沒有錯誤提示，最可能是誰的BUG?

顯然，工作過程中，我們不可能把這些BUG提交給同一個人去解決。我們應該至少區分出是前端還是后端BUG，就好像時下流行的詞“垃圾分類”，經過BUG分類處理，整個團隊的效率都會有所提高。

一、什么是前端/后端?

目前多數互聯網項目都是前后端分離開發的，那么什么是前端?什么是后端?簡言之，前端側重于頁面設計，后端側重于服務開發。

比如要保存一個用戶信息，前端把界面顯示給用戶，讓用戶按需填寫，當用戶點擊“保存”按鈕時，數據會通過網絡被提交給后端服務，由后端服務處理是否需要進一步運算，并且把數據保存在哪一個數據庫的哪一張表里。

二、為什么要區分前端/后端BUG?

目前多數項目都是多人協作開發的，如果不能明確這個BUG是誰造成的，容易提交給錯誤的開發人員，會大大降低BUG的解決效率。

另外，如果團隊規模較大，或者由各地的項目組拼湊而成，勢必會增加溝通成本，這更需要我們在類似禪道或者Jira等項目管理軟件中提交BUG時，先指明是誰的BUG，避免互相踢皮球的現象。

所以，為了提高團隊效率，測試人員尤其要做好BUG分類。

三、如何定位前端/后端BUG?

對于一個優秀的軟件測試工程師來說，區分BUG屬于前端還是后端是尤為重要的。

頁面請求過程

弄清楚如何定位和分類BUG之前，需要了解一下頁面請求的過程，以 http 請求為例，請求過程如下：

1. 用戶在前端頁面操作，如點擊某個功能

2. 頁面攜帶數據進行請求，訪問具體功能接口

3. 由后端服務執行該接口相應的業務邏輯，如涉及數據，再去請求并組裝數據返回給前端

4. 前端頁面進行渲染和展示對應的頁面和數據

前后端BUG各有什么樣的特點?

? 前端BUG

– 界面相關

– 布局相關

– 兼容性相關

? 后端BUG

– 業務邏輯相關

– 性能相關

– 數據相關

– 安全性相關

定位BUG屬于前端還是后端，有什么方法?

這里提供了幾個方法，可以給大家一個思路，讓大家能在學習和工作中了解如何去區分BUG屬于前端還是后端。

1. 經驗法

軟件測試人員應不斷精進自己的技能，負責的項目多了，自然對功能的實現過程有了解，也就明白如何分類BUG了。

例如：

網頁上的某個圖片的分辨率不對，如果我們了解實現過程，可以想到一般情況下，是根據某個地址去服務器取圖片的，數據庫一般只保存地址，那么圖片能正確顯示，就說明后端的基本功能是滿足需求的。如果具體圖片分辨率有誤，最可能的原因是前端顯示過程出了差錯。

2. 日志查看法

當我們發現一個BUG，并不確定這個BUG屬于前端還是后端，可以查看后端服務的日志，復現BUG時，查看日志中有沒有相關信息。基本可以認為，如果日志沒有輸出，很可能這個功能并沒有與后端交互，也就不存在后端的問題。反之，如果日志有輸出，可以進一步查看有無錯誤日志信息，進一步分析。

3. 接口查看法

這種方法常用于查看是后端返回給前端的數據有誤，還是前端顯示有誤。

大多數瀏覽器都有自帶的接口查看工具，如Chrome，FireFox等都可以通過F12開啟抓包，在NetWork中可以看到當前頁面發送的每個http請求。

通過Chrome看到的接口情況如下

可以在Response中查看響應數據

我們需要對比通過后端接口拿到的數據和前端顯示的數據，來確認問題出在哪里。如果數據錯了，頁面顯示是錯的，也是正常的，先從后端入手去解決。如果數據對了，但是顯示錯了，就需要問問前端的開發人員了。

四.經驗和總結

1.溝通很重要

我們在定位BUG的過程中，最不能忽略的一個問題是和開發人員的溝通，有時候忙活半天，不如一問一答。經驗和技術的成長也都離不開合理高效的溝通。

2.經驗和小結

? 出現樣式的問題基本都是CSS的BUG

? 出現文本的問題基本上都是html的BUG

? 出現交互類的問題基本上都是Javascript的BUG

? 其他問題先溝通，再定位
 
本文轉自：傳智播客 軟件測試學院 test.itcast.cn