背景簡單交代一下，業(yè)務(wù)是廣告平臺，廣告主要展現(xiàn)在C端，C端每接入一個廣告位需要QA介入測試，主要針對廣告展現(xiàn)、廣告的pv/click的數(shù)據(jù)上報。
由于歷史原因，C端并不統(tǒng)一采用sdk方式接入。
由于C端以及廣告平臺均是公司業(yè)務(wù)，cpc廣告才剛剛開始接入，公司并未重視各接入方的收入情況，以及各種內(nèi)部廣告及宣傳的融合。
各種原因吧，導(dǎo)致上報數(shù)據(jù)不準(zhǔn)確。這個風(fēng)險性是顯而易見的。（但總有人對風(fēng)險視而不見）
臨時抱佛腳的修復(fù)，隨著廣告位越來越多，積攢的問題也會越來越多。
有必要分析一番
- 關(guān)于上報數(shù)據(jù)問題：該是C端QA來保證質(zhì)量還是廣告QA來保證？
理論上廣告QA只需要保證請求展現(xiàn)、pv/click上報接口以及后續(xù)報表的正確，反作弊系統(tǒng)正常運作?？墒怯捎跇I(yè)務(wù)的歷史原因，這個責(zé)任落到了廣告QA身上。（其實就是各方PK失敗??）
- 所以廣告QA該做什么呢？輔助自己或C端QA做上報校驗，避免讓自己陷入手工重復(fù)勞動的漩渦里。
再來分析一番
- 什么樣的需求會用到自動化工具呢？
（1）新增廣告位
（2）C端優(yōu)化
（3）廣告?zhèn)葟V告引擎優(yōu)化=》影響展現(xiàn)
（4）廣告?zhèn)壬蠄蠓?wù)優(yōu)化
我們來討論一下（1）（2）（4），（3）可以通過廣告QA接口測試來保證質(zhì)量，不做贅述。 - 如何做全自動/半自動化工具？
- 我們是怎么手工測試的呢？
以Android為例，一般通過抓包過濾上報請求，校驗上報字段是否正確，再確定廣告?zhèn)嚷鋷斐晒?，報表展示正確。（一般上報請求數(shù)據(jù)丟入redis，廣告?zhèn)葟膔edis中取數(shù)據(jù)做分析落庫等等。） - 哪里可以做輔助測試？
（1）如果僅C端有更改，廣告?zhèn)葻o更改，那么可以【抓包=》校驗】，無需關(guān)注后續(xù)的落庫和數(shù)據(jù)展示。
（2）如果僅廣告?zhèn)扔懈膭樱珻端無改動，那么可以在redis中構(gòu)造不同廣告類型等上報數(shù)據(jù)，驗證后端邏輯。
（3）全有改動，需要做全流程測試，通過UI自動化，加后端邏輯校驗，走全流程回歸。 - 效率提升？
保守估計，之前一個廣告位要測試要4小時，現(xiàn)在1小時內(nèi)搞定。主要是純手工眼睛會累瞎。
今天主要說一下第（1）種方案，第（2）種很簡單，第（3）種非常復(fù)雜，性價比不高。
輔助打點測試方案：
經(jīng)過以上分析，針對C端有改動，廣告?zhèn)葻o改動情況，方案圖如下image.png通過配置文件來配置需要校驗的數(shù)據(jù)，抓包，過濾上報請求，校驗上報字段正確性，做的好看一點可以輸出報告。
還有有幾個小點想提一下：
- 我進(jìn)了一個頁面，一下子有10幾條上報數(shù)據(jù)，怎么check？
首先你要明確要測試廣告位的上報條數(shù)，是上報一條還是多條，每條上報是否是一樣的？只需要將自己需要校驗的數(shù)據(jù)過濾出來并check就可以了 - 期望結(jié)果有多個，實際結(jié)果只要match上一個就算通過
- 有一些點我們未必可以check的很全，比如廣告id，如果每次都有變化，最好用正則去match
選型
沒做什么特別的對比分析，沒什么權(quán)威性，不過可以說用起來還不錯。
原來想用一個基于nodejs的開源庫，后來還是選擇了mitmproxy，基于python的，選擇自己熟悉的沒錯。
整個程序可以說就是在分析數(shù)據(jù)，校驗數(shù)據(jù)，輸出校驗結(jié)果，沒別的了。整個工程不超過500行代碼。
由于沒什么代碼沒什么通用性，就不分享代碼了，大家可以動手做起來，代碼雖不通用，但想法是可以借鑒的。
附一下我的代碼結(jié)構(gòu)
image.png
config/：存放期望結(jié)果配置
core/：核心代碼（每次執(zhí)行后，再去生成html報告即可）
report/：本次測試結(jié)果，緩存在這里
static/：html模板，用于生成html報告
