測試工程師不只是負責發現問題，除了發現問題這種基本功外，定位問題，提出解決方案，提出預防方案也是要掌握的基礎技能
一、定位問題的要求
（前提當然是對功能、產品或業務需要熟悉，BUG書寫要盡量貼近開發易懂語言）
- 界面問題：如圖標錯誤，文字錯誤，樣式錯誤等，此種Bug需提供截圖
- 功能問題：如數據庫錯誤，服務端錯誤，客戶端錯誤，此種Bug需提供報錯信息，抓包信息或日志記錄、預期結果，復現路徑等
-
- 數據庫問題：需要定位到哪張表出現了問題，是服務端接口傳值導致的問題、sql本身問題或建表時就存在的問題，例如少某個字段，或者字段值為空
- 服務端問題：哪個接口出的問題，或者什么業務邏輯處理的不對，從而導致數據庫哪里不對或導致返回給前端的數據不對
- 客戶端問題：什么業務邏輯處理的不對或具體哪個字段對接有問題，例如與接口對接時字段取值錯誤，與服務端定義的需要前端自己處理邏輯的業務處理出錯等
Example：http://jira.gtja.net/browse/MATRIXJS-5758
1、選擇客戶時，客戶數據重復，cust_info基表僅一條數據（使用了V_CUST_INFO_OTHER視圖）
2、創建客戶股權關系后，未往select * from cust_equity_structure t表中記錄客戶掛接數據 （新增或維護均需要同步修改cust_equity_structure和MR_CUST_EQUITY_HOOK表）
3、實控關系解除時，未同步刪除 cust_equity_structure表中對應客戶股權掛接關系
二、定位問題工具
- 抓包工具：Flidder、F12、Charles等
-
- 請求未返回數據、返回錯誤的數或返回不符合預期結果的數據，可能是client（客戶端）入參錯誤，可能是server端處理錯誤。需結合接口文檔進行分析http://10.187.144.60:8080/matrix/doc.html
- 請求返回正確的數據，顯示在頁面不正確，那就是前端處理server端（服務器端）返回的數據出錯
2.日志系統：xshell、Finalshell、kibana等
-
- 查看具體當報錯信息：字段超長too large，空字符串：Null等
- 當自己分析不出具體錯誤時，遇到報錯信息可復制下來貼給開發，方便定位到具體問題
三、區分前后端問題方法
- 前台的bug通常是功能、界面和兼容性等有關；
- 后台的bug與邏輯、性能和安全性有關；
- 與數據相關的錯誤、排序問題大多是后台問題，對於APP頁面toast提示可能是后台給的，可能是APP給的，屬於前后端自己的定義
-
情況分析
a.檢查請求的數據是什么，反饋的數據又是什么（可以通過抓包工具來進行抓包分析）通常情況下，我們可以通過請求接口、傳參和響應三部分來判斷Bug，另外，也可以在瀏覽器的控制台進行代碼調試定位。
-
- 請求接口URL是否正確（如果請求接口URL不正確，為前端Bug，前端調錯接口）
- http請求中的參數是否正確（如果http請求中的參數不正確，為前端Bug，未遵守入參規則）
- 如果接口URL和參數都正確，查看響應內容是否正確（如果這種情況下響應內容不正確，則為后端Bug）
- 如果JS基礎比較好的話，也可以在瀏覽器的控制台中輸入JS代碼進行調試
- 。。。。
b.根據接口的文件，檢查數據是否正確
-
- 如果入參是正確的，但是后台反饋的數據是不符合需求的，那就是后台的問題；
- 如果前端沒有請求接口，或者請求的時候發送數據與定義不符，那這個時候就是前端的問題了
2.后端的Bug，如何准確的定位問題在哪里，如何精准的描述Bug
-
- 查看報錯日志（查看報錯日志，通過日志分析，有一定的經驗，並且有一定的代碼基礎，才能更好地定位問題）
- 查看數據庫的數據（了解所測功能的數據表結構，測試過程中，查看數據庫的數據，確認數據的正確性）
- 查看緩存（如Memcache、apc、redis等緩存）是否正確（個人還不太懂）
3.前台bug定位：
-
- F12在console中查看報錯信息，對於出錯的js可以在Sources下查看對應報錯的資源文件，貼給開發
- 與接口對接時字段取值錯誤，與服務端定義的需要前端自己處理邏輯的業務處理出錯等