本文轉載自：https://www.cnblogs.com/nickjiang
做測試的小夥伴可能用過httpwatch，firebug，fiddler，charles等抓包（數據包）工具，但實際上除了這些還有一個簡單實用並的抓包工具，那就是瀏覽器的F12調試器。
httpwatch，firebug都是瀏覽器的插件，需要額外下載，fiddler，charles也需要額外下載安裝包另行安裝，但是瀏覽器F12調試器卻是所有瀏覽器內置的調試器，不需要大家額外去安裝的，打開它只是一個順手的事情，而且它提供的功能也比較強大，因此如果在開發或者測試web系統的時候，我們可以先考慮使用這個調試器去抓包，來調試系統或者用它來協助定位系統中的bug。
下文中我準備了幾個小案例來說明這個工具的用法以及使用它的便捷性。
廢話不多說，我們首先來一睹它的陣容，以火狐爲例，打開瀏覽器，再按F12就可以打開調試器，如下圖:
注意：不同的瀏覽器，調試器在ui上可能會有少許差異，但基本功能都差不多，掌握了某種瀏覽器調試器的用法後，其他也很容易上手。
場景：在對web系統進行測試時，如何分析一個bug是來自於前端還是後端。
首先說一下，
1.在一些公司，一個系統可能是由前端團隊和後端團隊共同開發出來的，因此在分配bug的時候，不同模塊的bug一般都會指派給對應的負責團隊乃至於個人。
2.提bug的時候，如果能儘量提供有價值的信息給開發人員，來縮小定位範圍，甚至於如果能夠直接協助定位到bug出在哪裏，那麼開發人員將更容易去fix掉bug，從而降低了測試和開發之間的溝通成本，提高了工作效率。
3.bug提的好從側面也能體現測試人員具備了較高的技術專業性，而不是隻會點點點，個人形象在項目團隊中也會得到迅速提升。別人也會認爲你是大佬，他們看你的表情如圖：
我們在分析一個系統bug來自於前端還是後臺時，最有用的兩個是調試器提供的兩個標籤，這兩個標籤底下都記錄了一些數據，一個是控制檯，一個網絡。
控制檯：記錄了前端js執行的情況，以及前端向服務器發出去的所有http請求信息，，如果有js錯誤可以在控制檯下看到，同樣如果發送到後臺的某個http請求沒有得到服務器正常響應，也能看到他的狀態信息。
網絡：記錄了前端往服務器發的所有的http請求信息，而且每個請求發送了什麼數據，服務器是否正常響應了請求，如果響應了，響應回來的狀態碼是什麼，響應數據是什麼都可以在“網絡”標籤下看到。
說了這麼多，到底怎麼用呢。
第一個小案例：
1）訪問：http://39.108.136.60:8380/ningmengban/app/login/login.html
2）輸入登錄賬號(用戶名 / 密碼)：[email protected] / 123456
3）點擊登錄，無任何反映（沒有提示也沒有跳轉）
從頁面交互看，輸入賬號，點擊登錄要麼登錄成功進入系統，跳轉到系統其他頁面，要麼登錄失敗給出錯誤提示，而現在沒有任何反應，這肯定是一個bug，但是這個bug到底是屬於前端bug還是後端，我們無從而知，但是我們可以順手打開瀏覽器調試器來分析定位一下。
打開控制檯，我們看到了控制檯有一個js錯誤，並且是login.js這個腳本在執行的時候報的一個錯誤，login是登錄的意思，所以我們下意識認爲這個js腳本就是定義了登錄前端邏輯的js腳本，點擊登錄按鈕沒任何反應這個bug很可能就是因爲前端js執行報錯引起的，截個圖，寫上自己的分析。
爲了進一步驗證自己的猜想，還可以再看下“網絡”標籤:
定論：經過分析，前端登錄腳本執行報錯導致了前端沒有對後臺登錄接口發起調用，頁面點擊登錄按鈕沒有任何提示，這個bug屬於前端的bug。我們提bug的時候帶上上面的兩個截圖，裏面有我們的分析。
第二個小案例：
1）訪問：http://39.108.136.60:8380/ningmengban/app/login/login.html
2）輸入登錄賬號(用戶名 / 密碼)：[email protected] / 123456
3）點擊登錄，無任何反映（沒有提示也沒有跳轉）
從頁面交互看，輸入賬號，點擊登錄要麼登錄成功進入系統，跳轉到系統其他頁面，要麼登錄失敗給出錯誤提示，而現在沒有任何反應，這肯定是一個bug，但是這個bug到底是屬於前端bug還是後端，我們無從而知，但是我們可以順手打開瀏覽器調試器來分析定位一下。
打開控制檯，我們看到了控制檯並沒有js錯誤，但是有向後臺發起一個請求，此時還無法有效定位到問題到底發生在前端還是後端，但是可以截個圖，寫上自己的測試過程：
爲了進一步定位，可以打開“網絡”標籤：
定論：這個404 not found請求路徑找不到的問題，可能是前端後臺開發人員改了接口地址，也有可能是前端js發起登錄請求是接口地址寫錯了，所以這個bug可以題給前端開發，也可以提給後端。只要提供了上面分析截圖，開發人員也能秒改這個bug。
第三個小案例：
1）訪問：http://39.108.136.60:8380/ningmengban/app/login/login.html
2）輸入登錄賬號(用戶名 / 密碼)：[email protected] / 123456
3）點擊登錄，無任何反映（沒有提示也沒有跳轉）
從頁面交互看，輸入賬號，點擊登錄要麼登錄成功進入系統，跳轉到系統其他頁面，要麼登錄失敗給出錯誤提示，而現在沒有任何反應，這肯定是一個bug，但是這個bug到底是屬於前端bug還是後端，我們無從而知，但是我們可以順手打開瀏覽器調試器來分析定位一下。
打開控制檯，我們看到了控制檯並沒有js錯誤，但是有向後臺發起一個請求，同樣，此時還無法有效定位到問題到底發生在前端還是後端，但是可以截個圖，寫上自己的測試過程：
繼續打開“網絡”標籤，我們看到這個底下有一個500請求，根據請求中的關鍵字眼login我們斷定這個就是登錄接口，而500則說明是後端服務器內部異常，一般是由於後臺代碼執行中報錯導致的，所以截圖寫上我們的分析，到時候提bug附上這個截圖：
定論：根據請求返回的狀態碼500，我們就能斷定這個bug是後臺代碼執行時候報錯導致的，提bug帶上上面的這個信息，開發人員就知道要去檢查登錄接口的代碼了，因此縮小了開發定位問題的範圍，保證了開發能在第一時間快速fix掉bug。
好了，給大家演示了三個小案例，教大家在碰到bug時，如何順手藉助瀏覽器調試器定位到bug到底來自於前端還是後端，當然我建議大家平時多關注一下http請求的響應狀態碼，對於常見的http code，比如200、302、404、500這些最好都去了解下，這樣結合了我們的工具，在定位分析問題的時候，我們會更堅定和自信。
小工具，但是很實用，這個技能大家get到了麼。希望大家在工作當中能夠應用起來。用的多了就自然熟練了。