Bug分析

• 1、如何分析Bug？
• • 1）抓包接口定位分析
  • 2）看系統日志

1、如何分析Bug？

1）抓包接口定位分析

web項目的話，一般工作中使用方式比較多的是使用瀏覽器自帶的F12抓包看接口請求。
如果是app客戶端之類的，一般采用fiddler等工具進行抓包接口。
不管哪種方式，目的都是通過查看接口，去定位分析屬于前端問題還是后端問題。

比如你在淘寶上邊購買了一件商品，并且成功支付，但是在我的訂單里面卻沒有記錄，你應該如何去分析定位這個問題？

首先需要搞明白的是這個場景的數據流調用的邏輯關系，不過這個問題比較簡單。

整體來說就是前端購買商品，支付成功，會把這條數據的商品信息加支付信息都落入數據庫中。

然后點擊我的訂單，會調后端接口，后端從數據庫取相關信息，然后前端渲染展示商品和支付信息。

搞明白這個場景的數據流轉就很容易定位分析這個bug了，可以使用抓包工具抓包這個我的訂單調后端的接口。

如果抓不到這個接口，就是前端沒有發出請求，顯然是前端問題。

如果有請求并且響應了，就查看這個接口響應信息，如果返回報錯了，則需要具體分析報錯內容。

這個時候既有可能是前端入參傳的不對，導致后端報錯。也有可能是前端傳對了，后端處理錯誤，需要具體分析是前端問題還是后端問題。

如果后端成功響應了且返回信息跟接口文檔定義的一致，那么大概率是前端展示的問題，這個時候需要找前端同事。

以上，就是定位一個bug是屬于前端還是后端的分析思路。

2）看系統日志

既然可以抓包定位看接口返回了，為什么還需要查日志系統呢？
這是因為對于一家公司來說，一般不止一個系統。很多公司都是根據業務不同劃分出不同的組，不同系統共同完成公司一個項目。

舉個例子，比如一家保險公司，可能有系統是負責用戶下單的就是交易系統，管理保單變更比如退保之類的就是保單系統，負責收錢的就是財務系統，負責賠錢的就是理賠系統……

每個系統就是一個組，一般二三十人不等。每個組有開發，測試，產品，具體看公司了。

那么這些系統是怎么交互合作的呢？就是通過接口來交互，這也是接口測試比較復雜的地方，涉及到多個系統多個接口的邏輯調用。

理解完這個，再說到為什么要查看日志的問題？

比如頁面調后端系統接口報錯了，但是你知道整個流程能有多長嗎？

頁面可能直接調用的是系統A接口，但是這時候系統A又調用了系統B，系統B又調用了系統C。頁面上看到的接口返回報錯結果，本質上可能是系統C接口報錯返回的。

這個時候僅僅通過抓包就無能為力了，你需要去查看系統日志，去一層層去分析，究竟是哪個系統報錯了，然后定位到問題。把報錯信息和日志截圖丟給那個系統同事。

一般我發送錯誤，協調處理時都會發下面幾樣東西，調對方接口的url，入參信息，返回報錯信息。

再簡單描述下調用接口業務場景，如果對方很熟悉的話一看url就知道了，這時候就不用描述了。

再來說下系統日志是怎么一回事？

日志本質上就是開發寫在項目中的代碼，報錯會拋出異常信息，以及打印一些接口返回信息等等。

有的公司會有專門的日志查詢系統，有的公司是通過xshell工具連接上linux系統再查找日志，這就看公司了。

因為現在公司系統一般是linux系統，所以查詢日志的命令自然就是linux命令了。

我一般用的比較多的是grep，tail這兩個命令，前者是精確查找，后者是動態查找，大家可以百度學習下這兩個命令。

說一下精確查找，就是根據開發代碼中打印的關鍵字信息去精確查找日志，一般是requestid，證件號或者訂單號之類的。

這個可以提測后問下開發，查找日志的關鍵字是什么，日志文件名是什么，以及去哪個服務里面去查找。

因為現在一般是微服務架構，不同的服務處理不同的業務，存儲不同的日志。不同公司可能不太一樣，但是方式大同小異。

總結

以上是生活随笔為你收集整理的如何定位前后端Bug？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。