一、功能

1. 依托于robotframework
2. 根據代碼注釋，自動生成測試庫
3. 自動搜索測試用例或指定測試用例文件運行
4. commit觸發測試和周期性定時(按天/小時)測試
5. 測試報表統計(區分環境)
6. 企業微信通知測試結果

在此之前，大家要去復習兩個重要的概念，一個是【測試金字塔】模型，

另一個是【基于關鍵字和數據驅動的測試】。

二、自動化測試架構

在這一套自動化測試架構中，代碼注釋起到了核心的作用，背后就是標準化的要求，代碼注釋的格式如下：

基于代碼的comment，能完成如下能力的輸出：

1. Document。我們要自動生成api接口說明文檔，可以依賴此方法生成。
2. 自動化生成服務測試用例。自動根據關鍵字構造自動化測試的方法和用例。

三、根據代碼注釋，自動生成測試庫

指定項目的根目錄，會自動將測試庫寫入到test/library/[項目名].py

如下代碼

注意，如果post/put請求發送的是一個list數據，這里param請寫struct類型。如

@param struct data 

然后測試數據構造data=[{"a": 1}]，框架將會發送[{"a": 1}]作為http body

會自動掃描并生成robotframework的測試庫

使用者，只需要撰寫測試數據即可(數據驅動測試)

四、自動搜索測試用例或指定測試用例文件運行

1. 自動搜索測試用例

根據我們的部署規范，工具會自動搜索/usr/local/easyops目錄下的項目，符合如下要求：

• 文件夾必須是全小寫的
• 文件夾下有test/case目錄

2. 指定測試用例文件

• 可指定測試用例的文件/目錄測試

五、commit觸發測試和周期性定時(按天/小時)測試

1. 工具會自動監聽commit，觸發測試
2. 也可指定每1h或每1d測試

自動觸發流水線執行全流程的驗證，開發、測試和發布亦是如此。

六、測試報表統計

1. 我們提出3個評價指標：

• 成功率：成功的用例個數/ 總的測試用例個數
• 覆蓋率：(keyword總數-未測試的keyword個數)/ keyword總數
• 測試用例指數：測試keyword的測試數據個數的平均。最小是1(每個接口都只有1個測試數據)，希望能達到3~5

2. 測試的結果數據會自動解析并存儲到influxdb，利用grafana來展示

3. 區分環境。我們有162、163、164等開發環境，所有數據都會區分顯示

此時的環境管理非常重要，過去的痛苦之處是如何快速創建和有效管理環境。由于我們的研發模式采用的是git workflow模式，所以能產生大量的特性分支，一個特性勢必對應一個環境。因此會產生大量的開發環境、集成測試和回歸測試環境，必須能夠保證我們服務測試用例和環境能一一對應，且無需人工接入，這一點就大大降低了測試維護的代價和成本。

七. 企業微信通知測試結果

項目的測試成功率小于100%，將會發送到企業微信

八、總結

 

一個完善的自動測試體系背后，是有很多經驗值得分享的：

1. 研發參與測試。我們說的參與測試不是參與測試本身，而是參與測試體系的搭建。研發和測試為了共同的目標，稍作改變，而不是完全依賴后續環境，自動化測試體系構建成本就可以大大降低。
2. 標準化。研發堅持標準化的代碼習慣，基于標準化，傳遞能力給自動化測試過程，效率和質量都能得到保障。
3. 質量意識前置。我們不把“質量當成測試組的職責”，而是把這部分的能力前置到研發階段，共同構建質量保障壁壘。
4. 自動化。我們在開發自動化測試體系的同時，把其能力和平臺流水線能力對接起來，讓執行和接入成本大大降低。
5. 數據化度量。即使建立了完善的測試體系，如果沒有很好的度量，效果依然不會很好，度量***的方式——看板。
6. 閉環。有問題就立即要去解決，讓測試發現的問題閉環起來。

【本文是51CTO專欄作者“王津銀”的原創稿件，轉載請注明出處】

戳這里，看該作者更多好文