隨着業務的高速發展，對於精細化流量運營的需求不斷提升，埋點量級也在不斷提升，埋點數據的質量問題是繞不過去的一個點。我們主要圍繞“埋點管理”（定義管理和流程控制）、“埋點線下保障”、“埋點線上保障”這三個環節展開。改造流程、優化策略，打造相應的工具平臺來固化流程和輔助測試，保障埋點開發正確性的同時，也提高協作效率。
隨着業務的高速發展，對於精細化流量運營的需求不斷提升，埋點量級也在不斷提升，埋點數據的質量問題是繞不過去的一個點，但埋點質量保障又是個老大難問題：
-
首先，由於埋點是非結構化的數據，不像數據庫本身對結構化數據的結構由系統的保障；
-
其次，嚴選C端有多端(ios、android、web、各小程序等)，多端埋點有不同開發人員開發，保障正確性、一致性又會更麻煩；
-
從埋點的需求、開發、測試、數據採集加工校驗這一整條鏈路上，涉及業務、分析師、產品、開發（客戶端、服務端、數據）、QA多個團隊的角色；
-
需求不清、客戶端和服務端上報出錯、數據加工不正確，這任意一個環節出錯，都導致埋點數據質量問題，而且往往問題發現不及時、排查難。
針對這樣的一個長鏈路的保障，我們主要圍繞“埋點管理”（定義管理和流程控制）、“埋點線下保障”、“埋點線上保障”這三個環節展開。改造流程、優化策略，打造相應的工具平臺來固化流程和輔助測試，保障埋點開發正確性的同時，也提高協作效率。在實施的過程中，我們也充分的利用了現有的各種能力，尋求各方合作（避免重複造輪子），快速的構建起一套能夠跑得通的實操方案。
先來一張大圖，描述一下此方案在各個環節的內容和工具平臺建設（如下）。再詳細地分三個小章節來描述各個點的實踐細節；最後附錄中會對各個平臺系統的簡介。
1 埋點管理
本着規範先行的思路，我們制定了一些的“流程規範”和具體的“研發規範”，比如：
-
從需求提報&評審、開發、測試、發佈的整體流程規範，明確了各環節負責人的職責。
-
細化了在研發過程中能夠指導各角色實戰操作的各類規範和示範，比如“埋點開發規範”、“埋點事件定義規範”、“jira流程規範”、“數據埋點研發規範”等等，這些規範也的確起到了基石的作用。
“流程規範都在哪裏找啊？新人來了誰培訓（各個角色都要培訓）？埋點定義在哪找，變更的維護很不及時，同一個埋點有好幾個excel版本中不一樣啊！？” 於是我們開始“夸父-埋點管理平臺”的建設來固化流程、提高協作正確性和效率。
-
通過平臺，我們將埋點的元信息線上化，統一管理，告別口口相傳，避免多個excel、wiki到處找埋點需求/定義的尷尬局面。
-
其次，將埋點研發流程固化在此平臺上。從“產品經理”錄入埋點詳細需求–>到“開發”根據定義開發埋點–>提測通知“QA”介入驗收–>修改埋點狀態爲“發佈”，整個流程都在埋點定義平臺上完成。
-
充分利用和兼容了現有的開發任務管理習慣，聯動jira來管理各項任務（需求任務、開發任務）和具體排期，儘可能地減少流程落地帶來的額外理解和操作成本。
2 埋點測試
一方面，從思路上還是沿用了通用的測試思路，線下測試（新功能&迴歸）+ 線上監控。
新埋點測試
思路：手工觸發、人工校驗；新埋點需求可能比較碎片化，自動化的投入產出比不高
落地：依靠“夸父-埋點管理平臺”提供的2個功能，“手動測試” 和 “自動測試方案”
迴歸測試
思路：利用UI自動化觸發埋點 + 數據校驗
落地：依靠“埋點自動化測試平臺”
線上埋點監控
思路：監控線上埋點的實際上報情況
落地：依靠“夸父-埋點管理平臺”提供的“埋點進度監控”能力
另一方面，也將埋點測試和現有研發流程進行了集成：
思路：策略制定 --> 觸發測試 --> 度量結果 --> 上線門禁
落地：整體依靠“嚴選質量平臺”控制全流程
2.1 埋點手工測試支持
爲了支持埋點的手工測試，開發了2個能力來支持：
首先是“埋點數據實時展示”，可以根據用戶提供的賬號、期望關注的頁面、行爲、計劃執行時間段等等信息，展示、校驗、統計相關的埋點信息。避免去通過手機抓包來看數據，在通過大數據平臺查詢工具去數倉裏查落表數據的麻煩。
其次，提供“執行集”的概念，來圈定本次測試需要執行的測試內容來判斷執行的進度和測試覆蓋情況。
埋點上報數據的實時展示
隨着用戶的操作，能夠實時展示上報並落入數倉的埋點數據詳細信息。端到端的測試（不僅僅只測客戶端是否正確）。
埋點執行集
有的放矢，統計測試覆蓋。篩選需要測試的埋點列表 -> 測試執行（手工或自動化）-> 覆蓋情況統計
-如何篩選所需要測試的埋點列表？
- 提供多個篩選維度（頁面、行爲、版本、端、狀態、名字）
- 提供核心埋點列表：
-
固定設置的篩選維度：核心的頁面、行爲所對應的埋點，比如“首頁的點擊xxx”埋點
-
人工設置的黑/白名單：某個非核心頁面的重要埋點
-
線上實際的埋點流量：最近XX日流量佔頁面流量的比重大於 x%
-
2.2 埋點數據自動化校驗
隨着埋點數量的不斷增加，QA和開發同學在校驗埋點數據的工作量越來越大。也常常因爲迴歸不充分，出現一些比較“低級”的錯誤，比如必填字段爲空、字段缺失或者Key不對等等。
爲了避免這些問題出現且又能降低人工測試的成本，我們抽取了一些通用的校驗規則來對收到的埋點數據進行自動稽覈。比如：
-
格式校驗：上報埋點的格式和埋點定義是否一致，是否存在缺失的字段
-
非空校驗：from_seq、seq_list、app_v 等數據是否爲空
-
自定義規則校驗：不符合枚舉值、數值的閾值校驗、連續性校驗（同上一個埋點的遞增組成部分校驗）等等
這個數據自動化校驗能力，在下面提到的手工測試、自動化迴歸、線上監控都會被應用到。
2.3 客戶端埋點回歸的自動化
埋點回歸和普通的功能迴歸相同，它主要的痛點是耗時耗力。
-
埋點多（核心埋點300+），一次迴歸需要耗時不短，且一旦碰到hotfix的時候更是要命。
-
埋點散落在各個頁面，涉及到多個業務，需要分派給多位同學來測試，這裏的協作問題可想而知。
-
測試沉澱，人員流動、功能變更等等。
因此實際情況下，草草的部分迴歸是家常便飯，全迴歸的成本實在太高（哪怕是核心埋點的全迴歸）。爲了解決這個問題，2019年下半年，開始共建埋點自動化測試平臺，利用SmartAuto的UI自動化能力和夸父平臺原有的埋點校驗能力，解決客戶端核心埋點的迴歸問題。
首先，大致介紹一下嚴選埋點上報的流程
其次，看一下埋點自動化測試的流程，以及它和其他現有平臺的交互
最後，我們來介紹一下嚴選和杭研QA部一起合作開發的埋點自動化測試平臺的使用姿勢。把大（埋）象（點）裝進冰箱（自動化迴歸）一共需要3步：
第一步：建立自動化測試“用例”
-
配置需要執行的UI自動化用例
-
配置每一步所需要校驗的哪些埋點（這裏第三步也可以先不操作，系統會提供2種類型的規則一些自動匹配的可能需要驗證的埋點）
-
匹配規則1 --> 根據ui自動化執行記錄 vs 上報的埋點數據，時間戳、頁面/行爲來粗略匹配
-
匹配規則2–> 其他歷史用例（其他的用例中也存在同樣的操作，且已經配置過該步驟需要驗證什麼埋點，則系統會自動化獲取）
第二步：執行驗證（平臺自動執行，不需要人工干預）
-
調用夸父平臺接口，開啓埋點上報的監控（因爲目前嚴選埋點自動化校驗，大部分依靠夸父平臺對埋點正確性的校驗能力）
-
觸發smartAuto 平臺上的UI自動化用例執行
-
根據“驗證模型”來確定app上的操作和期望的埋點是否“出現”&“正確”
第三步：結果分析&統計
-
驗證概述：驗證的埋點數量、埋點驗證成功/失敗的情況
-
驗證詳情：
-
執行明細：執行人、關聯賬號、app版本、執行時間（開始 & 總共耗時）
-
步驟詳情：自動化操作步驟 vs 期望校驗的埋點明細（包含ui自動化操作的截圖）
-
3 埋點線上監控
說完線下，再說說線上。客戶端兼容性問題、線下無法完整覆蓋所有的場景。作爲對線下測試的補充，線上的埋點監控也是不可或缺。
因此我們也在夸父平臺上提供針對每一個埋點的線上數據統計能力，當新增的/變更的埋點發布以後，QA、開發、產品同學可檢查這些埋點線上的實際數據。
-
埋點“進度”監控：統計的是最近此埋點在各端的上報數量、成功、失敗數量；一般當新埋點或變更埋點發布後，我們會關注這個信息（上報數量是否有明顯異常？是否線上存在明顯的數據異常、比如格式錯誤、字段缺失等等）
-
埋點“分析”：和用戶行爲分析平臺聯通，提供更多維度的數據統計信息；比如，觀察埋點的數量趨勢、和其他埋點向結合來分析它的正確性等等
最後，針對缺失埋點可以利用熱修復來保障及時修復，形成整個線上埋點保障的閉環。
4 在路上
優化埋點回歸的測試
-
埋點用例維護。讓用例結構更加優化，降低維護成本
-
提高UI行爲和期望埋點關聯關係自動化匹配的精準度
埋點數據自動化校驗
-
針對埋點具體參數的數值的校驗，如何更自動化
-
針對場景化的埋點校驗，比如埋點中有些數據是從其他埋點裏透傳的
埋點線上問題處理閉環加強
- 線上問題採集能力加強（現有埋點監控 + 人工上報問題）
作者簡介：
梁策：2014年加入網易，目前主要負責嚴選數據線的質量保障工作。對質量體系建設、各類測試技術有一定的實戰經驗和濃厚的興趣。