巧用瀏覽器F12調試器定位系統先後端bug-轉載

作測試的小夥伴可能用過httpwatch，firebug，fiddler，charles等抓包（數據包）工具，但實際上除了這些還有一個簡單實用並的抓包工具，那就是瀏覽器的F12調試器。

httpwatch，firebug都是瀏覽器的插件，須要額外下載，fiddler，charles也須要額外下載安裝包另行安裝，可是瀏覽器F12調試器倒是全部瀏覽器內置的調試器，不須要你們額外去安裝的，打開它只是一個順手的事情，並且它提供的功能也比較強大，所以若是在開發或者測試web系統的時候，咱們能夠先考慮使用這個調試器去抓包，來調試系統或者用它來協助定位系統中的bug。

下文中我準備了幾個小案例來講明這個工具的用法以及使用它的便捷性。

廢話很少說，咱們首先來一睹它的陣容，以火狐爲例，打開瀏覽器，再按F12就能夠打開調試器，以下圖:

注意：不一樣的瀏覽器，調試器在ui上可能會有少量差別，但基本功能都差很少，掌握了某種瀏覽器調試器的用法後，其餘也很容易上手。下面咱們經過幾個小案例來講明咱們測試人員在系統測試中有哪些場景可以應用上調試器。

場景：在對web系統進行測試時，如何分析一個bug是來自於前端仍是後端。

 首先說一下，爲何找到網站中的bug後還要去分析它究竟是屬於前端bug仍是後端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）輸入登陸帳號(用戶名 / 密碼)：304034318@qq.com / 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）輸入登陸帳號(用戶名 / 密碼)：304034318@qq.com / 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）輸入登陸帳號(用戶名 / 密碼)：304034318@qq.com / 123456

3）點擊登陸，無任何反映（沒有提示也沒有跳轉）

從頁面交互看，輸入帳號，點擊登陸要麼登陸成功進入系統，跳轉到系統其餘頁面，要麼登陸失敗給出錯誤提示，而如今沒有任何反應，這確定是一個bug，可是這個bug究竟是屬於前端bug仍是後端，咱們無從而知，可是咱們能夠順手打開瀏覽器調試器來分析定位一下。

打開控制檯，咱們看到了控制檯並無js錯誤，可是有向後臺發起一個請求，一樣，此時還沒法有效定位到問題到底發生在前端仍是後端，可是能夠截個圖，寫上本身的測試過程：

 繼續打開「網絡」標籤，咱們看到這個底下有一個500請求，根據請求中的關鍵字眼login咱們判定這個就是登陸接口，而500則說明是後端服務器內部異常，通常是因爲後臺代碼執行中報錯致使的，因此截圖寫上咱們的分析，到時候提bug附上這個截圖：

 

 定論：根據請求返回的狀態碼500，咱們就能判定這個bug是後臺代碼執行時候報錯致使的，提bug帶上上面的這個信息，開發人員就知道要去檢查登陸接口的代碼了，所以縮小了開發定位問題的範圍，保證了開發能在第一時間快速fix掉bug。

 

好了，給你們演示了三個小案例，教你們在碰到bug時，如何順手藉助瀏覽器調試器定位到bug到底來自於前端仍是後端，固然我建議你們平時多關注一下http請求的響應狀態碼，對於常見的http code，好比200、30二、40四、500這些最好都去了解下，這樣結合了咱們的工具，在定位分析問題的時候，咱們會更堅決和自信。

小工具，可是很實用，這個技能你們get到了麼。但願你們在工做當中可以應用起來。用的多了就天然熟練了。