背景

知乎客戶端發(fā)版周期為 1 周，前后端項目需求多且迭代快?？蛻舳烁髂K雖然做了組件化，但仍然不可避免的存在耦合，導(dǎo)致商業(yè)功能會受第三方改動影響。而客戶端線上故障需要發(fā)版解決，版本覆蓋速度慢，且商業(yè)故障直接造成金錢損失影響較大。如何在時間緊、代碼復(fù)雜的情況下，盡早發(fā)現(xiàn)問題，減少線上故障？運用核心數(shù)據(jù)進行測試驗證，是知乎商業(yè)化測試團隊目前嘗試的一個辦法。通過梳理核心數(shù)據(jù)，在項目流程中加入數(shù)據(jù)檢查的環(huán)節(jié)，作為質(zhì)量保障的最后一環(huán)。

如何構(gòu)建核心數(shù)據(jù)模型

構(gòu)建核心數(shù)據(jù)模型，需要深入了解業(yè)務(wù)，關(guān)注產(chǎn)品核心指標(biāo)?？蛻舳松蠌V告的數(shù)據(jù)流程，主要包括客戶端請求廣告，引擎下發(fā)廣告，客戶端加載廣告，滑動屏幕至廣告可見，用戶點擊廣告，用戶在廣告落地頁產(chǎn)生轉(zhuǎn)化幾個步驟，形成如圖一所示的漏斗模型。但這些指標(biāo)的絕對值，受客戶端覆蓋用戶變化影響，對判斷客戶端質(zhì)量沒有參考意義。通過相鄰2個數(shù)相除，可以分別得到填充率，加載率，可見率，點擊率，轉(zhuǎn)化率，這些數(shù)據(jù)不受用戶變化影響，是我們用來判斷客戶端質(zhì)量的主要業(yè)務(wù)指標(biāo)。

圖一 廣告漏斗模型

除了上述業(yè)務(wù)指標(biāo)，我們還關(guān)注客戶端上的性能指標(biāo)：比如客戶端崩潰率，圖片加載時長，開屏廣告白屏?xí)r長，落地頁加載速度等。

服務(wù)端核心指標(biāo)包括資源占用情況，如cpu，mem，線程，網(wǎng)絡(luò)，磁盤IO；服務(wù)性能數(shù)據(jù)，如吞吐，平均響應(yīng)時間，.99響應(yīng)時間，失敗率，超時率；業(yè)務(wù)數(shù)據(jù)，如消費、點擊率、過濾情況、下發(fā)量等。

如何使用數(shù)據(jù)

在項目流程的各個環(huán)節(jié)，都可以運用數(shù)據(jù)，去輔助測試。并且需要把數(shù)據(jù)檢查，作為項目流程的必經(jīng)環(huán)節(jié)。

需求評審階段

需求評審時，需要關(guān)注漏斗模型上的環(huán)節(jié)是否設(shè)計了埋點，埋點時機是否合理，埋點定義是否唯一。比如推廣目標(biāo)為app的廣告，有廣告卡片上一鍵下載和進入落地頁后點擊下載2種形式，埋點需要覆蓋這2個下載流程，同時有不同的標(biāo)記方便進行對比。

客戶端灰度階段

客戶端運行環(huán)境復(fù)雜，功能測試覆蓋場景有限。對比灰度版本和線上版本核心數(shù)據(jù)，可以輔助判斷客戶端功能是否正常?？蛻舳税姹净叶葓蟊砣鐖D二所示。另外新開辟的廣告位，在灰度期間進行試投放，能快速驗證點擊率等數(shù)據(jù)是否符合預(yù)期。值得一提的是，數(shù)據(jù)的獲取和展示必須直觀易用，如果數(shù)據(jù)的查詢語句復(fù)雜，數(shù)據(jù)的對比需要手工多次處理，數(shù)據(jù)測試就很難落地。

圖二 客戶端版本灰度報表

服務(wù)端上線過程

不同的后端服務(wù)，可以制定不同的上線checklist。比如服務(wù)資源指標(biāo)、性能指標(biāo)和業(yè)務(wù)指標(biāo)。在上線過程中，實時觀察監(jiān)控，判斷上線是否成功。

項目上線后

項目上線后，需要及時分析數(shù)據(jù)是否達到預(yù)期。對于AB實驗的功能，需要分析數(shù)據(jù)判斷是否全量。比如落地頁加速的需求，發(fā)版后需要驗證廣告落地頁到達率是否有提升，提升的比例是否達到目標(biāo)。

定期數(shù)據(jù)巡查

定期數(shù)據(jù)巡查，可以發(fā)現(xiàn)線上緩慢變差的指標(biāo)，并及時修正。比如服務(wù)端內(nèi)存占用持續(xù)上漲，超時率越來越高；客戶端隨新版本覆蓋崩潰率上升。

如何分析數(shù)據(jù)

數(shù)據(jù)分析的模型如圖三所示。為方便描述，定義了4層。

• Level 1 是結(jié)果，所有的變化，最終都體現(xiàn)在消費的變化。
• Level 2 是指標(biāo)，對應(yīng)漏斗模型的每層。
• Level 3 是維度，Level 2 的每個指標(biāo)，都可以按 Level 3 的每個維度（或維度組合）分組聚合。
• Level 4 是變量，列出了引起數(shù)據(jù)變化的因素，比如流量的變化，服務(wù)上線，客戶端發(fā)版，大客戶的賬戶變化，頻控等策略調(diào)整。

圖三 數(shù)據(jù)分析模型

Level 1 的變化，受 Level 2 所有指標(biāo)綜合影響，分析起來比較困難，通常先找出變化最明顯的指標(biāo)。指標(biāo)確定后，按Level 3 的各種維度聚合，找到發(fā)生變化的維度。維度確定后，變量就比較方便確定了。比如，加載率分小時維度統(tǒng)計，如果有突變，一般是后端服務(wù)上線這個變量引起；如果是漸變且趨勢和新版本覆蓋速度吻合，則是客戶端發(fā)版引起。下面舉例說明：

案例1：客戶端某版本灰度過程中，轉(zhuǎn)化指標(biāo)里的下載成功率下降明顯。
分析方法：
1、對比灰度版本和線上版本數(shù)據(jù)，只有灰度版本發(fā)生變化。Level 4的變量確定，新版本問題。
2、按Level 3的維度進行聚合，發(fā)現(xiàn)所有的廣告，指標(biāo)都下降
3、按網(wǎng)絡(luò)環(huán)境聚合，發(fā)現(xiàn)4G環(huán)境下載成功率下降明顯。至此，排查客戶端4G下載邏輯。

案例2：客戶端某版本灰度過程中，某第三方渠道加載率暴漲
分析方法：
1、對比灰度版本和線上版本，在1月2日都出現(xiàn)暴漲
2、分析1月1日的數(shù)據(jù)，灰度版本和線上版本，數(shù)據(jù)正常，基本判斷和客戶端無關(guān)
3、分析1月1日的數(shù)據(jù)，按小時聚合，發(fā)現(xiàn)19:00 數(shù)據(jù)開始暴跌，此時可以排查19點附近的服務(wù)端上線記錄
4、繼續(xù)按維度聚合漏斗模型的上游指標(biāo)，縮小服務(wù)范圍。

建立Level 4 各變量的數(shù)據(jù)報表，可以加快排查的過程，比如：

• 大客戶消費對比表。昨天 topN 消費廣告主數(shù)據(jù)和今天 topN 消費廣告主數(shù)據(jù)對比，能快速定位消費變化。
• 廣告商賬戶操作日志。廣告定向條件的修改，出價的變化，都會影響廣告的下發(fā)，進而導(dǎo)致消費發(fā)生變化。
• 后端上線記錄，實驗放量記錄，客戶端發(fā)版記錄。數(shù)據(jù)突變時，方便快速找到上線的項目。

數(shù)據(jù)測試的效果

在客戶端灰度過程中，運用版本核心數(shù)據(jù)對比，發(fā)現(xiàn)多起數(shù)據(jù)異常，且可以通過數(shù)據(jù)分析快速定位問題，保證了發(fā)版的質(zhì)量。服務(wù)端上線過程中加入數(shù)據(jù)檢查，可以在小流量階段發(fā)現(xiàn)問題時，及時回滾，避免多起線上故障。

總結(jié)

以上是生活随笔為你收集整理的后端数据操作超时_数据分析在知乎商业质量保障中的初步实践的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。