之前公司招了一個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）
可能點點點久了會比較心累，但是有些臟活累活，還是要測試干，因為這是我們功能測試的職責......