背景簡(jiǎn)單交代一下，業(yè)務(wù)是廣告平臺(tái)，廣告主要展現(xiàn)在C端，C端每接入一個(gè)廣告位需要QA介入測(cè)試，主要針對(duì)廣告展現(xiàn)、廣告的pv/click的數(shù)據(jù)上報(bào)。
由于歷史原因，C端并不統(tǒng)一采用sdk方式接入。
由于C端以及廣告平臺(tái)均是公司業(yè)務(wù)，cpc廣告才剛剛開始接入，公司并未重視各接入方的收入情況，以及各種內(nèi)部廣告及宣傳的融合。
各種原因吧，導(dǎo)致上報(bào)數(shù)據(jù)不準(zhǔn)確。這個(gè)風(fēng)險(xiǎn)性是顯而易見的。（但總有人對(duì)風(fēng)險(xiǎn)視而不見）
臨時(shí)抱佛腳的修復(fù)，隨著廣告位越來(lái)越多，積攢的問(wèn)題也會(huì)越來(lái)越多。

有必要分析一番

1. 關(guān)于上報(bào)數(shù)據(jù)問(wèn)題：該是C端QA來(lái)保證質(zhì)量還是廣告QA來(lái)保證？
   理論上廣告QA只需要保證請(qǐng)求展現(xiàn)、pv/click上報(bào)接口以及后續(xù)報(bào)表的正確，反作弊系統(tǒng)正常運(yùn)作?？墒怯捎跇I(yè)務(wù)的歷史原因，這個(gè)責(zé)任落到了廣告QA身上。（其實(shí)就是各方PK失敗??）

• 所以廣告QA該做什么呢？輔助自己或C端QA做上報(bào)校驗(yàn)，避免讓自己陷入手工重復(fù)勞動(dòng)的漩渦里。

再來(lái)分析一番

1. 什么樣的需求會(huì)用到自動(dòng)化工具呢？
   （1）新增廣告位
   （2）C端優(yōu)化
   （3）廣告?zhèn)葟V告引擎優(yōu)化=》影響展現(xiàn)
   （4）廣告?zhèn)壬蠄?bào)服務(wù)優(yōu)化
   我們來(lái)討論一下（1）（2）（4），（3）可以通過(guò)廣告QA接口測(cè)試來(lái)保證質(zhì)量，不做贅述。
2. 如何做全自動(dòng)/半自動(dòng)化工具？

• 我們是怎么手工測(cè)試的呢？
  以Android為例，一般通過(guò)抓包過(guò)濾上報(bào)請(qǐng)求，校驗(yàn)上報(bào)字段是否正確，再確定廣告?zhèn)嚷鋷?kù)成功，報(bào)表展示正確。（一般上報(bào)請(qǐng)求數(shù)據(jù)丟入redis，廣告?zhèn)葟膔edis中取數(shù)據(jù)做分析落庫(kù)等等。）
• 哪里可以做輔助測(cè)試？
  （1）如果僅C端有更改，廣告?zhèn)葻o(wú)更改，那么可以【抓包=》校驗(yàn)】，無(wú)需關(guān)注后續(xù)的落庫(kù)和數(shù)據(jù)展示。
  （2）如果僅廣告?zhèn)扔懈膭?dòng)，C端無(wú)改動(dòng)，那么可以在redis中構(gòu)造不同廣告類型等上報(bào)數(shù)據(jù)，驗(yàn)證后端邏輯。
  （3）全有改動(dòng)，需要做全流程測(cè)試，通過(guò)UI自動(dòng)化，加后端邏輯校驗(yàn)，走全流程回歸。
• 效率提升？
  保守估計(jì)，之前一個(gè)廣告位要測(cè)試要4小時(shí)，現(xiàn)在1小時(shí)內(nèi)搞定。主要是純手工眼睛會(huì)累瞎。

今天主要說(shuō)一下第（1）種方案，第（2）種很簡(jiǎn)單，第（3）種非常復(fù)雜，性價(jià)比不高。

輔助打點(diǎn)測(cè)試方案：

經(jīng)過(guò)以上分析，針對(duì)C端有改動(dòng)，廣告?zhèn)葻o(wú)改動(dòng)情況，方案圖如下

image.png

通過(guò)配置文件來(lái)配置需要校驗(yàn)的數(shù)據(jù)，抓包，過(guò)濾上報(bào)請(qǐng)求，校驗(yàn)上報(bào)字段正確性，做的好看一點(diǎn)可以輸出報(bào)告。

還有有幾個(gè)小點(diǎn)想提一下：

1. 我進(jìn)了一個(gè)頁(yè)面，一下子有10幾條上報(bào)數(shù)據(jù)，怎么check？
   首先你要明確要測(cè)試廣告位的上報(bào)條數(shù)，是上報(bào)一條還是多條，每條上報(bào)是否是一樣的？只需要將自己需要校驗(yàn)的數(shù)據(jù)過(guò)濾出來(lái)并check就可以了
2. 期望結(jié)果有多個(gè)，實(shí)際結(jié)果只要match上一個(gè)就算通過(guò)
3. 有一些點(diǎn)我們未必可以check的很全，比如廣告id，如果每次都有變化，最好用正則去match

選型

沒(méi)做什么特別的對(duì)比分析，沒(méi)什么權(quán)威性，不過(guò)可以說(shuō)用起來(lái)還不錯(cuò)。
原來(lái)想用一個(gè)基于nodejs的開源庫(kù)，后來(lái)還是選擇了mitmproxy，基于python的，選擇自己熟悉的沒(méi)錯(cuò)。

整個(gè)程序可以說(shuō)就是在分析數(shù)據(jù)，校驗(yàn)數(shù)據(jù)，輸出校驗(yàn)結(jié)果，沒(méi)別的了。整個(gè)工程不超過(guò)500行代碼。

由于沒(méi)什么代碼沒(méi)什么通用性，就不分享代碼了，大家可以動(dòng)手做起來(lái)，代碼雖不通用，但想法是可以借鑒的。

image.png

config/：存放期望結(jié)果配置
core/：核心代碼（每次執(zhí)行后，再去生成html報(bào)告即可）
report/：本次測(cè)試結(jié)果，緩存在這里
static/：html模板，用于生成html報(bào)告

干貨送給大家，喜歡點(diǎn)贊??