埋點自動化測試框架設計

大數(shù)據(jù)時代，多數(shù)的web或app產品都會使用第三方或自己開發(fā)相應的數(shù)據(jù)系統(tǒng)，進行用戶行為數(shù)據(jù)或其它信息數(shù)據(jù)的收集，在這個過程中，埋點是比較重要的一環(huán)。埋點收集的數(shù)據(jù)一般有以下作用：

埋點測試，首先要了解埋點的分類。

埋點主要分為：前端埋點、后端埋點

1. 前端埋點：前端埋點可以理解為web端，app端等在前端觸發(fā)相關規(guī)則時進行的埋點上報等，主要記錄的是用戶的操作行為，例如點擊了哪個按鈕，進入了哪個頁面等等。

2. 后端埋點：主要是服務端埋點，可以理解為當用戶進行相關操作觸發(fā)相關接口請求或相關業(yè)務的時候，進行的埋點上報。

那么兩者有什么區(qū)別呢？

在實際過程中，有些埋點是不用特意區(qū)分前后端的，用戶的一個埋點事件在前端埋點或后端埋點都可以實現(xiàn)，但是需要注意的是，在實際埋點上報、數(shù)據(jù)收集等過程中會有數(shù)據(jù)丟失的情況，從這個角度來看的話，其實后端埋點要比前端埋點更有優(yōu)勢，前端埋點會因為一些網絡問題、適配問題等等容易出現(xiàn)上報異常造成數(shù)據(jù)丟失且丟失后排查困難，因為前端相關的是沒有記錄相關操作的，只負責上報，上報成功與否沒有記錄。

而如果是后端埋點，無論是自己的數(shù)據(jù)系統(tǒng)還是第三方數(shù)據(jù)系統(tǒng)都是可以通過自己系統(tǒng)本身相關的數(shù)據(jù)庫查詢或記錄日志等操作進行埋點數(shù)據(jù)的校驗排查，所以針對一些比較重要的埋點，還是建議以后端埋點為主，必要時通過記錄日志或記入數(shù)據(jù)庫等方式對相關數(shù)據(jù)進行二次記錄以便進行數(shù)據(jù)核實。

埋點測試的過程有兩個比較重要的環(huán)節(jié)，埋點上報和埋點落庫

1. 埋點上報：無論是前端埋點還是后端埋點，有沒有正常按照相關規(guī)則進行上報，相關的事件名、屬性值都是否完整正確上報，這個是需要關注的

2. 埋點落庫：埋點上報完的數(shù)據(jù)是需要存儲到數(shù)據(jù)庫當中再進行相關的數(shù)據(jù)統(tǒng)計、分析、歸類等等，除了檢查埋點上報，還要看最終數(shù)據(jù)是否正常落庫，相關數(shù)據(jù)字段是否正常。

了解了埋點測試的分類和過程，再思考如何針對埋點進行自動化測試。首先埋點自動化測試與其它自動化測試的方案設計在目的層面應該是一致的，是為了更好的進行埋點回歸測試，擴大埋點回歸的覆蓋率，特別是針對一些核心的埋點數(shù)據(jù)，例如一些埋點數(shù)據(jù)是轉化相關數(shù)據(jù)，而轉化數(shù)據(jù)直接跟核心業(yè)務相關，有些核心業(yè)務還會根據(jù)轉化數(shù)據(jù)進行營銷、銷售、業(yè)績等相關統(tǒng)計，埋點數(shù)據(jù)不準直接影響到這些東西。

那么如何進行埋點自動化測試設計呢？

可以進行分層設計

1.  用戶應用層框架-移動端Appium，web端selenium，主要是模擬用戶正常的業(yè)務操作

2. 數(shù)據(jù)mock、上報數(shù)據(jù)收集-通過構造測試數(shù)據(jù)給到用戶應用層使用，并且通過代理抓包收集上報數(shù)據(jù)，進行上報數(shù)據(jù)校驗（jsonschema校驗）

3. 服務端上報及落庫查詢-通過鏈接數(shù)據(jù)數(shù)據(jù)庫或使用相關API，查詢測試上報數(shù)據(jù)是否落庫。

另外，還需要結合Jenkins進行持續(xù)集成，每天或每次發(fā)版前對所有埋點進行回歸測試。

回復：【百人計劃】