做測試的小夥伴可能用過httpwatch，firebug，fiddler，charles等抓包（資料報）工具，但實際上除了這些還有乙個簡單實用並的抓包工具，那就是瀏覽器的f12偵錯程式。
下文中我準備了幾個小案例來說明這個工具的用法以及使用它的便捷性。
廢話不多說，我們首先來一睹它的陣容，以火狐為例，開啟瀏覽器，再按f12就可以開啟偵錯程式，如下圖:
注意：不同的瀏覽器，偵錯程式在ui上可能會有少許差異，但基本功能都差不多，掌握了某種瀏覽器偵錯程式的用法後，其他也很容易上手。
下面我們通過幾個小案例來說明我們測試人員在系統測試中有哪些場景能夠應用上偵錯程式。
場景：在對web系統進行測試時，如何分析乙個bug是來自於前端還是後端。
首先說一下，
為什麼找到**中的bug後還要去分析它到底是屬於前端bug還是後端bug，三個原因：
1.在一些公司，乙個系統可能是由前端團隊和後端團隊共同開發出來的，因此在分配bug的時候，不同模組的bug一般都會指派給對應的負責團隊乃至於個人。
2.提bug的時候，如果能盡量提供有價值的資訊給開發人員，來縮小定位範圍，甚至於如果能夠直接協助定位到bug出在**，那麼開發人員將更容易去fix掉bug，從而降低了測試和開發之間的溝通成本，提高了工作效率。
3.bug提的好從側面也能體現測試人員具備了較高的技術專業性，而不是只會點點點，個人形象在專案團隊中也會得到迅速提公升。別人也會認為你是大佬，他們看你的表情如圖：
我們在分析乙個系統bug來自於前端還是後台時，最有用的兩個是偵錯程式提供的兩個標籤，這兩個標籤底下都記錄了一些資料，乙個是控制台，乙個網路。
控制台：記錄了前端js執行的情況，以及前端向伺服器發出去的所有http請求資訊，，如果有js錯誤可以在控制台下看到，同樣如果傳送到後台的某個http請求沒有得到伺服器正常響應，也能看到他的狀態資訊。
網路：記錄了前端往伺服器發的所有的http請求資訊，而且每個請求傳送了什麼資料，伺服器是否正常響應了請求，如果響應了，響應回來的狀態碼是什麼，響應資料是什麼都可以在「網路」標籤下看到。
說了這麼多，到底怎麼用呢。
第乙個小案例：
2）輸入登入賬號(使用者名稱 / 密碼)：[email protected] / 123456
3）點選登入，無任何反映（沒有提示也沒有跳轉）
從頁面互動看，輸入賬號，點選登入要麼登入成功進入系統，跳轉到系統其他頁面，要麼登入失敗給出錯誤提示，而現在沒有任何反應，這肯定是乙個bug，但是這個bug到底是屬於前端bug還是後端，我們無從而知，但是我們可以順手開啟瀏覽器偵錯程式來分析定位一下。
開啟控制台，我們看到了控制台有乙個js錯誤，並且是login.js這個指令碼在執行的時候報的乙個錯誤，login是登入的意思，所以我們下意識認為這個js指令碼就是定義了登入前端邏輯的js指令碼，點選登入按鈕沒任何反應這個bug很可能就是因為前端js執行報錯引起的，截個圖，寫上自己的分析。
為了進一步驗證自己的猜想，還可以再看下「網路」標籤:
定論：經過分析，前端登入指令碼執行報錯導致了前端沒有對後台登入介面發起呼叫，頁面點選登入按鈕沒有任何提示，這個bug屬於前端的bug。我們提bug的時候帶上上面的兩個截圖，裡面有我們的分析。
第二個小案例：
2）輸入登入賬號(使用者名稱 / 密碼)：[email protected] / 123456
3）點選登入，無任何反映（沒有提示也沒有跳轉）
從頁面互動看，輸入賬號，點選登入要麼登入成功進入系統，跳轉到系統其他頁面，要麼登入失敗給出錯誤提示，而現在沒有任何反應，這肯定是乙個bug，但是這個bug到底是屬於前端bug還是後端，我們無從而知，但是我們可以順手開啟瀏覽器偵錯程式來分析定位一下。
開啟控制台，我們看到了控制台並沒有js錯誤，但是有向後台發起乙個請求，此時還無法有效定位到問題到底發生在前端還是後端，但是可以截個圖，寫上自己的測試過程：
為了進一步定位，可以開啟「網路」標籤：
定論：這個404 not found請求路徑找不到的問題，可能是前端後台開發人員改了介面位址，也有可能是前端js發起登入請求是介面位址寫錯了，所以這個bug可以題給前端開發，也可以提給後端。只要提供了上面分析截圖，開發人員也能秒改這個bug。
第三個小案例：
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到了麼。希望大家在工作當中能夠應用起來。用的多了就自然熟練了。
IE瀏覽器F12無法使用
這是很久之前遇到的乙個問題了，當初公升級完ie瀏覽器之後出現的問題 當然現在我也好久沒有用過ie瀏覽器了，現在應該只有那些老專案還在使用ie瀏覽器了 錯誤的文字內容 diagnostic exception in windowonload error an error has occurredisp...
谷歌瀏覽器F12基本用法
第一步 開啟你想進行除錯的頁面，並按f12進入到除錯模式 這是關於最右側 元素選擇器 的功能展示 關於第二個功能的使用，這個功能是將頁面適應成手機螢幕大小，elements 點選這個功能後出現的是當前頁面的html檔案，在你想實時修改的那個元素處雙擊，可以暫時修改，不過並沒有同步到後台，這個功能通常...
chrome瀏覽器中 F12 功能的簡單介紹
由於f12是前端開發人員的利器，所以我自己也在不斷摸索中，檢視一些部落格和資料後，自己總結了一下來幫助自己理解和記憶，也希望能幫到有需要的小夥伴，嘿嘿！首先介紹chrome開發者工具中，除錯時使用最多的三個功能頁面是 元素 elements 控制台 console 源 sources 此外還有網路 ...