一個基于數據共享的接口開發平臺

2020-10-09 11:01:23謝業欣

軟件 2020年8期

摘 ?要：在RESTful API（以下簡稱接口）開發的設計、編碼、測試、維護工作現狀中，接口文檔工具、接口Mock工具、接口測試工具和接口自動化測試技術的使用，產生了工作重復、耗時、難度大、數據不易分析的問題。為保障產品質量的同時進一步提高工作效率，提出了一個基于數據共享的接口開發平臺方案。通過共享接口設計過程中錄入平臺的數據，在接口編碼、測試、維護工作過程中，充分復用接口數據，解決了工作重復問題。通過整合這些輔助工具和技術到同一個平臺中，降低了工作難度，簡化了工作流程。數據集中存儲、管理，解決了數據分散、不利于項目分析的問題。實驗結果表明，使用該平臺后，工作效率提高了58.33%。在實際項目運行中，達到了預期效果，縮短了項目周期，節省了項目成本，增加了企業收益。

關鍵詞：軟件項目管理;接口平臺;質量保障與工作效率;接口Mock;接口測試;接口自動化測試;數據共享

中圖分類號： TP311.56 ? ?文獻標識碼： A ? ?DOI：10.3969/j.issn.1003-6970.2020.08.041

本文著錄格式：謝業欣. 一個基于數據共享的接口開發平臺[J]. 軟件，2020，41（08）：152-157

【Abstract】： In the current status of design， coding， testing， and maintenance of RESTful API （hereinafter referred to as interface） development， the use of interface document tools， interface mock tools， interface test tools， and interface automation testing techniques has resulted in problems such as duplication of work， time-consuming， difficult， and difficult to analyze data. In order to ensure product quality and further improve work efficiency， an interface development platform scheme based on data sharing was proposed. By sharing the data entered in the platform during the interface design process， the interface data is fully reused during the process of interface coding， testing， and maintenance to solve the problem of duplication of work. By integrating these auxiliary tools and technologies into the same platform， the work difficulty is reduced and the work process is simplified. Centralized storage and management of data solves the problems of scattered data and difficult project analysis. The experimental results show that after using the platform， the work efficiency has increased by 58.33%. In the actual project operation， the expected results have been achieved， the project cycle has been shortened， project costs have been saved， and corporate profits have been increased.

【Key words】： Software project management; Interface platform; Quality assurance and work efficiency; Interface mock; Interface test; Interface automated testing; Data sharing

0 ?引言

互聯網發展到今天，人們對互聯網應用軟件的質量和體驗要求越來越高，如何在保障軟件質量和追求極致體驗的同時，持續提高工作效率、降低成本、增加收益，不僅有助于企業在競爭對手中脫穎而出，還有助于企業在長遠發展中持續占有主導地位。

為滿足越來越多樣化的終端應用軟件開發， RESTful架構被廣泛應用。2000年Roy Thomas Fielding的博士論文中首次提出REST。RESTful架構將網絡上的實體作為資源并用URI（統一資源定位符）唯一標識，客戶端和服務端之間傳遞這種資源的某種表現層（即某種數據格式），客戶端使用HTTP協議的四個動詞（GET、POST、PUT、DELETE）對服務端資源進行操作，實現資源的“表現層狀態轉換”[1]。

RESTful架構解耦前后端代碼，使用RESTful API（以下簡稱接口）進行通信，只需要一套統一的服務接口，就可以同時為Web、IOS、Android等應用提供服務。代碼結構清晰、標準統一、易于擴展，還可以使前后端并行開發，縮短了項目周期[2-5]。

軟件的設計、編碼、測試、維護，是軟件開發的主要過程[6]，接口是軟件前后端通信的統一機制，在接口設計、編碼、測試、維護的過程中，做好質量保障和提效工作，對于整個軟件項目尤為重要。因此，在做好接口質量保障工作的同時，如何進一步提高工作效率，一直是各互聯網公司不斷探討的主題。

1 ?接口開發過程中存在的問題

如圖1所示，為接口開發過程中工作現狀與存在的問題。

在接口設計過程中，前后端開發人員根據需求分析的結果，對接口進行設計，約定接口數據規則，并人為記錄到接口文檔工具中[2]。確保了接口開發過程的準確性，提高了跨團隊合作的工作效率。但錄入接口數據耗時、文檔維護成本高。

接口編碼過程中，接口Mock工具為客戶端與服務端分別提供了符合接口數據規則的模擬數據，解耦服務端-客戶端間的模塊依賴，實現真正的前后端分離開發[7]，減少了缺陷出現的可能性，提高了產品質量，縮短了項目周期[8]。但安裝Mock工具，根據接口文檔將接口數據錄入到Mock工具中，這些前置工作非常耗時。

對新開發的接口進行測試不僅可以更早地發現一些核心問題，還可以縮小定位、分析問題的范圍，有助于更快修復問題，進而提高了缺陷修復效率[9]。但安裝工具，依照接口文檔將接口請求數據錄入到接口測試工具中[10-11]，這些前置工作非常繁瑣、耗時。

在快速增量迭代的工作實際中，要求在短時間內對大量處于維護過程中的接口進行回歸測試。接口自動化測試，在很大程度上減輕測試人員的壓力，大大提高了軟件測試工作的效率[12-14]。同時，避免了人為操作帶來的失誤，一定程度上提高了測試的準確性。但根據接口文檔將接口數據錄入到自動化測試腳本中，并開發、調試腳本，不僅耗時，而且工作難度大、學習成本高。

在接口設計、編碼、測試、維護過程中，接口文檔、接口Mock、接口測試、接口自動化測試，都對產品質量保障和提高工作效率起到了積極作用。但這些輔助工具和技術的使用，也帶來了如下問題：

（1）每一個過程都需要錄入接口數據，工作重復

（2）工具安裝、開發環境部署等，繁瑣、耗時

（3）測試人員要求具備開發測試腳本的能力，難度大、學習成本高

（4）各個過程產生的數據分散、不易于收集進行項目分析

2 ?平臺方案設計

2.1 ?工作流程設計

針對接口開發過程中的工作重復、耗時、難度大、數據不易分析的問題，本文提出了一個基于數據共享的接口開發平臺解決方案。

平臺基于現有的工具和技術，整合了接口文檔工具、接口Mock工具、接口測試工具和接口自動化測試技術，使用數據庫統一管理數據，支持接口文檔、接口Mock、接口測試、接口自動化測試功能。

共享接口設計過程中錄入平臺的數據，在接口編碼、測試、維護過程中，充分復用接口數據，無需再次人為錄入，解決了工作重復問題。無需安裝、部署任何工具和環境，無需具備編程基礎，只需使用瀏覽器訪問，就可以使用，解決了工作耗時、難度大的問題。數據集中存儲、管理，解決了數據分散、不易項目分析的問題。

如圖2所示，為平臺工作流程圖。在接口設計過程中，將接口數據人為錄入到平臺中。在接口編碼、測試、維護過程中，只需在平臺界面中選擇所需接口，就可以完成接口Mock、接口測試、接口自動化測試。

2.2 ?功能模塊劃分

如圖3所示，該平臺的主要功能模塊有：接口管理，環境管理，接口Mock，接口測試，接口自動化測試。接口管理，主要實現接口添加、修改、查詢、刪除功能。環境管理，主要實現環境添加、修改、查詢、刪除功能。接口Mock，主要實現Mock設計、執行功能。接口測試，主要實現測試用例的設計、執行、結果展示功能和測試用例管理（即測試用例的新增、修改、查詢、刪除）功能。接口自動化測試，主要實現測試任務的創建、執行、測試報告展示功能，測試任務管理（即新增、修改、查詢、刪除）功能，和測試報告管理（即詳情展示、查詢）功能。

2.3 ?數據庫設計

（1）概念結構設計

根據上述流程設計和功能模塊劃分可知，該平臺涉及到的數據有：接口數據、環境數據、Mock設計數據、Mock結果數據、測試用例數據、單接口測試結果數據、測試任務數據、測試報告數據。因Mock設計數據、Mock結果數據和單接口測試結果數據，在后續的流程中不會被復用和查詢，故不作持久性存儲，只作單次數據展示。因此，該平臺的數據庫設計實體和屬性有：

環境：環境ID、名稱、描述、類型、IP地址、域名、最近更新時間、創建人。

接口：接口ID、名稱、描述、URL、請求Headers、請求參數、請求協議、返回Headers、返回Body、最近更新時間。

測試用例：用例ID、名稱、描述、驗證內容、最近更新時間。

測試任務：任務ID、名稱、描述、啟動時間、測試頻率、最近更新時間。

測試任務結果：任務結果ID、任務執行狀態、測試報告。

這些實體之間的聯系如下：

1）一個Mock環境可以為多個接口提供Mock數據，一個接口只能在這一個Mock環境中Mock數據（只有一個Mock環境）。因此，環境和接口具有一對多的聯系。

2）一個接口可以設計多條測試用例，一條測試用例只能測試一個接口。因此，接口和測試用例具有一對多的聯系。

3）一個測試環境中可以運行多條測試用例，一條測試用例只能運行在一個測試環境中。因此，環境和測試用例具有一對多的聯系。

4）一個測試任務中可以包含多條測試用例，一條測試用例也可以存在在多個測試任務。因此，測試任務和測試用例具有多對多的聯系。

5）一個測試任務運行會生成多個測試任務結果，一個測試任務結果只能由一個測試任務生成。因此，測試任務和測試任務結果具有一對多的聯系。

6）對該平臺進行概念結構設計，用E-R圖表示其概念模型，如圖4所示。

（2）邏輯結構設計

將E-R圖轉換為關系數據模型，如下：

環境（環境ID，名稱，描述，類型，IP地址，域名，最近更新時間）

接口（接口ID，環境ID，名稱，描述，URL，請求方法，請求Headers，請求參數，請求協議、返回Headers，返回Body，最近更新時間）

測試用例（測試用例ID，接口ID，環境ID，名稱，描述，驗證內容，最近更新時間）

測試任務（測試任務ID，名稱，描述，啟動時間，測試頻率，最近更新時間）

生成測試任務（測試用例ID，測試任務ID）

測試任務結果（任務結果ID，任務ID，任務執行狀態，測試報告）

2.4 ?系統架構設計

如圖5所示，該系統架構由：數據定義、設計、調度中心、執行和管理平臺五部分構成。

（1）數據定義部分由接口定義和環境定義兩部分組成。

接口定義，支持數據模板定義，定義數據內容包括接口名稱、接口描述、接口URL、請求方法、請求協議、請求參數、請求Headers、返回Headers、返回Body。服務于接口設計過程中對原始接口數據的錄入、編輯、查詢、刪除功能，通過管理平臺中的接口定義和管理界面可進行數據操作。對外輸出接口描述數據，便于在接口Mock、測試、自動化測試過程中復用。

環境定義，定義數據內容包括環境名稱、環境描述、環境類型、IP地址、域名。對外輸出環境描述數據，服務于接口Mock設計、接口測試用例設計時，運行環境的配置選擇，通過管理平臺中的環境定義和管理界面可進行數據操作。

（2）設計部分由Mock設計和測試設計兩部分組成。

Mock設計部分，服務于接口Mock過程，用于設計Mock數據。在接口管理頁面中，選擇要進行Mock的接口，設置Mock環境，生成接口Mock描述數據，等待Mock被觸發。

測試設計部分，服務于接口測試和接口自動化測試過程，用于單接口測試用例和測試任務的設計和生成。在接口管理頁面中，選擇要進行測試的接口，設置測試運行環境，并設置接口響應校驗規則作為期望結果，生成單接口測試用例數據，并在測試用例管理頁面中被統一管理。在測試用例管理頁面中，選擇多個測試用例，設置測試任務執行的啟動時間和間隔時間，組裝成一個測試任務，并在測試任務管理頁面中被統一管理。

（3）調度中心，主要實現了調度判斷和調度執行功能，是銜接前端頁面操作和接口Mock、接口測試、接口自動化測試模塊的橋梁，是平臺的核心功能。當管理平臺中有執行操作被觸發時，調度中心首先會攔截被執行接口的請求，然后解析請求數據中的運行環境類型，來判斷是哪種類型的執行操作被觸發。然后將攔截的請求轉發到對應的服務器上，并調度相應的執行模塊。

（4）執行部分由Mock執行和測試執行兩部分組成。

Mock執行，服務于接口Mock過程中的Mock執行。首先，將Mock設計中生成的Mock數據作為請求數據，向Mock服務器發起請求。然后，在接口數據庫表中查詢接口設計過程中定義的該接口的響應內容，作為Mock請求的響應并返回。最后，展示在Mock結果查看頁面中。

測試執行，服務于接口測試和接口自動化測試過程中的測試執行。單接口測試用例執行被觸發時，首先會將測試設計中生成的測試用例數據作為請求數據，向開發環境或者生產環境的服務器發起請求，并將響應數據返回，展示在單接口測試結果查看頁面中。測試任務執行被觸發時，首先會解析測試執行的啟動時間和間隔時間，然后啟動定時器。每當滿足執行條件時，就運行一次測試任務中的所有測試用例。每一次運行，都會生成一個測試報告，并在測試報告管理頁面中被統一管理。測試報告內容包括測試任務執行結果概覽和任務中每條測試用例的執行結果詳情。

（5）管理平臺部分，實現了平臺前端頁面的展示、操作功能。用于數據操作和展示、流程觸發、狀態監控、結果查看。包括接口、環境、測試用例、測試任務數據定義和增刪改查操作的管理，Mock、單接口測試、測試任務的執行觸發以及測試任務執行狀態監控，Mock結果、測試結果展示以及測試任務執行報告的展示、查詢管理。

3 ?系統核心功能實現

本系統使用基于JavaScript的Vue.js框架和Elemnet-ui組件庫來實現管理平臺的數據的展示和頁面的操作、跳轉等功能。使用基于Python編程語言的Django框架和DRF（Django REST framework）組件來實現服務端業務邏輯處理并提供Web API，主要實現了調度中心、執行模塊。使用Django的Model層自帶數據庫ORM組件管理數據，使用MySQL存儲數據。使用Nginx+uWSGI部署Web服務到Linux系統的服務器上。

3.1 ?調度中心的實現

如圖6所示，為調度中心的實現流程圖。當前端界面觸發接口的Mock執行、單接口測試執行、測試任務執行操作后，調度中心會攔截Axios請求，解析、匹配被執行接口數據中配置的環境類型，并判斷是否為Mock環境。如果是，則將請求轉發至Mock服務器上，調用Mock執行模塊;否則，將請求轉發至真實服務器上，調度測試執行模塊。

3.2 ?Mock執行的實現

如圖7所示，為Mock執行的實現流程圖。Mock執行模塊被調度后，將會在Mock服務器上完成Mock執行功能，本系統中Mock服務器和系統服務器共用，因此，訪問Mock服務器即為訪問系統服務器，無需做重定向跳轉。首先會解析被攔截請求中的URL，然后查詢接口描述數據庫表中被定義的響應數據模板，解析數據模板，生成隨機模擬數據，并作為Mock響應數據返回。隨機模擬數據的生成，使用了開源模擬數據生成器Mock.js。此處，復用了接口定義數據，無需再次錄入數據。

3.3 ?測試執行的實現

如圖8所示，為測試執行的實現流程圖。測試執行模塊被調度后，首先會判斷該次測試執行是否為周期性執行。如果是周期性執行，則會先解析測試任務中設置的執行開始時間和執行頻次，然后啟動定時器，輪詢檢查啟動時間是否到，如果還沒到啟動時間，則繼續等待;如果已到啟動時間，則周期性地調用測試任務執行單元。定時任務的執行，使用Python的定時任務調度框架APScheduler中的BackgroundScheduler調度器實現。

如果不是周期性執行，則會直接調用測試任務執行單元。首先判斷是否為測試任務。如果是測試任務，則會生成測試執行隊列，只要執行隊列不為空，將循環調用單次單條測試用例執行單元。否則，生成測試報告。測試任務執行單元的實現，使用Python單元測試框架unittest編寫和組織測試用例模板，使用unittest HTML的第三方報告庫HTMLTestRunner實現測試用例的執行和測試報告的生成。

如果不是測試任務，則會直接調用單次單條測試用例執行單元。首先，判斷被測試接口數據中配置的環境是否為測試環境，如果是，則將訪問測試服務器并返回測試數據;否則，將訪問線上服務器并返回線上數據。測試服務器的訪問過程，使用Python的HTTP庫Requests來實現。

4 ?運行結果分析

目前，該平臺已經在項目中交付使用，運行效果達到了預期。筆者從項目中隨機選取了50個接口作為樣本數據進行了對比分析。如表1所示，為使用該平臺前后的運行結果分析。

使用該平臺前，完成一個接口的設計，平均需要10分鐘，其中，約定接口數據規則需要4分鐘，錄入接口數據需要6分鐘;完成一個接口的Mock，平均需要10分鐘，其中，錄入接口數據需要5分鐘，Mock需要5分鐘;完成一個接口測試，平均需要30分鐘，其中，安裝測試工具和錄入接口數據需要25分鐘，設計和執行測試用例需要5分鐘;完成一個接口的自動化測試，平均需要10分鐘，其中，錄入接口數據需要5分鐘，設計和執行自動化測試用例需要5分鐘。因此，一個接口的設計、Mock、測試和自動化測試，一共需要60分鐘。

使用該平臺后，完成一個接口的設計，平均需要10分鐘;完成一個接口的Mock，節省了50%的錄入接口數據的工作量，僅需要5分鐘;完成一個接口測試，節省了83%的安裝測試工具和錄入接口數據的工作量，僅需要5分鐘設計和執行測試用例;完成一個接口的自動化測試，節省了50%的錄入接口數據的工作量，僅需要5分鐘設計和執行自動化測試用例。

由此可見，完成一個接口的設計、Mock、測試、自動化測試需要的平均總工作量，使用平臺前為60分鐘/個，使用平臺后為25分鐘/個。使用平臺后與使用平臺前相比，總工作效率提高了58.33%。

5 ?結語

本文從接口開發的設計、編碼、測試、維護工作現狀中進行研究和分析，發現輔助工具和技術的使用，雖然在一定程度上保障了產品質量和提高了工作效率，但也造成了工作重復、耗時、難度大、數據不易分析的問題。

針對這些問題，提出了一個基于數據共享的接口開發平臺方案，將現有工具和技術整合到一個平臺中，無需安裝、部署任何工具和環境，無需具備編程基礎，只需使用瀏覽器訪問，就可以使用，解決了工作耗時、難度大的問題。共享接口設計過程中錄入平臺的數據，在接口編碼、測試、維護過程中，充分復用接口數據，無需再次人為錄入，解決了工作重復問題。數據集中存儲、管理，解決了數據分散、不易項目分析的問題。平臺在滿足現有工作要求的同時，降低了工作難度，簡化了工作流程，進一步提高了工作效率，確保了工作的準確性。同時，也為進一步的項目分析提供了數據基礎。

實驗證明，使用該平臺后整體工作效率提高了58.33%。在實際項目中的運行也達到了預期效果，縮短了項目周期，節省了項目成本，增加了企業收益。

對項目數據提供數據可視化展示和分析，是接下來的一個重要優化點。同時，隨著版本的迭代，需要進行回歸自動化測試的用例數量越來越多，針對增量代碼進行精準回歸測試的需求，已經提上了日程。

參考文獻

[1] 阮一峰. 理解RESTful架構[EB/OL]. 2011[2020-07-01]. http：//www.ruanyifeng.com/blog/2011/09/restful.html

[2] 劉紅衛. 利用Node.js開發前后端分離的系統——以圖書館地方文獻系統為例[J]. 天津科技， 2018， 45（07）： 67-70.

[3] 孟祥雙. 前后端分離式WEB應用開發研究[J]. 電子元器件與信息技術， 2019， 3（06）： 40-43.

[4] 萬青. Web系統前后端分離架構中的控制器優化[J]. 科技經濟導刊， 2019， 27（16）： 28-29.

[5] 周紹景，應杰，潘宏斌，等. RESTful架構的應用研究[J]. 數字技術與應用， 2018， 36（05）： 59-60.

[6] 王立福，孫艷春，劉學陽. 軟件工程[M]. 北京：北京大學出版社， 2009.

[7] 潘詩瑤，黃建明. Web應用系統中的MOCK測試技術[J]. 軟件， 2016， 37（12）： 214-218.

[8] 王建，羅政，張希，等. Web項目前后端分離的設計與實現[J]. 軟件工程， 2020， 23（04）： 22-24.

[9] 蟲師. Web接口開發與自動化測試[M]. 北京：電子工業出版社， 2017： 4-1.