一. 功能

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目錄下的專案，符合如下要求：
   a. 資料夾必須是全小寫的
   b. 資料夾下有test/case目錄
2. 指定測試用例檔案
   可指定測試用例的檔案/目錄測試

五. commit觸發測試和週期性定時（按天/小時）測試

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

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

六. 測試報表統計

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

   成功率：成功的用例個數/ 總的測試用例個數
   覆蓋率：（keyword總數-未測試的keyword個數）/ keyword總數
   測試用例指數：測試keyword的測試資料個數的平均。最小是1（每個介面都只有1個測試資料），希望能達到3~5

2. 測試的結果資料會自動解析並存儲到influxdb，利用grafana來展示

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

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

專案的測試成功率小於100%，將會發送到企業微信

八. 總結

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

1、研發參與測試。我們說的參與測試不是參與測試本身，而是參與測試體系的搭建。研發和測試為了共同的目標，稍作改變，而不是完全依賴後續環境，自動化測試體系構建成本就可以大大降低。

2、標準化。研發堅持標準化的程式碼習慣，基於標準化，傳遞能力給自動化測試過程，效率和質量都能得到保障。

3、質量意識前置。我們不把“質量當成測試組的職責”，而是把這部分的能力前置到研發階段，共同構建質量保障壁壘。

4、自動化。我們在開發自動化測試體系的同時，把其能力和平臺流水線能力對接起來，讓執行和接入成本大大降低。

5、資料化度量。即使建立了完善的測試體系，如果沒有很好的度量，效果依然不會很好，度量最好的方式——看板。

6、閉環。有問題就立即要去解決，讓測試發現的問題閉環起來。