基於 Springboot+layui 實現介面自動化平臺

前言

一次偶然的機會來到這裡，有種恍然大悟的感覺：原來大家都在這裡！我說在CSDN上很少看到測試相關的文章呢。翻看了幾篇，各位談笑間，水平盡顯——進這裡就像回到家一樣，進了裡面去個個都是人才，說話又好聽，超喜歡在裡面。

我本人是19年6月份開始在CSDN寫些博文的，這裡也順勢推薦一波，歡迎大家關注、交流。部落格地址奉上：https://blog.csdn.net/mu_wind。

發現測試裡走Java路線的真是少之又少，希望多遇到幾個同道中人吧。

言歸正傳，今天來跟大家分享一個自己的作品--基於Springboot+layui實現介面自動化平臺，如果感興趣的人多，會考慮開源。回顧這段歲月，甘苦自知。既有遇到難點一籌莫展、食之無味的困窘，也有解決難題除錯成功的欣喜，堪稱五味雜陳。人言奮鬥的歲月最充實，果然如此。

閒言幾句：讀了幾篇文章，頗有幾番質疑技術的言論，在我看來，技術是一把刀，越鋒利越好，如果這把刀發揮不了功效，那是拿刀的人出了問題，而非刀本身。當然，技術一定要結合業務，否則就成了無柄之刃，再鋒利也是徒勞。

好，正式開始。平臺採用的技術棧有：

• 後端：Springboot、mysql、redis
• 前端：jQuery、layui

平臺資料採用分層設計，即將介面自動化所需的資料分為【專案管理】、【介面列表】、【用例管理】、【測試集合】、【測試結果】五個部分。如下圖所示：

平臺入口，顏值即正義，儘量弄得漂亮一點，也讓人有使用的慾望。

1 專案管理

專案管理，定義了公司系統的基本框架。以新浪新聞為例，我將做如下分割：

• 平臺：新浪新聞
• 專案：體育
• 模組：西甲
• IP地址：略

專案模組層，有以下規範和特點：

• 專案管理頁面決定了每個介面的歸屬，當我們新增介面時，必須建立在已有模組下，而不能隨心所欲地新增。因為平臺使用人眾多，如果不做此約束，資料將會十分混亂。
• 通常情況下，每個專案對應著自己的IP地址。這個平臺中，每個模組對應著一個IP地址，還是有一些資料冗餘，但如果為了消除資料冗餘而再增加一層，就不是三表關聯而是四表關聯了，開發難度倍增，使用起來也略顯繁瑣。
• 每個模組定義了IP地址後，該模組下的介面將直接繼承，不需要再單獨為介面定義IP地址了。

2 介面列表

當專案模組建立後，就可以在該模組下新增介面了。

介面層有以下規範和特點：

• 這個頁面定義了一個介面的基本資訊，包括路徑、請求方法、引數型別等，但不會定義具體的引數以及其他資訊，這些資訊留到用例頁去定義。
• 每個介面只能有一條記錄，新增時根據介面路徑進行判重，以便進一步增強資料規範性，防止出現明明是一個介面，但介面名稱不一樣的情況。
• 新增介面時，平臺、專案、模組皆為選擇項（可選擇的資料來源於【專案管理】），而不能自行填入。

3 用例管理

用例管理是對介面的進一步描述，是最核心的部分，也是開發難度最大的一個模組。用例可以直接呼叫除錯：

用例層具有以下規範和特點：

• 用例依賴於介面而存在，只有在介面列表頁建立了某個介面後，才能在此頁面建立該介面的用例，用例將自動繼承所屬介面和模組的屬性，比如IP地址和路徑等。
• 一個介面可以有多個用例，用例之間引數值不同。
• 用例型別分為標準用例、正常用例、異常用例，所謂標準用例是指該用例的引數等資訊都是能確保用例能正常執行並獲取正常響應結果的用例，每個介面下只能有一個標準用例，當介面下建立了標準用例後，再次建立用例時，直接複製其引數資訊等資料，極大增加建立用例的便利性。
• 操作欄點選【執行】按鈕後，將發起一次介面請求，引數為該用例的資料。
• 點選【編輯】可以修改用例的基本資訊。
• 點選【詳情】，進入用例詳情頁。

用例詳情頁有以下幾大部分：

1、基本資訊：用例的描述性資訊，自動讀取。其中，所屬平臺、所屬專案、所屬模組等資訊，讀取自用例所屬的模組，介面名稱、介面路徑等讀取自用例所屬的介面。

2、請求引數，包括請求頭和請求體兩部分。

3、關聯提取：這個功能是為後續【測試集合】準備的，當你準備把一個用例加入測試集合，且測試集合後續的介面的引數依賴該用例響應結果的值，就需要在關聯處理做預處理。
比如一個登入用例，需要在響應結果中提取token並提供給後續介面使用，就可以按圖中示例，新增一條關聯提取規則：

• 變數名：提取到的資訊暫存到記憶體中時對應的變數名
• 路徑表示式：需要提取的內容對應的路徑，其書寫格式與使用規則與Jmeter的【JSON Extractor】完全一致。
• 預設值：當提取預期內容失敗時，給變數名賦予的值。

4、結果斷言：目前包括常規斷言和Beanshell斷言兩種形式，其中常規斷言包括：包含、相等、JSON三種方式（已經能覆蓋大多數應用場景，後續可以繼續豐富）

5、結果示例是介面返回結果的示例：

4 測試集合

測試集合可以說是這個介面自動化平臺的意義之所在。在介面自動化中，單介面呼叫參考價值有限，多個介面按照業務邏輯組成一條流程，才是介面自動化意義所在。
當一系列介面用例建立完成後，在【測試集合】頁面可以按照業務邏輯將它們組裝起來，形成一個任務佇列。

下面說明一下如何編輯一條測試集合：

1. 點選【編輯】按鈕，將進入測試集合詳情頁，在該頁面可以非常方便地增減用例、調整用例順序。
2. 點選【+】按鈕，進入用例新增頁面：
3. 通過選定一系列篩選條件，【用例】行將展示所有符合篩選條件的用例，選擇想要的用例後，點選【提交】即將該用例新增到測試集合的用例列表中。
4. 選擇了用例後，回到測試集合詳情頁，用例順序調整完畢後，點選【提交】按鈕，將資訊儲存到資料庫。同時，程式會自動生成【用例佇列】（用例ID組成的佇列）和【佇列描述】（用例對應的介面名稱組成的佇列）。

5 測試結果

在【測試集合】頁面選擇執行某條測試集合後，程式將讀取其對應的用例佇列，並依次執行每個用例，最終生成一條測試集合的測試結果，並持久化儲存在資料庫中。

點選【詳情】按鈕，進入測試結果詳情頁，檢視某條測試結果的詳情：

雙擊某行，彈出該行對應的響應結果：

介面測試平臺功能大體上就以上，還有很多需要優化的地方，比如

• 定時任務，將以專案或測試集合為單位佈置定時任務執行。
• 結果報告，這個功能常有的華麗麗的測試報告，個人覺得華大於實，有精力再搞搞吧。
• 互動優化，測試資料頁面左側增加樹狀列表，方便資料查詢。