背景
知乎用戶端發版周期為 1 周，前後端項目需求多且疊代快。用戶端各子產品雖然做了元件化，但仍然不可避免的存在耦合，導緻商業功能會受第三方改動影響。而用戶端線上故障需要發版解決，版本覆寫速度慢，且商業故障直接造成金錢損失影響較大。如何在時間緊、代碼複雜的情況下，盡早發現問題，減少線上故障？運用核心資料進行測試驗證，是知乎商業化測試團隊目前嘗試的一個辦法。通過梳理核心資料，在項目流程中加入資料檢查的環節，作為品質保障的最後一環。
如何建構核心資料模型
建構核心資料模型，需要深入了解業務，關注産品核心名額。用戶端上廣告的資料流程，主要包括用戶端請求廣告，引擎下發廣告，用戶端加載廣告，滑動螢幕至廣告可見，使用者點選廣告，使用者在廣告落地頁産生轉化幾個步驟，形成如圖一所示的漏鬥模型。但這些名額的絕對值，受用戶端覆寫使用者變化影響，對判斷用戶端品質沒有參考意義。通過相鄰2個數相除，可以分别得到填充率，加載率，可見率，點選率，轉化率，這些資料不受使用者變化影響，是我們用來判斷用戶端品質的主要業務名額。
圖一 廣告漏鬥模型
除了上述業務名額，我們還關注用戶端上的性能名額：比如用戶端崩潰率，圖檔加載時長，開屏廣告白屏時長，落地頁加載速度等。
服務端核心名額包括資源占用情況，如cpu，mem，線程，網絡，磁盤IO；服務性能資料，如吞吐，平均響應時間，.99響應時間，失敗率，逾時率；業務資料，如消費、點選率、過濾情況、下發量等。
如何使用資料
在項目流程的各個環節，都可以運用資料，去輔助測試。并且需要把資料檢查，作為項目流程的必經環節。
需求評審階段
需求評審時，需要關注漏鬥模型上的環節是否設計了埋點，埋點時機是否合理，埋點定義是否唯一。比如推廣目标為app的廣告，有廣告卡片上一鍵下載下傳和進入落地頁後點選下載下傳2種形式，埋點需要覆寫這2個下載下傳流程，同時有不同的标記友善進行對比。
用戶端灰階階段
用戶端運作環境複雜，功能測試覆寫場景有限。對比灰階版本和線上版本核心資料，可以輔助判斷用戶端功能是否正常。用戶端版本灰階報表如圖二所示。另外新開辟的廣告位，在灰階期間進行試投放，能快速驗證點選率等資料是否符合預期。值得一提的是，資料的擷取和展示必須直覺易用，如果資料的查詢語句複雜，資料的對比需要手工多次處理，資料測試就很難落地。
圖二 用戶端版本灰階報表
服務端上線過程
不同的後端服務，可以制定不同的上線checklist。比如服務資源名額、性能名額和業務名額。在上線過程中，實時觀察監控，判斷上線是否成功。
項目上線後
項目上線後，需要及時分析資料是否達到預期。對于AB實驗的功能，需要分析資料判斷是否全量。比如落地頁加速的需求，發版後需要驗證廣告落地頁到達率是否有提升，提升的比例是否達到目标。
定期資料巡查
定期資料巡查，可以發現線上緩慢變差的名額，并及時修正。比如服務端記憶體占用持續上漲，逾時率越來越高；用戶端随新版本覆寫崩潰率上升。
如何分析資料
資料分析的模型如圖三所示。為友善描述，定義了4層。
- Level 1 是結果，所有的變化，最終都展現在消費的變化。
- Level 2 是名額，對應漏鬥模型的每層。
- Level 3 是次元，Level 2 的每個名額，都可以按 Level 3 的每個次元（或次元組合）分組聚合。
- Level 4 是變量，列出了引起資料變化的因素，比如流量的變化，服務上線，用戶端發版，大客戶的賬戶變化，頻控等政策調整。
圖三 資料分析模型
Level 1 的變化，受 Level 2 所有名額綜合影響，分析起來比較困難，通常先找出變化最明顯的名額。名額确定後，按Level 3 的各種次元聚合，找到發生變化的次元。次元确定後，變量就比較友善确定了。比如，加載率分小時次元統計，如果有突變，一般是後端服務上線這個變量引起；如果是漸變且趨勢和新版本覆寫速度吻合，則是用戶端發版引起。下面舉例說明：
案例1：用戶端某版本灰階過程中，轉化名額裡的下載下傳成功率下降明顯。
分析方法：
1、對比灰階版本和線上版本資料，隻有灰階版本發生變化。Level 4的變量确定，新版本問題。
2、按Level 3的次元進行聚合，發現所有的廣告，名額都下降
3、按網絡環境聚合，發現4G環境下載下傳成功率下降明顯。至此，排查用戶端4G下載下傳邏輯。
案例2：用戶端某版本灰階過程中，某第三方管道加載率暴漲
分析方法：
1、對比灰階版本和線上版本，在1月2日都出現暴漲
2、分析1月1日的資料，灰階版本和線上版本，資料正常，基本判斷和用戶端無關
3、分析1月1日的資料，按小時聚合，發現19:00 資料開始暴跌，此時可以排查19點附近的服務端上線記錄
4、繼續按次元聚合漏鬥模型的上遊名額，縮小服務範圍。
建立Level 4 各變量的資料報表，可以加快排查的過程，比如：
- 大客戶消費對比表。昨天 topN 消費廣告主資料和今天 topN 消費廣告主資料對比，能快速定位消費變化。
- 廣告商賬戶記錄檔。廣告定向條件的修改，出價的變化，都會影響廣告的下發，進而導緻消費發生變化。
- 後端上線記錄，實驗放量記錄，用戶端發版記錄。資料突變時，友善快速找到上線的項目。
資料測試的效果
在用戶端灰階過程中，運用版本核心資料對比，發現多起資料異常，且可以通過資料分析快速定位問題，保證了發版的品質。服務端上線過程中加入資料檢查，可以在小流量階段發現問題時，及時復原，避免多起線上故障。
作者:鐘離無糖
出處:https://zhuanlan.zhihu.com/p/57013245