DevOps實踐(1)面向服務的全自動化測試體系
一. 功能
- 依託於robotframework
- 根據程式碼註釋,自動生成測試庫
- 自動搜尋測試用例或指定測試用例檔案執行
- commit觸發測試和週期性定時(按天/小時)測試
- 測試報表統計(區分環境)
- 企業微信通知測試結果
在此之前,大家要去複習兩個重要的概念,一個是【測試金字塔】模型,
另一個是【基於關鍵字和資料驅動的測試】,
二. 自動化測試架構
在這一套自動化測試架構中,程式碼註釋起到了核心的作用,背後就是標準化的要求,程式碼註釋的格式如下:
基於程式碼的comment,能完成如下能力的輸出:
1、Document。我們要自動生成api介面說明文件,可以依賴此方法生成。
2、自動化生成服務測試用例。自動根據關鍵字構造自動化測試的方法和用例。
三.根據程式碼註釋,自動生成測試庫
指定專案的根目錄,會自動將測試庫寫入到test/library/[專案名].py
如下程式碼
注意,如果post/put請求傳送的是一個list資料,這裡param請寫struct型別。如
@param struct data
然後測試資料構造data=[{“a”: 1}],框架將會發送[{“a”: 1}]作為http body
會自動掃描並生成robotframework的測試庫
使用者,只需要撰寫測試資料即可(資料驅動測試)
四. 自動搜尋測試用例或指定測試用例檔案執行
- 自動搜尋測試用例
根據我們的部署規範,工具會自動搜尋/usr/local/easyops目錄下的專案,符合如下要求:
a. 資料夾必須是全小寫的
b. 資料夾下有test/case目錄 - 指定測試用例檔案
可指定測試用例的檔案/目錄測試
五. commit觸發測試和週期性定時(按天/小時)測試
- 工具會自動監聽commit,觸發測試
- 也可指定每1h或每1d測試
自動觸發流水線執行全流程的驗證,開發、測試和釋出亦是如此。
六. 測試報表統計
- 我們提出3個評價指標:
成功率:成功的用例個數/ 總的測試用例個數
覆蓋率:(keyword總數-未測試的keyword個數)/ keyword總數
測試用例指數:測試keyword的測試資料個數的平均。最小是1(每個介面都只有1個測試資料),希望能達到3~5 - 測試的結果資料會自動解析並存儲到influxdb,利用grafana來展示
此時的環境管理非常重要,過去的痛苦之處是如何快速建立和有效管理環境。由於我們的研發模式採用的是git workflow模式,所以能產生大量的特性分支,一個特性勢必對應一個環境。因此會產生大量的開發環境、整合測試和迴歸測試環境,必須能夠保證我們服務測試用例和環境能一一對應,且無需人工接入,這一點就大大降低了測試維護的代價和成本。
七. 企業微信通知測試結果
專案的測試成功率小於100%,將會發送到企業微信
八. 總結
一個完善的自動測試體系背後,是有很多經驗值得分享的:
1、研發參與測試。我們說的參與測試不是參與測試本身,而是參與測試體系的搭建。研發和測試為了共同的目標,稍作改變,而不是完全依賴後續環境,自動化測試體系構建成本就可以大大降低。
2、標準化。研發堅持標準化的程式碼習慣,基於標準化,傳遞能力給自動化測試過程,效率和質量都能得到保障。
3、質量意識前置。我們不把“質量當成測試組的職責”,而是把這部分的能力前置到研發階段,共同構建質量保障壁壘。
4、自動化。我們在開發自動化測試體系的同時,把其能力和平臺流水線能力對接起來,讓執行和接入成本大大降低。
5、資料化度量。即使建立了完善的測試體系,如果沒有很好的度量,效果依然不會很好,度量最好的方式——看板。
6、閉環。有問題就立即要去解決,讓測試發現的問題閉環起來。