測試人員如何定位bug

定位問題大體思路：用戶層面問題-->web頁面/軟件界面-->中間件-->後端服務-->代碼-->數據庫

1.用戶層面問題：用戶本身的環境問題或操做問題，好比環境不通或者操做不正確。這種問題通常不是bug,若是要考慮構建更加健壯的軟件，那麼能夠根據實際狀況來決定要不要處理。

2.web頁面問題：這類問題通常經過觀察以及利用一些常識可發現，好比樣式問題通常是css問題，交互問題通常是是js的問題，文本問題通常是HTML的問題。

3.web頁面操做後，好比發出一個請求，可能會進入中間件這個層面。這裏的中間件是廣義上的，好比LVS、CDN、各類緩存服務器等等。

4.後端服務層：服務會轉發到真正的後端服務層，WEB服務器、應用服務器好比nginx、tomcat會收到請求。若是發現內存溢出，那麼就可能定位到是Tomcat配置問題；若是請求返回404，也多是nginx配置不當。這個時候可能會遇到一些環境問題，好比測試環境沒有問題，到線上就有了，極可能是環境緣由，好比jdk版本不一樣、Tomcat版本不一樣、jar包版本不一樣等等。

5.最後一層是數據庫：也可能會有代碼沒有問題，不表明軟件沒有問題。數據庫層面各類問題，好比字段的約束問題等。假如一個文本框的前端校驗和接口校驗的文本長度是50，但數據表字段設定的是VARCHAR（30），那麼在存數據的時候確定會報錯。再好比測試環境沒有，到線上卻有了，也多是數據庫版本不一樣致使的。

有的問題會直接暴露在用戶面前，有些可能須要分析日誌。

1.狀態碼查看4xx狀態碼通常表示客戶端問題（固然也有多是服務器端配置問題），好比401要看一下是否帶了正確的身份驗證信息；403看下是否有訪問權限；404看下對應的URL是否真實存在。

2.5xx通常表示服務器端問題，500服務器內部錯誤，須要配合服務器log進行定位，502多是服務器掛了，503多是網絡過載致使，504多是程序執行時間過長致使。

 

3.看服務器日誌

若是發生5xx問題，或者檢查後端接口執行的sql是否正確，最多見的排查方法就是去看服務器日誌，好比Tomcat日誌，開發人員通常會打印出關鍵信息和報錯信息，從而找到問題所在。

5.接口的請求和返回以及js執行是否報錯。若是接口返回了200，就必定正常嗎?

假設要測試一個翻頁控件，翻到第二頁的時候，發現內容和第一頁徹底同樣，接口請求返回的是200，該怎麼排查？

這個時候就要看前端發送的參數正不正常，後端返回的內容正不正常，即接口的請求和返回。

請求URL不正確是前端bug，傳參不正確是前端bug，響應內容不正確則是後端bug，若是是響應內容不正確的後端問題，那就要繼續深挖，是接口吐數據時出錯仍是數據庫中的數據就錯了，仍是緩存中的數據錯了（若是用到緩存的話），常常見到後端開發人員有的負責接口，有的負責寫入數據庫，有的負責緩存。

6.看需求文檔