測試平臺之接口自動化平臺
前言
接口自動化，與UI自動化相比，其維護成本更低，結果校驗更精確。目前，接口自動化無論是使用testng框架者還是使用Jmeter，都有一定的侷限性，前者需要一定代碼基礎，且維護測試數據比較麻煩，後者簡單易用，但共享性差一些。基於此，從前端選型、數據庫表設計到實現方案設計與開發，我花費三個月時間完成了這個接口自動化測試平臺。
2020年5月31日開源第一個版本：GitHub項目地址，如果覺得有所幫助的話，請給項目點個star，給我更多繼續完善下去的動力！
第一個版本問題還挺多的，想補充完善的點也很多，比如權限管理的完善（目前完成度70%吧）、定時任務、郵件發送等模塊。歡迎提出寶貴意見。
1 簡介
1.1 技術棧
- 後端：SpringBoot + Mybatis + mysql + redis
- 前端：jQuery + layui
關於前端，個人推薦沒有前端基礎的同學，可以從layui上手。後期視情況向vue靠攏，畢竟vue是目前主流的前端開發框架，在我們遇到問題時，如果使用和前端開發相同的框架，可以非常方便地向他們請教。
1.2 特點
- 極致簡潔：頁面簡潔，交互方便，易於上手
- 數據管理：可視化數據管理，數據的添加與維護十分方便
- 分級設計：將數據按項目模塊、接口、用例、測試集合劃分，保證數據規範性和一致性，減少數據冗餘
- 單點調試：支持接口測試用例的在線調用，輸出響應結果、請求信息等詳細信息
- 流程拼裝：將多個已創建的測試用例拼接成測試集合，執行有一定業務邏輯的流程
2 詳述
2.1 權限管理設計
經典的樹狀角色權限控制：
在角色控制之外，又單獨爲各個模塊，比如接口自動化模塊設計了組別權限：
新增數據與編輯數據相比，少了是否是本人數據的校驗。
爲組分配（增減）人員：
爲組分配（增減）項目：
權限不足效果：
2.1 平臺入口
登錄頁面使用Spring主題，清新雅緻。不支持註冊用戶，只能由管理員添加用戶。
平臺集成了redis，token信息存儲在redis中，並可在配置文件中自定義失效時間和加密規則：
redis:
host: localhost
port: 6379
timeout: 10s
lettuce:
pool:
min-idle: 0
max-idle: 8
max-active: 8
max-wait: -1ms
password:
token:
expire:
seconds: 72000
jwtSecret: (XIAO:)_$^11244^%$_(WEI:)_@@++--(LAO:)_++++_.sds_(SHI:)
2.2 分級設計
前面提到，接口自動化平臺數據採用分層設計，即將接口自動化所需的數據分爲【項目管理】、【接口列表】、【用例管理】、【測試集合】、【測試結果】五個部分。如下圖所示：
2.2.1 項目管理
項目管理，定義了公司系統的基本框架。以新浪新聞爲例，我將做如下分割：
- 平臺：新浪新聞
- 項目：體育
- 模塊：西甲
- IP地址：略
項目模塊層，有以下規範和特點：
- 項目管理頁面決定了每個接口的歸屬，當我們新增接口時，必須創建在已有模塊下，而不能隨心所欲地添加。因爲平臺使用人衆多，如果不做此約束，數據將會十分混亂。
- 通常情況下，每個項目對應着自己的IP地址。這個平臺中，每個模塊對應着一個IP地址，還是有一些數據冗餘，但如果爲了消除數據冗餘而再增加一層，就不是三表關聯而是四表關聯了，開發難度倍增，使用起來也略顯繁瑣。
- 每個模塊定義了IP地址後，該模塊下的接口將直接繼承，不需要再單獨爲接口定義IP地址了。
2.2.2 接口列表
當項目模塊創建後，就可以在該模塊下添加接口了。
接口層有以下規範和特點：
- 這個頁面定義了一個接口的基本信息，包括路徑、請求方法、參數類型等，但不會定義具體的參數以及其他信息，這些信息留到用例頁去定義。
- 每個接口只能有一條記錄，新增時根據接口路徑進行判重，以便進一步增強數據規範性，防止出現明明是一個接口，但接口名稱不一樣的情況。
- 新增接口時，平臺、項目、模塊皆爲選擇項（可選擇的數據來源於【項目管理】），而不能自行填入。
2.2.3 用例管理
用例管理是對接口的進一步描述，是最核心的部分，也是開發難度最大的一個模塊。
用例層具有以下規範和特點：
- 用例依賴於接口而存在，只有在接口列表頁創建了某個接口後，才能在此頁面創建該接口的用例，用例將自動繼承所屬接口和模塊的屬性，比如IP地址和路徑等。
- 一個接口可以有多個用例，用例之間參數值不同。
- 用例類型分爲標準用例、正常用例、異常用例，所謂標準用例是指該用例的參數等信息都是能確保用例能正常執行並獲取正常響應結果的用例，每個接口下只能有一個標準用例，當接口下創建了標準用例後，再次創建用例時，直接複製其參數信息等數據，極大增加創建用例的便利性。
- 操作欄點擊【執行】按鈕後，將發起一次接口請求，參數爲該用例的數據。
- 點擊【編輯】可以修改用例的基本信息。
- 點擊【詳情】，進入用例詳情頁。
用例詳情頁有以下幾大部分：
2.2.3.1 基本信息
基本信息，用例的描述性信息，自動讀取。其中，所屬平臺、所屬項目、所屬模塊等信息，讀取自用例所屬的模塊，接口名稱、接口路徑等讀取自用例所屬的接口。
2.2.3.2 請求參數
請求參數，包括請求頭和請求體兩部分。
2.2.3.3 關聯提取
這個功能是爲後續【測試集合】準備的，當你準備把一個用例加入測試集合，且測試集合後續的接口的參數依賴該用例響應結果的值，就需要在關聯處理做預處理。
比如一個登錄用例，需要在響應結果中提取token並提供給後續接口使用，就可以按圖中示例，添加一條關聯提取規則：
- 變量名：提取到的信息暫存到內存中時對應的變量名
- 路徑表達式：需要提取的內容對應的路徑，其書寫格式與使用規則與Jmeter的【JSON Extractor】完全一致。
- 缺省值：當提取預期內容失敗時，給變量名賦予的值。
2.2.3.4 結果斷言
結果斷言目前包括常規斷言和Beanshell斷言兩種形式，其中常規斷言包括：包含、相等、JSON三種方式（已經能覆蓋大多數應用場景，後續可以繼續豐富）
- 包含：響應結果包含預期值，即判定接口請求成功
- 等於：響應內容等於預期值，即判定接口請求成功
- JSON：通過路徑表達式在響應結果中提取特定字段，該特定字段的值等於預期值，即判定接口請求成功
2.2.3.5 結果示例
結果示例是接口返回結果的示例：
2.2.4 測試集合
測試集合可以說是這個接口自動化平臺的意義之所在。在接口自動化中，單接口調用參考價值有限，多個接口按照業務邏輯組成一條流程，纔是接口自動化意義所在。
當一系列接口用例創建完成後，在【測試集合】頁面可以按照業務邏輯將它們組裝起來，形成一個任務隊列。
下面說明一下如何編輯一條測試集合：
- 點擊【編輯】按鈕，將進入測試集合詳情頁，在該頁面可以非常方便地增減用例、調整用例順序。
![在這裏插入圖片描述]()
- 點擊【+】按鈕，進入用例添加頁面：
![在這裏插入圖片描述]()
- 通過選定一系列篩選條件，【用例】行將展示所有符合篩選條件的用例，選擇想要的用例後，點擊【提交】即將該用例添加到測試集合的用例列表中。
![在這裏插入圖片描述]()
- 選擇了用例後，回到測試集合詳情頁，用例順序調整完畢後，點擊【提交】按鈕，將信息保存到數據庫。同時，程序會自動生成【用例隊列】（用例ID組成的隊列）和【隊列描述】（用例對應的接口名稱組成的隊列）。
新增一條測試集合與上述操作基本相同，不同的是，在【測試集合】頁點擊新增後，進入的集合詳情頁，只有一條示例用例：
測試集合支持【一鍵執行】，目前只支持單線程全部執行，後續考慮優化加入按項目執行和多線程執行。
2.2.5 測試結果
在【測試集合】頁面選擇執行某條測試集合後，程序將讀取其對應的用例隊列，並依次執行每個用例，最終生成一條測試集合的測試結果，並持久化保存在數據庫中。
點擊【詳情】按鈕，進入測試結果詳情頁，查看某條測試結果的詳情：
雙擊某行，彈出該行對應的響應結果：
3 難點與待優化列表
3.1 關聯的實現
關聯在【用例管理】的【關聯提取】已有簡單闡述，這裏詳述一下其實現方案：
- 首先，當一條測試集合被執行時，在棧內存中開闢一個Map或JSONObject，我稱其爲關聯池。
- 執行每條用例時，讀取其【關聯提取】數據，如果有記錄，解析該記錄並按提取規則去用例的響應結果中提取相應內容（提取失敗則取其缺省值），並將該內容put到關聯池中。
- 執行每條用例時，如果用例的某個參數的值是 ${param}
格式，意味這個參數值是引用值，則將"param"解析出來，併到關聯池中以"param"爲key執行get操作。 - 基於這種設計機制，我們還可以實現下面的場景：第一個用例的參數A的值是2001，後面用例涉及到參數A的值都想跟第一個用例保持一致，如果每個用例都寫成固定值，那麼一旦修改將是很麻煩的事。那麼，我們可以在關聯提取中添加一行，路徑故意寫錯，缺省值寫爲‘2001’，當該用例執行時，關聯提取失敗，缺省值‘2001’就被put到了關聯池中，後面的用例引用該值即可。
- 測試集合執行完成後，關聯池被銷燬。
實現思路的示意圖如下：
3.2 待優化列表
- 定時任務：新增定時任務管理頁面，支持定時任務可視化編輯。
- 郵件發送：將測試結果發送給相關人，目前測試結果以什麼格式（純文本還是html）發送尚未選定。
- 多線程：測試集合支持按項目執行，並開啓線程池，加快執行效率。
- 前置條件：用例是否執行依賴於前置條件是否被滿足。
- 重試策略：用例執行失敗自動重試n次（n可配置）。
- 請求參數：請求參數支持JSON體。