一個基于數(shù)據(jù)共享的接口開發(fā)平臺

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

關(guān)鍵詞： 軟件項目管理;接口平臺;質(zhì)量保障與工作效率;接口Mock;接口測試;接口自動化測試;數(shù)據(jù)共享

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

本文著錄格式：謝業(yè)欣. 一個基于數(shù)據(jù)共享的接口開發(fā)平臺[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 ?引言

互聯(lián)網(wǎng)發(fā)展到今天，人們對互聯(lián)網(wǎng)應(yīng)用軟件的質(zhì)量和體驗要求越來越高，如何在保障軟件質(zhì)量和追求極致體驗的同時，持續(xù)提高工作效率、降低成本、增加收益，不僅有助于企業(yè)在競爭對手中脫穎而出，還有助于企業(yè)在長遠(yuǎn)發(fā)展中持續(xù)占有主導(dǎo)地位。

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

RESTful架構(gòu)解耦前后端代碼，使用RESTful API（以下簡稱接口）進行通信，只需要一套統(tǒng)一的服務(wù)接口，就可以同時為Web、IOS、Android等應(yīng)用提供服務(wù)。代碼結(jié)構(gòu)清晰、標(biāo)準(zhǔn)統(tǒng)一、易于擴展，還可以使前后端并行開發(fā)，縮短了項目周期[2-5]。

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

1 ?接口開發(fā)過程中存在的問題

如圖1所示，為接口開發(fā)過程中工作現(xiàn)狀與存在的問題。

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

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

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

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

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

（1）每一個過程都需要錄入接口數(shù)據(jù)，工作重復(fù)

（2）工具安裝、開發(fā)環(huán)境部署等，繁瑣、耗時

（3）測試人員要求具備開發(fā)測試腳本的能力，難度大、學(xué)習(xí)成本高

（4）各個過程產(chǎn)生的數(shù)據(jù)分散、不易于收集進行項目分析

2 ?平臺方案設(shè)計

2.1 ?工作流程設(shè)計

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

平臺基于現(xiàn)有的工具和技術(shù)，整合了接口文檔工具、接口Mock工具、接口測試工具和接口自動化測試技術(shù)，使用數(shù)據(jù)庫統(tǒng)一管理數(shù)據(jù)，支持接口文檔、接口Mock、接口測試、接口自動化測試功能。

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

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

2.2 ?功能模塊劃分

如圖3所示，該平臺的主要功能模塊有：接口管理，環(huán)境管理，接口Mock，接口測試，接口自動化測試。接口管理，主要實現(xiàn)接口添加、修改、查詢、刪除功能。環(huán)境管理，主要實現(xiàn)環(huán)境添加、修改、查詢、刪除功能。接口Mock，主要實現(xiàn)Mock設(shè)計、執(zhí)行功能。接口測試，主要實現(xiàn)測試用例的設(shè)計、執(zhí)行、結(jié)果展示功能和測試用例管理（即測試用例的新增、修改、查詢、刪除）功能。接口自動化測試，主要實現(xiàn)測試任務(wù)的創(chuàng)建、執(zhí)行、測試報告展示功能，測試任務(wù)管理（即新增、修改、查詢、刪除）功能，和測試報告管理（即詳情展示、查詢）功能。

2.3 ?數(shù)據(jù)庫設(shè)計

（1）概念結(jié)構(gòu)設(shè)計

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

環(huán)境：環(huán)境ID、名稱、描述、類型、IP地址、域名、最近更新時間、創(chuàng)建人。

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

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

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

測試任務(wù)結(jié)果：任務(wù)結(jié)果ID、任務(wù)執(zhí)行狀態(tài)、測試報告。

這些實體之間的聯(lián)系如下：

1）一個Mock環(huán)境可以為多個接口提供Mock數(shù)據(jù)，一個接口只能在這一個Mock環(huán)境中Mock數(shù)據(jù)（只有一個Mock環(huán)境）。因此，環(huán)境和接口具有一對多的聯(lián)系。

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

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

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

5）一個測試任務(wù)運行會生成多個測試任務(wù)結(jié)果，一個測試任務(wù)結(jié)果只能由一個測試任務(wù)生成。因此，測試任務(wù)和測試任務(wù)結(jié)果具有一對多的聯(lián)系。

6）對該平臺進行概念結(jié)構(gòu)設(shè)計，用E-R圖表示其概念模型，如圖4所示。

（2）邏輯結(jié)構(gòu)設(shè)計

將E-R圖轉(zhuǎn)換為關(guān)系數(shù)據(jù)模型，如下：

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

接口（接口ID，環(huán)境ID，名稱，描述，URL，請求方法，請求Headers，請求參數(shù)，請求協(xié)議、返回Headers，返回Body，最近更新時間）

測試用例（測試用例ID，接口ID，環(huán)境ID，名稱，描述，驗證內(nèi)容，最近更新時間）

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

生成測試任務(wù)（測試用例ID，測試任務(wù)ID）

測試任務(wù)結(jié)果（任務(wù)結(jié)果ID，任務(wù)ID，任務(wù)執(zhí)行狀態(tài)，測試報告）

2.4 ?系統(tǒng)架構(gòu)設(shè)計

如圖5所示，該系統(tǒng)架構(gòu)由：數(shù)據(jù)定義、設(shè)計、調(diào)度中心、執(zhí)行和管理平臺五部分構(gòu)成。

（1）數(shù)據(jù)定義部分由接口定義和環(huán)境定義兩部分組成。

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

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

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

Mock設(shè)計部分，服務(wù)于接口Mock過程，用于設(shè)計Mock數(shù)據(jù)。在接口管理頁面中，選擇要進行Mock的接口，設(shè)置Mock環(huán)境，生成接口Mock描述數(shù)據(jù)，等待Mock被觸發(fā)。

測試設(shè)計部分，服務(wù)于接口測試和接口自動化測試過程，用于單接口測試用例和測試任務(wù)的設(shè)計和生成。在接口管理頁面中，選擇要進行測試的接口，設(shè)置測試運行環(huán)境，并設(shè)置接口響應(yīng)校驗規(guī)則作為期望結(jié)果，生成單接口測試用例數(shù)據(jù)，并在測試用例管理頁面中被統(tǒng)一管理。在測試用例管理頁面中，選擇多個測試用例，設(shè)置測試任務(wù)執(zhí)行的啟動時間和間隔時間，組裝成一個測試任務(wù)，并在測試任務(wù)管理頁面中被統(tǒng)一管理。

（3）調(diào)度中心，主要實現(xiàn)了調(diào)度判斷和調(diào)度執(zhí)行功能，是銜接前端頁面操作和接口Mock、接口測試、接口自動化測試模塊的橋梁，是平臺的核心功能。當(dāng)管理平臺中有執(zhí)行操作被觸發(fā)時，調(diào)度中心首先會攔截被執(zhí)行接口的請求，然后解析請求數(shù)據(jù)中的運行環(huán)境類型，來判斷是哪種類型的執(zhí)行操作被觸發(fā)。然后將攔截的請求轉(zhuǎn)發(fā)到對應(yīng)的服務(wù)器上，并調(diào)度相應(yīng)的執(zhí)行模塊。

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

Mock執(zhí)行，服務(wù)于接口Mock過程中的Mock執(zhí)行。首先，將Mock設(shè)計中生成的Mock數(shù)據(jù)作為請求數(shù)據(jù)，向Mock服務(wù)器發(fā)起請求。然后，在接口數(shù)據(jù)庫表中查詢接口設(shè)計過程中定義的該接口的響應(yīng)內(nèi)容，作為Mock請求的響應(yīng)并返回。最后，展示在Mock結(jié)果查看頁面中。

測試執(zhí)行，服務(wù)于接口測試和接口自動化測試過程中的測試執(zhí)行。單接口測試用例執(zhí)行被觸發(fā)時，首先會將測試設(shè)計中生成的測試用例數(shù)據(jù)作為請求數(shù)據(jù)，向開發(fā)環(huán)境或者生產(chǎn)環(huán)境的服務(wù)器發(fā)起請求，并將響應(yīng)數(shù)據(jù)返回，展示在單接口測試結(jié)果查看頁面中。測試任務(wù)執(zhí)行被觸發(fā)時，首先會解析測試執(zhí)行的啟動時間和間隔時間，然后啟動定時器。每當(dāng)滿足執(zhí)行條件時，就運行一次測試任務(wù)中的所有測試用例。每一次運行，都會生成一個測試報告，并在測試報告管理頁面中被統(tǒng)一管理。測試報告內(nèi)容包括測試任務(wù)執(zhí)行結(jié)果概覽和任務(wù)中每條測試用例的執(zhí)行結(jié)果詳情。

（5）管理平臺部分，實現(xiàn)了平臺前端頁面的展示、操作功能。用于數(shù)據(jù)操作和展示、流程觸發(fā)、狀態(tài)監(jiān)控、結(jié)果查看。包括接口、環(huán)境、測試用例、測試任務(wù)數(shù)據(jù)定義和增刪改查操作的管理，Mock、單接口測試、測試任務(wù)的執(zhí)行觸發(fā)以及測試任務(wù)執(zhí)行狀態(tài)監(jiān)控，Mock結(jié)果、測試結(jié)果展示以及測試任務(wù)執(zhí)行報告的展示、查詢管理。

3 ?系統(tǒng)核心功能實現(xiàn)

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

3.1 ?調(diào)度中心的實現(xiàn)

如圖6所示，為調(diào)度中心的實現(xiàn)流程圖。當(dāng)前端界面觸發(fā)接口的Mock執(zhí)行、單接口測試執(zhí)行、測試任務(wù)執(zhí)行操作后，調(diào)度中心會攔截Axios請求，解析、匹配被執(zhí)行接口數(shù)據(jù)中配置的環(huán)境類型，并判斷是否為Mock環(huán)境。如果是，則將請求轉(zhuǎn)發(fā)至Mock服務(wù)器上，調(diào)用Mock執(zhí)行模塊;否則，將請求轉(zhuǎn)發(fā)至真實服務(wù)器上，調(diào)度測試執(zhí)行模塊。

3.2 ?Mock執(zhí)行的實現(xiàn)

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

3.3 ?測試執(zhí)行的實現(xiàn)

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

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

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

4 ?運行結(jié)果分析

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

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

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

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

5 ?結(jié)語

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

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

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

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

參考文獻

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

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

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

[4] 萬青. Web系統(tǒng)前后端分離架構(gòu)中的控制器優(yōu)化[J]. 科技經(jīng)濟導(dǎo)刊， 2019， 27（16）： 28-29.

[5] 周紹景， 應(yīng)杰， 潘宏斌， 等. RESTful架構(gòu)的應(yīng)用研究[J]. 數(shù)字技術(shù)與應(yīng)用， 2018， 36（05）： 59-60.

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

[7] 潘詩瑤， 黃建明. Web應(yīng)用系統(tǒng)中的MOCK測試技術(shù)[J]. 軟件， 2016， 37（12）： 214-218.

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

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

[10] 劉國慶， 汪興軒. 基于Charles錄制會話的HTTP接口自動化測試框架設(shè)計與實現(xiàn)[J]. 計算機應(yīng)用與軟件， 2019， 36（06）： 7-13.

[11] 楊夢萌， 劉夢. 接口測試數(shù)據(jù)生成工具的設(shè)計與實現(xiàn)[J]. 科技經(jīng)濟導(dǎo)刊， 2019， 27（28）： 25.

[12] 孫立哲. 輕量級接口自動化測試框架設(shè)計與實踐[J]. 計算機應(yīng)用與軟件， 2020， 37（01）： 27-30+36.

[13] 張魯珊. 通用接口自動化測試框架設(shè)計與應(yīng)用[J]. 電子技術(shù)與軟件工程， 2019（06）： 49.

[14] 王娜. 基于python的接口自動化測試框架設(shè)計[J]. 電腦知識與技術(shù)， 2020， 16（12）： 246-248.