談談最近做的一個自動化平臺(二)

語言: CN / TW / HK

微信搜尋【大奇測試開】,關注這個堅持分享測試開發乾貨的傢伙。

繼上次 《談談最近做的一個自動化平臺》 一個多月的時間裡,這個平臺又有了不少迭代功能,就再來談一談。

迭代功能

從大的需求方面有兩處一個是  Dashboard ,這塊主要是團隊負責人比較關注的層面,他(她)們需要看一些度量資訊和趨勢變化。

[迭代圖1]包含兩份資料,

  • 平臺的概覽資料:其中包括繫結的專案數,平臺排程執行數(包含手動觸發和定時觸發),還有近一個月的累計數和通過率。

  • 日構建成功率:儀表盤檢視專案當然執行和通過率情況,其中展示了當天多次執行的次數,最高(左),最低(右),平局(儀表盤)

這裡的儀表盤採用了紅黃綠燈,目前根據專案定的通用條件是,綠燈>=95%,黃燈>70%,紅燈<=70%

[迭代圖2]趨勢圖表示30天內每日平均通過率,主要看某個專案通過率是否穩定,是否有某個點的異常情況,以及可以對比出哪個團隊自動化做的比較好。圖中因為專案多,目前各個團隊自身指令碼不穩定+多套微服務的測試環境不穩定因素導致了線亂,隨著各方面的穩定,理想的趨勢線應該是圍繞90%~100%區域呈現。

[迭代圖3]對應上邊趨勢圖,使用堆疊柱狀圖展示當天執行測試業務的自動化用例數量(去重)以及累計數量,在全量定時全部配置的情況下,反應當天覆蓋率,以及自動化CASE的增長變化。

畫重點,上邊這些圖表最終使用的是G2Plot元件,官方的描述是開箱即用、易於配置、具有良好視覺和互動體驗的通用統計圖表庫。一開始我調研的其實是ECharts,但從原始資料結構簡單性上來說確前者更容易上手,這兩個組建庫的使用方式我也將在《提測平臺》系列的最後一節報表實現中具體講講。

另一需求是  快捷操作   功能,這塊主要來自測試同學的較多的反饋需求,之前的進入程式碼管理執行計劃,入口稍微有點深,在快速執行和推動研發自測執行的時候不方便,所以增加一個集快速選擇執行和合並狀態展示功能。

[迭代圖4]新增我的快捷管理,在頭部選擇專案、計劃、環境便可立即執行,並支援收藏專案優先展示和快速進入專案管理,執行歷史將彙集任務&報告集合在一起進行展示和功能操作,這項功能大大提高了使用率和組外的推廣效果。

[迭代圖5]展示是在原有每日定時基礎上增加了Cron自定義定時,另外這塊定時任務後端實現也從python apscheduler 遷移到了xxljob,開源XXL-JOB是一個分散式任務排程平臺,原始碼是兩個JAVA工程專案,部署容易可以二次開發,這個找個時間可以寫個教程分享出來,提前瞭解可參考官網https://www.xuxueli.com/。

迭代的內容只挑選幾個變動比較大地方,其他互動優化/BUG修復/小需求就不在這裡討論了。

平臺打通

團隊內部用例平臺上有個轉測單功能,主要是做測試流程管理和質量的卡點,其中對於某個需求可以設定在狀態轉變的時候觸發自動化測試,然後收到自動化測試平臺的執行完的回撥結果,根據通過率決定卡點過不過,比如研發提測通過率大於95%才可以進入下一階段,否則直接通知打回,這是其中一個平臺打通功能。

到這裡以為就結束了嗎?不不不,每天10個小時的高效不會只產出這些的,還有個年後的計劃被提前的並行開發的大需求在週期內完成了...

單介面測試

類Postman介面化的單介面web,團隊維度介面和用例資料共享,目的還是根據公司內部和業務特性降低介面自動化門檻和統一框架與流程,為什麼平臺一開始就上這個功能,原因在第一篇的有提到過,就是快速將已有分散的自動化統一起來,引導大家平臺使用,再有一定依賴度和更多的需求下,推出這個更易用版的介面化配置功能更容易切換,其實簡單的說更容易讓平臺的得到推廣和使用起來,看一看多少公司很多類似平臺除了為了完成KPI和晉級PPT,易用性、實用性、推廣性有多難做。

[單介面圖1]展示了核心的頁面架構,需求設計和實現上主要參考了現在個人認為比較不錯的一個可協同ApiFox平臺,參考就了參考了不避諱,官方的定位 Apifox = Postman + Swagger + Mock + JMeter,相比Postman和Yapi平臺確實是一個服務端做介面管理的不錯軟體工具,感謝這麼好的一個工具,想體驗的可以直達官方https://www.apifox.cn/ 瞭解詳情。

由於是第一個內部測試板,功能沒有上太多,主要是Http介面陪著和CASE管理的基礎功能,以及一種Json格式的校驗能力,展示上已樹的形式全部展示,便於操快捷操作,這也是重點參考ApiFox的地方。

[單介面圖2]是環境管理,這個根據一個業務團隊有多個微服務的特點是支援了一套環境下支援多個HOST配置,同時是支援部署平臺內Docker服務ID的直接呼叫。

[單介面圖3]演示的是個POST介面用例請求,有請求引數和返回引數+配置的斷言結果,內部基本除了Dubble就是標準HTTP的GET/POST請求,所以優先上的此功能。

[單介面圖4]配套的用例集管理,主要是建立測試計劃進行測試執行。

[單介面圖5]和上邊迭代中的快捷操作頁面類似,是集任務排程,報告彙總和快捷執行為一體的“執行報告”管理頁面,目前還只是作為狀態展示和查詢的一個簡單頁面。

[單介面圖6]報告部分結果儲存與自動化的報告使用的是一個總表,詳細表是兩表,但展現形式上差不多,所以頁面採用的是一個樣式,包括飛書的訊息通知都是一套,只是在個別欄位和邏輯處理上加了相容性。

對於單口測試還只是個初版,這部分也 畫個重點 ,前端很多是要定製化所以頁面實現是由組內前端同學共同開發而成的,後端技術上,請求邏輯斷言等處理是利用Python requests庫、eval函式和jsonpath庫實現了核心邏輯。

隨著迭代這部分功能應該也會越來豐富,但絕不是重複造輪子再寫個WEB版的Postman,而是打造一個符合質量團隊需求,適應業務形態的提升測試質量的效率平臺,後續規劃上短期和長期會有如下一些打算:

  • 增加Dubble的請求

  • 全域性/自定義變數定義

  • 前置處理/後置處理

  • 資料庫的配置和使用

  • 內建和自定義預處理指令碼

  • 用例管理支援場景化配置即上下文

  • 更多http格式請求&返回處理

  • 更多斷言的方式的處理

  • 高階指令碼功能支援

  • ...

關於後續更多進展和分享歡迎持續關注公眾號或部落格。