目前的專案大多數都是前後端分離的，當我們發現bug後不知道指派給哪位開發，指派錯了不僅影響解決bug 的效率，還容易被開發懟。最主要的是人家會認為你不專業，不專，不專呀。廢話少說，上乾貨（踩過的坑）！
測試中發現問題不要著急提bug，首先確定我們測試的這個系統是不是開發提測最新的一個版本，比如開發自己發現了這個bug，然後又提測一版，但我們還用的上一個版本。這時候把bug提上去，開發會把bug直接打過來（附帶一句：這個bug已經解了，用新包。。。）。
然後排除測試環境的干擾（如：網路環境，配置項）在測試的時候我們往往開啟網路代理對資料進行攔截，導致某些資料載入失敗，所以確保網路環境是正常的。再比如我們在測試環境後臺新增的資料，在正式環境測試，會出現資料匹配不上的問題，所以要確保環境一致。有些app要開啟手機系統許可權如：懸浮窗、開啟訊息通知、獲取相機許可權等，如果這些許可權不開啟，會出現收不到訊息和系統許可權，所以我們要確保這些許可權是開啟的。
最後，如果以上兩個步驟都沒問題，我們再根據測試用例、需求文件、介面文件、UE等確定功能模組，開開心心的提bug了。這時候就要展示你的神通了，該用的工具全部用上如：fiddler，瀏覽器的開發者模式，wireshark，linux命令，SQL語句等，努力復現出現bug的步驟。總結如下：
1、通過抓包或者開發者模式過濾資訊定位bug
a、傳入引數錯誤（缺參、錯參等），導致的問題往往是前端bug；
b、傳入的引數與介面文件一致，資料返回正確，介面顯示錯誤（欄位取錯），往往是前端的bug；
c、傳入引數正確，資料返回錯誤，往往是後端的bug。
d、根據響應狀態碼：404客戶端請求路徑錯誤，500伺服器內部錯誤
2、根據前後端的bug特點來定位問題
a、前端bug特點：介面相關（文字問題可能是html產生的bug）、佈局相關（樣式問題可能是css產生的bug，圖片尺寸解析度等）、相容性相關
b、後端bug特點：業務邏輯相關（排序、分頁）、資料相關、效能相關、安全性相關。
3、查詢系統日誌
如果查不到錯誤日誌前端的問題概率大，反之後臺的問題。
4、通過sql語句查詢資料，是否有資料入庫。
有些專案介面與介面之間存在相互呼叫，不同的介面是不同的開發人員負責，我們可以通過查詢資料的方式來區分哪個介面問題。比如：在A模組新增一條資料，但是在B模組沒有展示，這時我們 通過查詢資料庫的資料來確認，是A模組沒有插入資料，還是B模組沒有查詢到資料來縮小問題的範圍。
5、根據測試經驗確定誰的bug
軟體測試人員應不斷精進自己的技能，負責的專案多了，自然對功能的實現過程有了解，也就明白如何分類BUG了。再就是與開發人員多溝通，熟悉業務，每個模組是哪個開發負責的。
總之，要對自己發現的問題負責，確保每一個bug都能被開發人員理解和修改。學無止境，我們不要怕踩坑，踩過的坑再踩才很可怕。