目前的項目大多數都是前后端分離的，當我們發現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都能被開發人員理解和修改。學無止境，我們不要怕踩坑，踩過的坑再踩才很可怕。