知乎用戶端目前實行單周發版，每個版本都需要經曆開發自測、産品驗收、QA 回歸等階段。商業廣告存在大量的廣告位和模闆，測試時無法線上上刷全所有廣告樣式。早期離線準備了所有廣告 Mock 資料，驗收過程中存在如下痛點：
- 研發、QA 使用的離線 Mock 資料不統一，溝通成本高，操作複雜
- 研發和 QA 各自在本地維護 Mock 資料，使用 Charles 的 Map Local 功能進行資料替換。各自維護資料存在資料不一緻、資料時效性低的問題。複現 bug 時經常因為資料不一緻 導緻表現不一緻，徒增溝通成本。
- 人工維護的 Mock 資料，在進行異常情況測試時需要頻繁修改資料，容易出現改錯資料，誤報 bug 的情況。
- 視訊等資料存在過期校驗，使用本地 Mock 資料，每次都需要重新生成有效視訊連結，步驟複雜，浪費大量時間。
-
測試門檻高
所有參與項目驗收的同學，都需要學習 Charles 的使用方法，手機安裝 SSL 證書，了解每一份本地 Mock 資料的用途。
-
線上驗收耗時長
進行線上驗收時，需要從廣告投放系統建立測試的合同、訂單、廣告，廣告稽核通過後，才能線上上刷到。流程過長，準備工作較為繁瑣。
-
埋點驗收複雜
廣告埋點都經過了加密處理，QA 驗收時，需要解密每一條埋點資訊，才能确認埋點是否正确。除此之外，商業廣告埋點資料發送到生産環境埋點統計服務，自動化無法實時擷取埋點統計資料，導緻商業廣告用戶端自動化無法校驗埋點。
為了解決上述問題，知乎商業化品質保障團隊設計實作了用戶端工作台 —— Simba。在此工作台上，所有項目組成員可以通過掃描廣告二維碼預覽到線上所有廣告位的所有模闆 / 樣式；也可以通過在工作台上勾選、編輯需要測試的廣告模闆資料（後文稱基準資料）進行精細化測試；測試過程中埋點資料自動分析統計，工作台實時展示廣告的各種類型埋點數量。同時，Simba 還提供廣告素材接口給用戶端自動化測試服務，廣告素材庫更新後，無需修改用戶端自動化用例代碼，實時更新廣告素材。工作台原理如下。
工作台原理
預覽
工作台從業務資料庫擷取廣告 id 、創意 id 等字段，按照預覽連結規則拼湊成 Schema 連結并生成二維碼。用戶端掃描二維碼後路由到相應的廣告頁面，在請求 Header 中寫入預覽連結，給後端發送廣告請求。開屏、問答、首頁等後端服務，透傳預覽連結到廣告引擎。廣告引擎根據請求 Header 中的預覽連結傳回指定廣告。如圖一所示。
圖一 廣告預覽原理圖
多使用者代理
除了上述掃描二維碼進行廣告實時預覽的方式，工作台還提供了代理服務和基準資料，供驗收人員修改廣告資料，進行更詳細的測試。日常工作中，需滿足多人同時驗收的場景，是以，工作台引入了 Mitmproxy 實作多使用者代理。每個使用者在工作台上擷取、使用專有的代理服務，請求和傳回互不幹擾，如圖二所示。Mitmproxy 可攔截請求、響應，并對其進行修改，同時提供指令行工具 Mitmdump 。啟動 Mitmdump 服務時通過添加 -s 參數加載腳本對接收到的請求進行定制化操作，然後傳回響應資料。添加 -H 參數為代理的請求添加 Header 來區分使用者。
圖二 多使用者代理
以上就是工作台的主要原理，接下來介紹下工作台的架構和實作。
工作台架構
工作台前端使用 React + AntD 實作，共有 3 個子產品，分别是預覽、mock、代理 (mitmproxy)。
工作台後端使用 Python Flask 架構，共有 4 個子產品，分别是預覽、定時任務（基準資料）、mock、代理 (mitmproxy)。
圖三 工作台架構
下面我們詳細介紹一下 4 個主要子產品。
預覽
QA 在生産環境建立一批測試廣告，置為已拒絕狀态，對生産環境無影響。工作台後端通過各廣告位預覽請求拼接規則生成 Scheme 連結，存儲在工作台資料庫中。工作台前端展示預投的廣告素材及 Schema對應二維碼。使用者可根據廣告位、廣告子產品、廣告樣式快速篩選需要驗收的廣告，使用知乎用戶端掃碼功能即可跳轉到指定廣告頁面，驗收指定廣告。如圖四所示。
圖四 廣告預覽
基準資料生成
1、基準資料定時器：工作台後端根據預覽子產品預存的 Schema 連結，以及通過代理服務獲得的生産環境廣告請求 Header，每天定時模拟廣告請求，獲得廣告響應資料，儲存在工作台資料庫中作為基準資料。當響應字段發生更改時，更新基準資料。
2、視訊資料更新定時器：工作台從所有的 Schema 連結中篩選出視訊類廣告的預覽連結，在基準資料和使用者資料中篩選出通過上述 Schema 傳回的廣告，根據視訊 id 重新獲得視訊連結，定時更新工作台視訊基準資料。
3、廣告落地頁實時更新：在進行不同類型廣告落地頁測試時，工作台提供了基準資料指定字段 value 值替換功能。這樣驗證 10 個不同的落地頁類型，隻需要儲存一份基準資料，另外預設 10 個落地頁值即可，降低基準資料維護成本。
Mock
Mock 子產品提供基準資料複制、基準資料開啟、請求 Header 校驗和埋點統計等功能。
1、基準資料複制：如前所述，基準資料定時更新為線上最新的接口傳回，保證了資料的時效性。驗收人員開始一輪測試時，可以複制一份基準資料到個人目錄，作為自己的 Mock 資料，然後進入個人目錄，勾選特定的資料進行測試。如圖五所示。
圖五 Mock 資料子產品
2、基準資料開啟：工作台接收到 Mitmdump 發送的廣告請求時，檢查 Mock 資料是否啟用，如啟用傳回使用者開啟的基準資料；否則，使用 Header 中儲存的原始資料建構請求發送至目标服務。
3、請求 Header 校驗：請求的 Header 出錯時，會導緻傳回的廣告資料不符合預期。而 Header 的檢查字段多且容易遺忘，為此工作台提供了自動檢查功能。對轉發到工作台的所有請求，進行 Header 重要字段校驗，在工作台上實時顯示校驗結果。如圖六所示。
圖六 請求 Header 校驗
4、埋點統計：工作台接收到 Mitmdump 發送的埋點請求時，解析請求的 Header 和請求 Url 中的參數，并進行解密，将獲得的資訊以廣告為次元彙總并存入資料庫。工作台前端按照廣告位、廣告、曝光數、點選數等次元，統計目前展現的廣告的關鍵埋點資料，如圖七所示。
圖七 埋點統計子產品
5、用戶端 UI 自動化用例接口：自動化測試通過 Scheme 打開廣告所在頁面對廣告進行操作，工作台自動化用例接口接收廣告位 id，将此廣告位的全部 Scheme 進行樣式去重後傳回給自動化進行測試。
6、自動化埋點校驗接口：編寫自動化用例時在 Scheme 後添加強定參數，形如：Key = 工作台 Host : 工作台 Port / 工作台路由。引擎端識别關鍵字「Key」獲得工作台埋點請求的接收位址，并将此位址添加到廣告的第三方監控連結中。這樣廣告發生曝光、點選時，工作台就會接收到廣告的埋點請求，調用上文埋點統計功能對請求進行處理。如果 Scheme 中無關鍵字 Key 則引擎不會有任何特殊操作，是以對正常廣告沒有影響。在自動化需要驗證埋點資料時，請求工作台自動化埋點校驗接口擷取廣告曝光數、點選數等進行斷言。
Mitmproxy
Mitmproxy 子產品用來過濾、轉發請求。使用者啟動的 Mitmdump 服務在後端伺服器上，對使用者無感覺，且不依賴本地環境。每個使用者使用自己的 Mitmdump 代理服務，是以每個使用者之間任何操作都不受影響。如圖八所示。
1、啟動 Mitmdump 時增加參數為此代理接收到的請求增加 Header ，如 Port 用來标記請求，供後端識别請求所對應的使用者。
2、增加參數來指定腳本，腳本可以選擇性的攔截請求（廣告請求、埋點請求等），攔截後修改請求的 Host、Port、Path、Schema，将請求轉發到 Mock 子產品，同時增加 Header 用來儲存請求原始資料，供後續使用。
圖八 代理子產品
總結
知乎商業測試工作台，為解決線上全量廣告卡片模闆驗收應運而生，目前廣泛應用在樣式驗收、開發自測、版本回歸等場景，極大的加快了測試的進度，縮短測試時間。通過和用戶端 UI 自動化結合，自動截圖全量樣式，極大的便利了設計師驗收，設計師驗收效率提升 4 倍。版本內建回歸時間已從 6 小時減至 4 小時。目前平台持續接收産品、開發的需求進行疊代，為商業品質保障提供有力支援。
作者:wmaidouw
出處:https://zhuanlan.zhihu.com/p/70876764