經驗分享：如何快速定位問題(BUG)

讓我掉下眼淚的 不止內存泄漏

讓我夜夜不眠的 不止你的需求

明天還要改多久 你攥着個人手

讓我感到爲難的 是善變的需求

發佈老是在半夜 回滾是永遠的愁

錯誤(Bug)隨時的暴漏 困擾着我心頭

做爲程序員，以上這些場景你必定都經歷過。今天就來聊聊如何快速定位問題。

先劃重點，下文所寫都是一家之言，本人工做經驗很少，語言表達能力有限，若是寫的很差，還望輕噴。另外，本文所講都是站在Java後端開發者的角度。

背景

下文所講內容，都會圍繞如下幾個真實案例來作舉例分析，先描述一下具體案例：

• 案例1：App首頁白屏。

  詳細描述：App、H五、小程序首頁都是由同一個後端接口負責提供數據。測試大佬反饋說，App首頁白屏了。

• 案例2：小程序商品會員價顯示不正確。

  詳細描述：測試大佬反饋，某商品會員價顯示不正確，客戶端展現會員價爲0元。爲何會員價0元是不正確的呢？由於咱們在系統中作了限制，會員價必須大於0元。

• 案例3：優惠券領取不了了，彈窗顯示「領取失敗，該優惠券僅限新人領取」！

  詳細描述：這是一個領取優惠券的功能。用戶能夠經過該活動領取優惠券。用戶在領取優惠券時，頁面彈窗提示：」領取失敗，該優惠券僅限新人領取「。同時，測試大佬反饋說，這個帳號就是一個新人帳號，是剛剛註冊的用戶。

• 案例4：某用戶購買的xx評測專欄的評測課沒法打開。

  詳細描述：評測專欄是我司的一個特點專欄，在這個專欄中，有一節評測課。評測課就是讓用戶作在線試題，用戶先進行測試，瞭解本身狀態。測試完成以後，系統會根據用戶的答題狀況，向用戶推薦合適的專欄課程表，供用戶學習。

背景交代完畢，那若是是你，在遇到這幾個問題的時候，會怎麼處理呢？

復現問題

當測試大佬反饋問題時，首先要作的就是復現問題。若是問題能復現，好嘛，已經解決一大半了，做爲開發，我以爲仍是要有這個自信的。能復現的問題，那就必定能修復（修復成本有高低，這個不在本文討論範圍以內哦），實在是找不到Bug代碼，我能夠一行一行的調試嘛！因此，遇到問題不用慌，淡定淡定。

那若是問題不能復現呢？怎麼辦？

這個時候，我通常的作法是去查日誌。若是日誌中有錯誤信息，咱們即可以根據錯誤信息快速定位到Bug所在的具體代碼。那若是這個時候也沒有錯誤信息呢？嗯...我想一想，好像也沒有別的辦法了。問題不能復現，程序沒有報錯，那隻能麻煩測試大佬再多測試一下，看看能不能復現吧。

快速定位

通過上一步驟，咱們已經可讓Bug復現了，那接下來要作的就是快速定位。快速定位？定位什麼呢？

通常公司項目開發，都會分後端開發、前端開發、APP開發，這裏說的快速定位，指的就是要快速定位到是三端中的哪一端出的問題。

那如何快速定位呢？

若是你熟悉這個功能的總體流程，清楚整個功能會經歷哪些步驟、哪些模塊，這對你去快速定位問題是很是有幫助的。固然，也有一些監控工具能夠來幫助開發者作快速定位，幫助開發瞭解整個流程。例如：sentry、skywalking等。

舉個慄：

案例1：App首頁白屏。

案例2：小程序商品會員價顯示不正確

這兩個問題反饋過來的時候，我打開app、H五、小程序都看了一下，發現：只有app的首頁白屏了，H5和小程序的首頁都是好的，考慮到App、H五、小程序首頁都是由同一個後端接口負責提供數據，那這個問題大機率是app那邊的問題，因而請app開發同事幫忙定位一下問題。

而app、H五、小程序這三端都出現了商品會員價顯示不正確這個問題，因而我判定，這大機率是一個後端的邏輯問題。三端都寫錯代碼取錯了會員價這個機率應該不大。

案例4：某用戶購買的xx評測專欄的評測課沒法打開。

這是一個產品反饋的線上問題，由測試大佬提到開發這邊的時候，測試大佬當時並不能復現。因爲評測課的特殊性，它是須要由用戶作題輸入到系統，系統解析用戶答題狀況，而後作系統推薦。

這是一個典型的與用戶行爲數據相關的問題，可能只有具備某些特性行爲、數據的用戶纔會遇到。遇到這種問題，測試也是很難復現的。能夠查一下日誌，看看有沒有報錯信息。

當時遇到這個問題的時候，因爲項目接入了sentry平臺，開發這邊也是收到了系統異常報錯的郵件提醒，很快速的就找到了緣由。

定位接口

好，通過上面幾輪的大體判斷，這大機率就是一個後端Bug了。如今咱們須要作的就是，快速定位到出問題的具體接口。若是移動端，就用Charles抓個包，H5端就直接打開Chrome控制檯。

so easy~~ 媽媽不再用擔憂我找不到接口啦~~ 固然了，在實際操做過程當中，可能並無這麼簡單。前端渲染頁面可能請求了N多個接口。

舉栗子

案例2：小程序商品會員價顯示不正確。

由於app、H五、小程序三端使用的是同一個接口來獲取商品相關信息，我會優先在H5平臺調試，畢竟不用開Charles，方便嘛~~

遇到問題，快速響應和解決纔是重點，特別的線上問題。因此有時候這個功能可能不是你開發的，那麼如何在這麼多請求中如何快速定位找個具體接口呢？這就要靠你的經驗和聰明的大腦了。

這裏就分享一個個人經驗吧，不必定適合全部場景。就拿這個案例來講：打開商品詳情頁，打開控制檯。基於我對系統的總體瞭解，我確信必定會有一個接口返回商品的會員價，具體哪一個接口我也不知道。

好，這個時候怎麼辦呢？猜接口！固然了，也不是亂猜。獲取商品會員價，那這個接口大機率須要前端傳給後端一個商品id，那商品id在哪裏呢？商品id通常都會出如今當前頁面的URL裏。因而，在控制檯的filter框中（圖中已標紅）輸入商品id。這個時候已經能夠過濾掉大部分的請求了。

接下來你要作的，仍是猜！看看剩下這些請求地址名稱，猜一下他的做用；看看接口返回的字段名稱，有沒有名稱像「會員價」字段，有沒有返回值和前端顯示的會員價同樣的字段。最後，通過大膽猜測以後，咱們要作的就是當心求證，確認咱們定位的接口是否正確。

定位代碼

定位到接口以後，咱們就能夠準備看代碼，修Bug啦！

不知道你有沒有遇到過這樣的狀況。打開代碼，一眼望去，這個代碼這麼長，並且以前也不是我寫的，我該怎麼辦呢？下面咱們就來說一下如何來快速定位Bug代碼。

舉栗子：

案例2：小程序商品會員價顯示不正確。

通過咱們以前一頓猛如虎的操做，終於定位到了問題。

//接口返回數據
{
    "price":9900,
    "discountPrice":8900,
    "vipPrice":0,
}
複製代碼

會員價顯示不正確，也就是"vipPrice":0這個字段有問題。

打開代碼，找到該接口對應Controller，找到該Controller返回的VO，找到VO中的vipPrice字段的setter方法，鼠標右鍵find Usages。恭喜你，這個時候你已經找到了這個vipPrice的值是在哪一行被設置的了，將重點聚焦於此便可，Bug就在這個代碼附近了。看一下這個vipPrice的值是怎麼計算出來的，是否是計算邏輯寫錯了。

若是這個時候，很不幸Controller的VO是經過BeanUtils這些工具類將屬性映射過去的，那麼你運行find Usages可能就找不到屬性是在哪裏被設置的了。唉，寫代碼時用的爽，出問題時淚汪汪。那隻能查這個VO是在哪裏被用到了，而後去代碼裏查了。

案例3：案例3：優惠券領取不了了，彈窗顯示「領取失敗，該優惠券僅限新人領取」！

若是「領取失敗，該優惠券僅限新人領取」這個文案，是你的接口返回給客戶端的，那麼，這個時候你要作的就是，IDEA全局查找這個關鍵詞。

哈哈哈，恭喜你，快速定位了，在PayUserRuleChecker的第51行，是否是很簡單？

修復問題

既然已經定位到具體的代碼了，那麼就能夠進行問題修復了。這個時候就要看我的經驗啦，有經驗的程序員可能一眼就能看出來問題。

這裏列舉一些須要注意的點：

• 學會聚焦。整個service方法的邏輯代碼可能不少，可是像」會員價顯示不正確「這種問題，必定是之和計算會員價相關，你只須要聚焦這一塊的邏輯便可。
• 學會debug。有些狀況下，即便發現了問題代碼，卻仍是發現不了問題（好比說，報錯日誌說第xx行有問題，打開xx行一看，懵，這裏怎麼可能會有問題呢）。這個時候，你應該嘗試去debug代碼，經過運行時debug，分析數據，來發現問題。

如何避免

借用測試大佬的一句話："沒bug是不可能的，這輩子都不可能沒bug的"。

而咱們要作的，一是要儘量的減小Bug，避免問題重複出現；二是要遇到問題，快速修復。千萬不要懼怕Bug，更不要擔憂出Bug就不敢寫代碼。

簡單總結

最後的最後，就來作個簡單總結：

1. 遇到問題不要慌，只要能復現，就能修復

2. APP、H五、小程序三端快速定位，找到問題負責人

3. 定位問題接口，找到問題代碼

   • 如何快速定位問題接口
   • 如何快速定位問題代碼

4. debug then fix

5. 總結經驗，避免再犯

---

歡迎關注公衆號：