[測試篇] bug排查技巧 | 小技巧

如下總結以web測試爲例，其餘類型測試可參考。前端

提問

相信有很多人測試在發現bug以後，立馬給開發提了bug，不多去排查bug產生的緣由。web

在開發準備修復bug的時候，發現測試提的「bug」描述不清，不知道如何復現，只能本身琢磨或者叫QA來演示一遍，最尷尬的是，可能在測試演示完以後，才發現這個並不是bug，而是因爲QA的不規範致使的。這樣就會引發開發的不滿，以爲測試在浪費他們的時間。後端

因此在咱們發現問題的時候，首先要作的第一件事就是須要確認一下是不是咱們自己測試的不規範致使的。若不肯定，可再嘗試進行復現。bug描述必定要寫具體，不然不只浪費開發的時間，也會浪費本身的時間。緩存

說明bug要麼開局一張圖，要麼一句話，開發復現bug全靠蒙。服務器

開發：markdown

正確姿式： 問題應該有詳情的描述，圖文並茂，場景說明，以及bug出現的流程，對應帳號密碼等。app

bug瞎指派。前端的bug指給後端，後端的bug指給前端。測試

開發：ui

正確姿式： 分析錯誤產生的緣由，分析是前端仍是後端產生的bug，123砸過去😌url

老是測一些生產環境中根本不可能存在的狀況。甚至有些需求就是如此設計，無論三七二十一直接提bug。 開發：

正確姿式： 先把需求理清楚，設計用例的時候，把一些實際不可能發生的事情剔除掉。

步入今天的正題，來，跟着我，從個人世界走一走。

新上一個功能時，發現前端頁面展現仍是舊的，發起請求還報錯？
- 若是部署沒問題的話，那麼大機率是前端存在緩存，可清除緩存試試。這裏就有個問題：若是功能發到live，可是因爲前端存在緩存，用戶沒沒有清除緩存，那們從前端向後端服務器請求時，一直報錯，一旦被投訴，那這個鍋就是你來背了。
分辨是前端的鍋仍是後端的鍋。前端的鍋不只僅只有UI的問題，須要發起請求，處理請求，並渲染到前端。
- 出現問題時，可先判斷接口是否有錯誤，返回的結果是否符合預期。若接口無錯誤且接口返回符合預期，但前端展現不符合預期，應該由前端負責修復。
- 若接口有報錯，可優先確認，前端有沒有按照約定的格式向後端發起請求，若是沒有，那麼前端須要負責修復。
- 若接口報錯，前端也按照約定的格式發起請求，那麼鍋就在後端了，接着可繼續往下走，繼續排查問題出現的緣由。

可經過接口返回的錯誤信息去猜想錯誤的來源

響應碼。可根據返回的響應碼去定位問題。須要你們熟悉這些響應碼。

響應頭。通常後端返回的錯誤信息會放在響應頭中，若是大家不會將錯誤信息放在響應頭的話，可忽略這個。
響應體。若是請求報錯的話，接口通常會返回錯誤信息以及錯誤碼，可經過這些去定位問題。在源代碼中輸入錯誤信息定位報錯的具體位置（全局搜索），再根據先後調用去分析具體緣由。

從日誌入手，查看具體的日誌信息

從日誌入手的話，那麼就須要學會在嘩啦嘩啦的日誌中尋找具體且有用的關鍵信息，相信大部分同窗都用過grep這個命令，相比awk，sed而言，這個命令使用起來更簡單，足夠知足咱們的需求了。推薦grep的幾個經常使用參數：

-a<顯示行數>	-a10：處理顯示符合結果的那一行外，還顯示該行以後的20行
-b<顯示行數>	-b10：處理顯示符合結果的那一行外，還顯示該行以前的20行
-c<顯示行數>	-c10：處理顯示符合結果的那一行外，還顯示該行以前以及以後的20行
-v 「」	-v "INFO" 反向匹配。就是匹配到的都不顯示，只顯示不含有INFO的行。
-i/--ignore-case	忽略字符的大小寫
-e	grep -ev "info" -e "error" info.log :至關於or，查看info.log不包含info的行但包含error的行。
-c	統計匹配的行數
-E	正則匹配。使用這個須要瞭解正則匹配規則。

再不濟，可本身本地調試（固然，這個是在時間相對充分的狀況下，若是前面兩步還沒法找到具體緣由的話，可直接交由開發處理）
- 能夠先把bug提給開發，而後本身在本地調試查找具體的問題。若是你僅僅是功能測試，想轉測開，這個步驟對本身能力提高也頗有幫助。可是若是你只想點點點的話，那這步驟就免了。