如何設計一個自動化測試平臺

之前寫過很多自動化測試相關的文章,後臺有同學留言:希望寫一篇自動化測試平臺的文章。

他的原話是這樣:目前市場上開源或者商業的自動化測試平臺很多,但試用下來總感覺有些地方不太融洽,想自己落地一個適合自己團隊和項目的自動化測試平臺。

這種想法在我看來很正常,商業平臺要考慮普適性,會大而全,也會存在客製化的訴求;而開源平臺更多的是作者結合自己的經驗做出來的,個人風格較爲強烈。且每個團隊的技術建設、項目迭代、流程規範以及人員各有區別,很難有完全適配的自動化測試平臺。

這篇文章,我會以自己的實踐經驗結合業內部分優秀平臺的設計理念,聊聊我對於設計自動化測試平臺的一些想法。

 

平臺解決了什麼問題

去年曾寫過一篇文章專門聊過測試平臺的作用和價值,詳情見:《測試平臺解決了什麼問題》。以此爲例,先聊聊自動化測試平臺的作用和價值。

一般在企業內,技術團隊如果規模比較小,很少會專門投入資源去做平臺化的事情,特別是測試團隊,無論是成本預算還是技術能力,先天技術能力不足,後天可投入的資源缺乏。

而平臺的特點在於:通過平臺將操作流程標準化,抹平不同個體間的認知和技術差異,減少重複造輪子帶來的的資源浪費以及排查和解決問題的成本,進一步提高人效比

大白話來說,就是人太多了,理解能力和技術差異太大,沒那麼多時間和資源浪費在不斷造輪子和來回對比扯皮上,直接平臺化,標準化,通過權限管理來標註操作的邊界,保證大家按照同一個方向和目標甚至度量標準去做事情

技術本身的實踐、迭代和演進是一個過程,從軟件工程的角度來說,測試平臺就是“只做剛剛好的設計”、“先做MVP方案然後不斷迭代小步快跑”這些很好的軟件工程實踐理念某個階段的產物。

當然,言必稱平臺,動則擼代碼的方式,也有企業發展和個人職場生存之間的博弈成分在內。

 

測試平臺的功能架構

回到本文的正題,要設計一個自動化測試平臺,最基本也是最核心的功能有如下幾點:

  • 文件管理:腳本、數據的上傳/下載、格式校驗等功能;
  • 任務管理:測試任務創建、更新、刪除、批次管理
  • 任務調度:測試任務執行,定時/觸發等靈活的調度策略;
  • 報表統計:主要包括場景、用例、任務、報告、狀態等維度的數據彙總;
  • 監控日誌:包含測試任務的執行狀態、時間、異常以及告警通知等功能;
  • 節點管理:執行器(node節點)的調度、配置、狀態、插件、驗籤等功能;
  • 系統設置:用戶權限、項目權限、插件管理等;
  • mock功能:隔離上下游依賴,確保任務執行的可靠性,避免外部影響;

當然,上述的功能模塊是相對比較通用的,在團隊內部落地時,可以根據自身具體情況進行擴展。綜合上述的功能模塊,自動化測試平臺的功能架構,可以用下面一張圖來概括(僅做示意和參考):

 

測試平臺的技術架構

聊完了功能架構,接下來聊聊技術架構。

在我看來功能架構的設計和功能模塊的劃分其實是很抽象的一件事,相比於技術架構,功能架構其實更爲重要。好比與一個產品的好壞其實更多的取決於如何設計,而不是用了java還是PHP。

自動化測試平臺的技術架構,大致可用下圖來概括(僅做示意和參考):

技術架構大致的調用關係和組件作用如下:

  • 通過UI界面進行編輯和下發任務執行消息,一般採用http協議通信;
  • 執行引擎支持多協議和規則格式等校驗,將任務信息推送給node集羣;
  • 從gitlab中獲取對應的自動化腳本,並推送到具體的node節點來執行任務;
  • 從 S3 或其他文件管理組件中獲取對應測試數據文件,並推送到node節點;
  • 通過任務調度組件比如 xxjob 來進行具體的任務分配執行,以及狀態管理;
  • 任務執行過程產生的日誌存儲於es中,通過集成elk組件來做日誌管理和展示;
  • 任務執行完成後產生的報告數據,以及項目/場景/用例/配置等冷數據存儲於mysql;
  • node節點內置listener,負責將任務狀態和資源耗用等數據通過kafka推送到工作臺展示;

上圖所展示的技術架構和相關組件,僅做參考。

 

在實際的技術選型過程中,還是需要根據團隊自身的技術棧以及需求靈活選擇合適的方案。

相比於自動化測試平臺,我們常說的自動化測試框架,就顯得很簡單了。只需要編程語言+測試框架+持續集成工具+測試報告工具,就能完成基本的自動化測試工作。

平臺並不是萬能的,平臺相比於最基本的自動化測試框架,也並沒有什麼優越性。根據團隊的需求,技術能力以及資源預算選擇合適的解決方案,纔是最優解。

自動化測試的重點並不是平臺,也不是選擇什麼高大上的框架。重點是,先讓測試任務本身run起來,能快速的驗證和反饋結果,纔是最重要的。

 

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章