背景簡單交代一下愕难，業(yè)務是廣告平臺早龟，廣告主要展現在C端惫霸，C端每接入一個廣告位需要QA介入測試，主要針對廣告展現葱弟、廣告的pv/click的數據上報壹店。
由于歷史原因，C端并不統(tǒng)一采用sdk方式接入芝加。
由于C端以及廣告平臺均是公司業(yè)務硅卢，cpc廣告才剛剛開始接入，公司并未重視各接入方的收入情況藏杖，以及各種內部廣告及宣傳的融合将塑。
各種原因吧，導致上報數據不準確蝌麸。這個風險性是顯而易見的抬旺。（但總有人對風險視而不見）
臨時抱佛腳的修復，隨著廣告位越來越多祥楣，積攢的問題也會越來越多开财。
有必要分析一番
- 關于上報數據問題：該是C端QA來保證質量還是廣告QA來保證？
理論上廣告QA只需要保證請求展現误褪、pv/click上報接口以及后續(xù)報表的正確责鳍，反作弊系統(tǒng)正常運作∈藜洌可是由于業(yè)務的歷史原因历葛，這個責任落到了廣告QA身上。（其實就是各方PK失敗??）
- 所以廣告QA該做什么呢嘀略？輔助自己或C端QA做上報校驗恤溶，避免讓自己陷入手工重復勞動的漩渦里。
再來分析一番
- 什么樣的需求會用到自動化工具呢帜羊？
（1）新增廣告位
（2）C端優(yōu)化
（3）廣告?zhèn)葟V告引擎優(yōu)化=》影響展現
（4）廣告?zhèn)壬蠄蠓諆?yōu)化
我們來討論一下（1）（2）（4）咒程，（3）可以通過廣告QA接口測試來保證質量，不做贅述讼育。 - 如何做全自動/半自動化工具帐姻？
- 我們是怎么手工測試的呢？
以Android為例奶段，一般通過抓包過濾上報請求饥瓷，校驗上報字段是否正確，再確定廣告?zhèn)嚷鋷斐晒Ρ约瑘蟊碚故菊_呢铆。（一般上報請求數據丟入redis，廣告?zhèn)葟膔edis中取數據做分析落庫等等蹲缠。） - 哪里可以做輔助測試棺克？
（1）如果僅C端有更改鳖宾，廣告?zhèn)葻o更改，那么可以【抓包=》校驗】逆航，無需關注后續(xù)的落庫和數據展示鼎文。
（2）如果僅廣告?zhèn)扔懈膭樱珻端無改動因俐，那么可以在redis中構造不同廣告類型等上報數據拇惋，驗證后端邏輯。
（3）全有改動抹剩，需要做全流程測試撑帖，通過UI自動化，加后端邏輯校驗澳眷，走全流程回歸胡嘿。 - 效率提升？
保守估計钳踊，之前一個廣告位要測試要4小時衷敌，現在1小時內搞定。主要是純手工眼睛會累瞎拓瞪。
今天主要說一下第（1）種方案缴罗，第（2）種很簡單，第（3）種非常復雜祭埂，性價比不高面氓。
輔助打點測試方案：
經過以上分析，針對C端有改動蛆橡，廣告?zhèn)葻o改動情況舌界，方案圖如下image.png通過配置文件來配置需要校驗的數據，抓包泰演，過濾上報請求呻拌，校驗上報字段正確性，做的好看一點可以輸出報告粥血。
還有有幾個小點想提一下：
- 我進了一個頁面柏锄，一下子有10幾條上報數據酿箭，怎么check复亏？
首先你要明確要測試廣告位的上報條數，是上報一條還是多條缭嫡，每條上報是否是一樣的缔御？只需要將自己需要校驗的數據過濾出來并check就可以了 - 期望結果有多個，實際結果只要match上一個就算通過
- 有一些點我們未必可以check的很全妇蛀，比如廣告id耕突，如果每次都有變化笤成，最好用正則去match
選型
沒做什么特別的對比分析，沒什么權威性眷茁，不過可以說用起來還不錯炕泳。
原來想用一個基于nodejs的開源庫，后來還是選擇了mitmproxy上祈，基于python的培遵，選擇自己熟悉的沒錯。
整個程序可以說就是在分析數據登刺，校驗數據籽腕，輸出校驗結果，沒別的了纸俭。整個工程不超過500行代碼皇耗。
由于沒什么代碼沒什么通用性，就不分享代碼了揍很，大家可以動手做起來郎楼，代碼雖不通用，但想法是可以借鑒的窒悔。
附一下我的代碼結構
image.png
config/：存放期望結果配置
core/：核心代碼（每次執(zhí)行后箭启，再去生成html報告即可）
report/：本次測試結果，緩存在這里
static/：html模板蛉迹，用于生成html報告
