Dev for Dev 專欄全稱為 Developer for Developer，該專欄是聲網與 RTC 開發者社群共同發起的開發者互動創新實踐活動。透過工程師視角的技術分享、交流碰撞、專案共建等多種形式，匯聚開發者的力量，挖掘和傳遞最具價值的技術內容和專案，全面釋放技術的創造力。
本文為專欄系列內容，作者為聲網音視訊實驗室工程師孫勇男。
什麼是測試自動化框架
測試自動化框架是為自動化測試用例或者指令碼提供執行環境而搭建的基礎設施。自動化測試框架為使用者提供了各種好處，可幫助他們有效地開發、執行和報告自動化測試用例。自動化測試框架更像是專門為自動化測試而建立的一套系統。用一種非常簡單的語言，也可以說框架是各種編碼標準、測試過程、工作實踐、專案層次結構、模組化、報告機制、測試資料注入等支援自動化測試的功能的極大融合。
自動化測試框架的型別
現在我們對自動化框架有了基本的瞭解，讓我們看一下現在流行的各種型別的測試自動化框架。這些框架可能基於對不同關鍵因素（例如驅動型別、可重用性、易於維護等）進行自動化的支援而彼此不同。
● 基於模組的自動化測試框架
● 倉庫架構自動化測試框架
● 資料驅動自動化測試框架
● 關鍵字驅動自動化測試框架
● 黑盒混合自動化測試框架
● 行為驅動自動化測試框架
為什麼選用黑盒混合自動化測試框架測試 SDK
所謂黑盒，即提供給業務測試人員無需考慮程式內部結構和內部特性的情況下，在程式介面輸入測試的引數並選擇輸出項，通過程式內部混合測試框架得到相應的結果，使用者只需關心輸入與輸出。
場景設計初衷
"自動化是為了更好的解放雙手，追求更高的效率"
與網際網路軟體(app、web)的測試有所不同的是，簡單來說實時視訊SDK測試幾乎不需要點點點，基本是通過自研自動化工具完成端與端間經過自定義網路損傷後的視訊通訊，並採集端上 SDK log 作為測試產出資料，客觀測試資料即客觀測試結果。圍繞並以此通過結合實際業務需求，去離"Code based automation"，根據業務測試以平臺化、模組化來提供解決方案，從而提供更多的測試維度、減少重複體力勞動和效率瓶頸問題。
01 解決方案架構簡述
基礎建設方案
● 採用 CI 叢集+測試工具及自動化測試框架 +資料平臺化
支撐 daily、發版測試、開發自測的測試工作
● 具體模組功能簡述
落地機房實景
● 多套測試節點支撐整個視訊客觀發版業務線
02 基於自動化測試維度的思考簡述
逐步完善自動化閉環
通常我們在做自動化測試過程中通常先完成“執行測試”這一步驟，然而這只是相對自動化的一部分，我個人理解的自動化閉環優點不侷限於"輸入便捷性靈、測試覆蓋性全、測試避障性強、輸出聚合性高"，更多的站在整個鏈路逐步突破測試精準性和效率瓶頸。
下面是我們在測試避障性和輸出聚合性模組中的舉例:
舉例1 時段網路波動影響
在生活中使用聊天軟體視訊時，往往會因為網路突發波動造成突然的卡頓或者或者畫面模糊，波動幅度和時間都具有不確定性，對於實時視訊 SDK 的測試也會遇到這樣的問題，雖然我們盡力保證網路環境的穩定，但是在長時間的測試過程中也經常會遇到諸如此類問題，影響我們的測試資料。
如何在測試過程中降低因網路波動造成的資料誤差？
● 利用漏斗式重跑篩選方式，簡要結構如圖所示
即迴圈求值保證在設定誤差內有效降低因為網路波動影響 SDK 版本測試資料。
舉例2 版本資料波動影響力採據
在完成自動化測試後對於測試版本間或者與 release 版本各項體驗指標資料上，一般是通過報告間數字的差異，但隨著體驗指標的增加，往往我們更迫切需要多個版本精確到端到端上某個指標上的差異性感知質量視覺化。
● 後臺管理系統-客觀報告模組
支援多版本報告對比的case、devices、體驗指標等求值動態檢視
目前這種客觀報告的檢視形式雖然暫時滿足了我們對自動化報告指標資料上的取證對比需求，但是在資料的梳理和合成功能還需要更加切入業務的理解。
03 總結
相對不同業務的框架並沒有什麼官方的標準，而是緊貼實際業務需求，搭配適用性高的主流框架或者自研框架整合到整個測試架構來提供解決方案。操作者可能為開發可能為測試，大家技術線有所不同，作為相對"黑盒"使用者暫不需要知道他的原理構造，僅需清楚瞭解能為自己在最短時間解決工作上的問題即是黑盒測試框架的價值。