定位問題大致思路：用戶層面問題-->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.看需求文檔