之前公司招了一個BI，但是工作了幾個月，好像沒有預期的實際產出，再加上今年下半年所謂的“寒冬”，公司直接撤了這個崗位，然後公司就開始引進“資料埋點”了。這裡水這麼一篇部落格，是因為我發現很多測試人員好像並不知道什麼叫“資料埋點”以及它要怎麼測，所以在此說說我的理解，僅供參考。
資料埋點，對於產品迭代而言，有很重要的指向意義。資料分析是產品獲得需求的來源之一，通過對使用者資料的對比，對資料趨勢的分析，能發現哪些環節存在問題，哪些環節有提高空間。同時，資料分析也是檢驗功能是否有效，是否受歡迎的重要佐證等，資料埋點能讓它們以一種非常直觀的資料形式呈現出來。
怎麼埋點呢(技術實施方案得問開發，我不懂(*^▽^*))，現在市面上有很多第三方平臺，比如Growing IO、神策等。這些平臺都提供了對應的接入方法（一般也提供了對應的測試方法），然後公司開發人員插入對應的程式碼就行。也有利用友商提供的SDK做的，我司是用Growing IO的，所以下面的說明就以這個為例了。
埋點的原理，說簡單點就是，使用者進行的操作，能通過特定的識別符號記錄下來，這些識別符號彙總可以得到一個資料池，根據這些資料池，就可以監控使用者的大概操作。比如首頁的一個登入事件，開發設定識別符號為login_success，型別為計數器(這個型別第三方平臺設定)，那麼使用者每次登入成功(觸發的條件是登入成功還是登入都可以在第三方平臺設定)，login_success就會+1，通過資料彙總就能大致知道一段時間之內有多少使用者進行了登入且成功。（額，大致是這個意思，好像舉的例子不是很直白）
所以我們要測試的點就出來了，那就是：按照事件文件(一般找產品要)進行測試，遍歷去點點點文件上的事件，看對應的識別符號是否有反饋以及反饋是否正確。
____PS：事件的定義，就是指使用者在產品內做了什麼事情，轉義成描述性語言就是“操作+物件”。
下面是我司在Growing IO平臺上設定的事件：
其中Growing IO提供了一個debug外掛，可以實時看到前端的反饋，主要檢查下圖中紅色框的四個欄位對應第三方平臺上面設定的內容即可（eg:有關聯事件級變數的計數器型別場景）
後端事件的觸發，從而檢視識別符號的反饋，我司採用的非同步機制，所以需要跑定時任務之後一起傳送資料至Growing IO，而Growing IO本身的資料顯示也是有延時的（他們的客服告訴我是1-2小時），所以測起來就有點憂桑，此處略過。
---------------------------------------------------------------------------分割線-------------------------------------------------------------------
我知道資料埋點源於一本書，蘇傑的《人人都是產品經理》，幾年前老張推薦的，測試同學無聊看看打發時間還是可以的，可以理解產品的一些思維，平時測試的時候也會發現一些新的角度。資料埋點測試，可能要注意的就是頁面的覆蓋，因為前端介面很多，可能一個事件在七八個介面都有入口，務必做到全覆蓋，最好讓開發/產品給一個文件，說明改動了哪些介面（我司系統是這樣的，不知道其他專案如何），因為資料分析涉及到產品的層次，所以務必做到精準，否則對於錯誤的資料進行分析得出的需求多半也是不行的，而一個產品的生死，可能會影響到整個公司的生死（可能言重了，2333）
可能點點點久了會比較心累，但是有些髒活累活，還是要測試幹，因為這是我們功能測試的職責......