資料產品Bug定位流程與實用方法

資料產品一般是服務與企業內部，一般原則是實現功能為第一優先順序，能用就行。所以在資源配備上是能省就省，比如沒有專門的UI資源，產品經理自己設計原型圖直接開發;沒有測試，資料產品自己進行功能可用性和資料準確性測試。沒有運營，資料產品自己當客服，擋運維等。這也是為什麼多數資料產品的崗位招聘時，對候選人的綜合能力要求更高的原因。

在產品功能測試驗收的環節，最經常遇到的情況就是發現頁面沒資料，或者指標資料不對，提了bug list，標註責任人的時候，把前後端、資料開發都加上了，但一個和尚挑水吃，2個和尚沒水吃，不把問題清晰直接指向具體地一方，這個問題往往是最後才會被解決，都想著對方先去排查一下。所以，掌握一些bug定位的小技巧，作為產品經理，就可以直接判斷是前端還是後端的問題，快速有效提升問題修復的效率。

資料產品的常見bug型別及排查方法

一、資料不顯示

資料產品的核心是要把資料呈現出來，給使用者進行使用和分析，但是經常是開發提測後，產品進行測試和驗收時，發現頁面全是“暫無資料“,根本無從測試。這個時候，需要界定清楚，是資料問題還是介面問題。

1.資料有沒有

一般來說，資料產品的查詢資料庫是一些可以秒級響應使用者互動操作的關係型資料庫或者列式儲存的非關係型資料庫，所以需要使用基礎的SQL查詢語句，查詢資料是否已經被成功的從資料倉儲(hive)成功地推數到了MySQL(或其他)。經常出現地情況就是，反饋頁面沒資料，一查發現，資料沒有推送，或者推送的資料格式不對

2.格式對不對

有資料了，在判斷頁面用到的篩選條件是否和資料裡面的格式保持一致，比如介面開發時，用day和month區分日報或月報的日期型別，但是資料推送過來的列舉值是“日報、月報”，對於資料開發和介面開發不是同一個人，資料格式是經常會出現對接問題的地方

3.前端有沒有請求?

資料產品資料查詢類的功能為主，一般是採用C/S架構，即客戶端發請求，服務端返回資料，通常每一次使用者的點選、篩選都需要請求後端介面，但是如果前端壓根沒法請求，那就不可能有資料顯示。判斷的方法就是頁面右鍵-檢查，或者直接F12，調出頁面debug的彈窗，監測本次操作是否有請求介面

找到network(網路)，重新整理頁面，或者先清空歷史請求的介面避免干擾，再點選頁面，看下最新的操作是否有發起請求。右上角可以設定檢查的介面的顯示方式，右側顯示，還是新視窗開啟，還是下方顯示。

另外，資料產品一般要求資料查詢效能控制在2s內，感覺頁面慢，定量的看到底有多慢，也是透過network看每個介面的響應時間

4.介面有沒有返回

資料庫有資料，格式正確，而且前端正常請求了介面，但是就是沒資料，那就要看下介面是否返回了資料，或者前端傳參是否正確

點選某一個具體的介面，首先看介面有沒有返回資料。主要是看介面的response，首先看是不是報錯了，報錯了直接把錯誤截圖扔給後端(java)開發。如果操作成功，但是data為空，也找後端。

如果操作成功，也返回了資料，就主要前端的問題了，比如傳參問題，或者介面展示bug。那就要近一一步看前端的傳參是否對了。主要透過payload看這個介面的入參

二、資料不準確

近期做的專案，搞了100多個資料指標，經常出現指標資料看著不符合常理的情況，比如同比異常大，佔比超100%等，這個時候就需要一個指標一個指標的拿著頁面顯示的結果，和MySQL(或其他)比對，常見的錯誤型別就是後端取錯欄位，或者前端介面呈現指標名和介面返回的指標繫結關係錯誤。在這個過程中，主要涉及的就是基礎SQL select * from table where等語句，連Join都很少用到。想學習SQL基礎可以參考之前的文章產品經理必知必會的SQL知識(附pdf版電子書)

以上都是非常基礎知識，但是在資料產品實際工作過程中還是非常實用的，至少對於我自己的這個專案，一個人把產品經理，QA、專案經理，運維、運營全乾了。總結一下分享給產品新人同學，以作備忘。