基于模塊化的接口協(xié)議測試平臺(tái)設(shè)計(jì)與實(shí)現(xiàn)

陳威宇

（倫敦大學(xué)國王學(xué)院 信息學(xué)院，英國 倫敦 WC2R 2LS）

0 引言

接口是Web系統(tǒng)平臺(tái)之間不同組成部分銜接的約定[1]，為了保證各接口運(yùn)行的正確性和穩(wěn)定性，開發(fā)完成的接口要先進(jìn)行測試才能上線使用，接口測試的主要功能是用來檢測各部分之間的交互點(diǎn)[2]，測試范圍通常包括數(shù)據(jù)流的傳遞、交換和控制管理、功能的容錯(cuò)性及系統(tǒng)相互之間的邏輯依賴關(guān)系等等[3]。

接口測試屬于功能測試的一類，測試流程也是測試人員根據(jù)接口文檔定義的接口協(xié)議，設(shè)計(jì)接口測試用例，然后由執(zhí)行人員執(zhí)行測試。這也意味著每次都需要耗費(fèi)很多精力和時(shí)間去編寫這些測試報(bào)文[4]。參考文檔的定義，這也意味著接口本身很容易存在一些描述上的缺陷，即接口信息不足而無法準(zhǔn)確表達(dá)服務(wù)過程中的一些隱性約束限制條件，造成調(diào)用方和服務(wù)提供方對(duì)服務(wù)理解的不一致，導(dǎo)致用例設(shè)計(jì)錯(cuò)誤或者用例覆蓋不全面等問題，從而出現(xiàn)質(zhì)量風(fēng)險(xiǎn)。

接口的測試方法多數(shù)是借助工具/框架，或者是通過編程語言去實(shí)現(xiàn)自定義的測試需求，現(xiàn)有的一些主流接口測試方法及實(shí)現(xiàn)方式存在以下的一些問題。（1）測試范圍：多數(shù)測試方法，只能覆蓋到接口表面的功能測試，無法深入接口內(nèi)部進(jìn)行一些更深層次的邏輯檢查，比如接入數(shù)據(jù)庫的數(shù)據(jù)更新或操作服務(wù)器模擬故障注入等行為，來提高接口測試場景的覆蓋率；（2）測試效率：很多簡單的接口測試工具/框架都可以做到快速完成接口測試工作，而且從效率上來看，UI > 腳本 > 編程語言，而測試覆蓋率上，UI < 腳本 < 編程語言；綜合分析可以看出覆蓋范圍越廣的方法，實(shí)現(xiàn)效率上往往都比較低，即測試方法的能力水平通常與效率成反比；（3）測試門檻：通過UI操作的形式完成測試的執(zhí)行要求相對(duì)較簡單，入門門檻也比較低。但同樣地，測試能覆蓋的范圍也相比腳本/代碼實(shí)現(xiàn)的方法也小很多，而編寫代碼測試的門檻較高，這也意味著對(duì)執(zhí)行人員的操作水平要求比較高，同時(shí)存在測試代碼與測試框架無法分離的問題。另外，代碼開發(fā)由于搭建調(diào)試運(yùn)行環(huán)境，經(jīng)常存在測試環(huán)境復(fù)雜的問題[5]。

接口協(xié)議包含的內(nèi)容細(xì)分為以下幾點(diǎn)：接口的功能、接口輸入輸出參數(shù)、服務(wù)之間的數(shù)據(jù)依賴與控制依賴關(guān)系，服務(wù)調(diào)用以及服務(wù)之間的協(xié)同合作所需的場景信息，場景執(zhí)行完成預(yù)期結(jié)果的預(yù)言[6]。

考慮接口協(xié)議復(fù)雜的流程性和邏輯性，本文引入模塊化的概念，模塊化既是一種設(shè)計(jì)方法也是一種思維方式，Kirk Knoernschild[7]也強(qiáng)調(diào)過“分而治之”是解決復(fù)雜問題的有效方式。模塊化在軟件領(lǐng)域有著形式簡單但意義比較深遠(yuǎn)的價(jià)值，有利于軟件開發(fā)以及業(yè)務(wù)邏輯中比較復(fù)雜問題的解決[8]。

如今市場上的軟件系統(tǒng)功能越來越復(fù)雜，迭代速度也越來越快，版本迭代速度和發(fā)布質(zhì)量之間的矛盾也是日益突出。針對(duì)該問題，本文提出一種基于模塊化的接口協(xié)議測試方法，它將接口協(xié)議抽象模塊化成一個(gè)個(gè)單獨(dú)的處理模塊，每個(gè)模塊單獨(dú)負(fù)責(zé)一部分通用能力，讓用戶通過Web UI界面快速進(jìn)行用例的編排操作，而后臺(tái)則通過Python語言為其提供對(duì)應(yīng)的強(qiáng)大的自動(dòng)處理能力，讓用戶通過UI操作的方式就能達(dá)到純語言開發(fā)的效果。本方法通過減少用戶的協(xié)議參考、手工編寫用例等時(shí)間，讓用戶聚焦于接口本身的具體邏輯流程，提升接口測試方法的覆蓋率和測試速度，從而提升整體系統(tǒng)的交付質(zhì)量和迭代速率。

從模塊化的角度出發(fā)，把接口協(xié)議測試的過程，定義為“定義-組建-調(diào)用-檢測”四部曲的方式，如圖1所示。

圖1 模塊化接口協(xié)議測試過程

請求信息獲取模塊：該模塊用于獲取接口協(xié)議配置的請求信息(包括出入?yún)?shù)/調(diào)用依賴關(guān)系等)，并確定與所述信息相對(duì)應(yīng)的一個(gè)或多個(gè)最小測試單元；場景用例組建模塊：該模塊按照測試順序?qū)⑺龅囊粋€(gè)或多個(gè)最小測試單元組成場景測試用例；場景用例調(diào)用模塊：該模塊調(diào)用所述場景測試用例，通過所述場景用例執(zhí)行待測試的接口協(xié)議，得到所述場景測試用例輸出的響應(yīng)數(shù)據(jù)；結(jié)果檢測模塊：該模塊對(duì)所述響應(yīng)數(shù)據(jù)進(jìn)行結(jié)果檢測，得到所述接口協(xié)議的測試結(jié)果。

1 系統(tǒng)平臺(tái)方案設(shè)計(jì)

1.1 系統(tǒng)架構(gòu)設(shè)計(jì)

圖2所示是本接口協(xié)議測試平臺(tái)的底層架構(gòu)。其中，用戶界面用于接收并顯示用戶的輸入，以獲取用于測試接口協(xié)議的請求信息，確定與請求信息相對(duì)應(yīng)的一個(gè)或多個(gè)最小測試單元。場景用例中可以包括一個(gè)或多個(gè)最小測試單元，每個(gè)最小測試單元中均配置有元參數(shù)、預(yù)設(shè)輸出數(shù)據(jù)和其他相關(guān)參數(shù)。平臺(tái)中還包括有設(shè)置臺(tái)和報(bào)告輸出模塊，設(shè)置臺(tái)用于對(duì)平臺(tái)進(jìn)行界面設(shè)置，報(bào)告模塊用于輸出場景用例調(diào)用并執(zhí)行完成之后產(chǎn)生的測試報(bào)告。平臺(tái)支持的協(xié)議包括一些基礎(chǔ)的函數(shù)調(diào)用功能、對(duì)響應(yīng)數(shù)據(jù)進(jìn)行結(jié)果檢測的功能以及基礎(chǔ)的腳本程序執(zhí)行功能等。

圖2 基于模塊化的接口協(xié)議測試平臺(tái)底層架構(gòu)

平臺(tái)的接口協(xié)議執(zhí)行模塊用于執(zhí)行待測試的接口協(xié)議，其中包括API(application programming tnterface，應(yīng)用程序接口)、CGI(common gateway interface，公共網(wǎng)關(guān)接口)、數(shù)據(jù)庫以及腳本程序等功能模塊，以及對(duì)最小測試單元的邏輯操作。例如，可以對(duì)場景用例中的某個(gè)最小測試單元配置邏輯操作參數(shù)，比如配置執(zhí)行預(yù)設(shè)次數(shù)。假設(shè)預(yù)設(shè)次數(shù)為RunCount，初始的當(dāng)前運(yùn)行次數(shù)RunTime為0，每當(dāng)完成一次對(duì)場景用例中的某個(gè)最小測試單元執(zhí)行過程，則令RunTime自增加1，直到RunTime等于RunCount時(shí)，完成對(duì)該最小測試單元的預(yù)設(shè)次數(shù)的執(zhí)行。平臺(tái)的定時(shí)任務(wù)模塊用于按照定時(shí)規(guī)則每隔預(yù)定時(shí)間調(diào)用最小測試單元。平臺(tái)的異步接口模塊用于執(zhí)行測試步驟中的異步請求的相關(guān)事宜，可以根據(jù)邏輯關(guān)鍵字控制請求的執(zhí)行過程，例如控制請求執(zhí)行過程的條件判斷、中斷和循環(huán)等。平臺(tái)的并行控制單元用于控制并行的請求任務(wù)同時(shí)執(zhí)行。

數(shù)據(jù)中心中存儲(chǔ)有場景用例調(diào)用過程中的全局變量、關(guān)聯(lián)字段和一些用于進(jìn)行結(jié)果檢測的偽代碼，例如“$res==0”就是判斷檢測變量$res是否等于預(yù)設(shè)輸出數(shù)據(jù)0的偽代碼，便于場景用例決定請求完成后的具體操作。

1.2 系統(tǒng)流程設(shè)計(jì)

一個(gè)場景用例從被調(diào)用開始,首先會(huì)載入CGI/API數(shù)據(jù)等測試平臺(tái)預(yù)設(shè)好的元數(shù)據(jù)，其中包括了請求和應(yīng)答的協(xié)議元數(shù)據(jù)，以便正確解析場景用例中的請求并應(yīng)答。接著對(duì)場景用例中由各個(gè)請求組成的測試流程進(jìn)行解析，以形成確定的測試順序；再對(duì)場景用例中的數(shù)據(jù)進(jìn)行解析，生成對(duì)應(yīng)的變量支持后續(xù)測試進(jìn)行。基于解析后的測試流程依次發(fā)起請求，并輸出表示成功接收到該請求的應(yīng)答回包。

測試過程需要判斷當(dāng)前請求是否為異步請求，若當(dāng)前的請求是為異步請求，則將請求加入到異步測試隊(duì)列中，同時(shí)開始執(zhí)行該請求，并繼續(xù)調(diào)用場景測試流程中的下一請求。若當(dāng)前請求是同步請求，則直接執(zhí)行該請求，等待該請求響應(yīng)后，再調(diào)用下一請求。在異步測試隊(duì)列中，需要每隔預(yù)設(shè)時(shí)間查詢隊(duì)列中的異步測試請求的任務(wù)狀態(tài)(即輪詢操作)，并在異步測試單元的任務(wù)已完成或超時(shí)的時(shí)候，生成響應(yīng)信息。在請求響應(yīng)之后，若響應(yīng)信息中包括有數(shù)據(jù)，則將該數(shù)據(jù)輸出到數(shù)據(jù)中心中存儲(chǔ)，若響應(yīng)信息中包括有函數(shù)調(diào)用，則將該響應(yīng)信息輸出到函數(shù)中心中調(diào)用執(zhí)行對(duì)應(yīng)的函數(shù)。

在請求生成響應(yīng)信息之后，獲取返回?cái)?shù)據(jù)，執(zhí)行對(duì)響應(yīng)信息進(jìn)行結(jié)果檢測的步驟。其中，獲取返回?cái)?shù)據(jù)可以是包括以下幾種方式：①腳本運(yùn)行結(jié)果；②數(shù)據(jù)庫訪問指令的訪問結(jié)果；③通過CGI接口獲取外界的數(shù)據(jù)；④將響應(yīng)信息輸出到函數(shù)中心中調(diào)用對(duì)應(yīng)的函數(shù)得到的計(jì)算結(jié)果。獲得返回?cái)?shù)據(jù)之后，可以執(zhí)行結(jié)果檢測，例如將返回?cái)?shù)據(jù)與場景用例包含的預(yù)設(shè)輸出數(shù)據(jù)進(jìn)行匹配檢測，并根據(jù)匹配結(jié)果輸出測試結(jié)果。

事件樁用于在預(yù)設(shè)的特定條件下執(zhí)行某個(gè)請求。當(dāng)一個(gè)請求的測試結(jié)果輸出之后，可能會(huì)觸發(fā)事件樁執(zhí)行特定的預(yù)設(shè)指令，例如重新發(fā)起該請求。在測試流程依次發(fā)起請求之后，也可以將其中的某個(gè)請求加載進(jìn)事件樁中，等到某個(gè)預(yù)設(shè)條件下再執(zhí)行該請求。事件樁還可以用于在場景用例開始/結(jié)束執(zhí)行時(shí)調(diào)用事件、在最小測試單元開始/結(jié)束執(zhí)行時(shí)調(diào)用事件、在結(jié)果檢測開始/結(jié)束時(shí)調(diào)用事件等。其中，事件可以為請求、函數(shù)、指令或者腳本程序等，也可以是空操作。

在一個(gè)請求輸出對(duì)應(yīng)的測試結(jié)果之后，將判斷場景用例是否結(jié)束，即判斷場景用例中配置的所有最小測試單元是否均已執(zhí)行完畢并得到對(duì)應(yīng)的測試結(jié)果。若判定場景用例已結(jié)束，則根據(jù)所有最小測試單元對(duì)應(yīng)的測試結(jié)果生成本次測試對(duì)應(yīng)的輸出報(bào)告并結(jié)束本次測試。否則，則根據(jù)測試流程繼續(xù)發(fā)起或執(zhí)行對(duì)應(yīng)的請求。

圖3是測試平臺(tái)的測試流程示意圖，展示了場景用例從被調(diào)用開始，到獲得場景用例輸出的返回?cái)?shù)據(jù)，并根據(jù)數(shù)據(jù)分析計(jì)算得到接口協(xié)議的最終測試結(jié)果。

圖3 測試平臺(tái)流程示意圖

1.3 系統(tǒng)流程設(shè)計(jì)

Django是一個(gè)基于MVT設(shè)計(jì)模式實(shí)現(xiàn)的Python Web框架，具有構(gòu)建快速、功能強(qiáng)大、穩(wěn)定等優(yōu)點(diǎn)[9]。本文提出的測試平臺(tái)是基于Django框架來搭建后臺(tái)服務(wù)，在框架層面完成了包括但不限于用戶鑒權(quán)、日志記錄、序列化等通用基礎(chǔ)功能，并通過裝飾器形式對(duì)每個(gè)業(yè)務(wù)模塊提供能力，這樣的好處是開發(fā)過程中能更加聚焦每個(gè)模塊具體業(yè)務(wù)邏輯的實(shí)現(xiàn)。

LayUI是一款遵循原生網(wǎng)頁HTML/CSS/JS的書寫與組織習(xí)慣的國產(chǎn)前端UI框架[10]。控制臺(tái)的模塊化能力主要是基于一款Web腦圖可視化應(yīng)用——My-Mind.js實(shí)現(xiàn)的，和LayUI搭載使用能快速方便地對(duì)我們場景用例的構(gòu)建和調(diào)用進(jìn)行可視化操作。前端頁面和后臺(tái)服務(wù)的請求負(fù)載均衡是通過Nginx[11]做反向代理實(shí)現(xiàn)的，數(shù)據(jù)是通過RESTful API[12]進(jìn)行交互的。系統(tǒng)基于B/S架構(gòu)[13]實(shí)現(xiàn)了前后端分離的結(jié)構(gòu)，基于MVC模式[14]進(jìn)行開發(fā)，目的也是降低系統(tǒng)各個(gè)組件間的耦合度。

存儲(chǔ)方面，持久化數(shù)據(jù)使用了MySQL數(shù)據(jù)庫進(jìn)行存儲(chǔ)，后臺(tái)通過Django自帶的ORM模型操作數(shù)據(jù)庫實(shí)現(xiàn)增刪改查。文件類數(shù)據(jù)則使用了騰訊云的對(duì)象存儲(chǔ)服務(wù)COS，后臺(tái)可以通過XML API或者騰訊云通用SDK完成COS的基礎(chǔ)操作(包括讀寫改刪等)。整體的系統(tǒng)實(shí)現(xiàn)如圖4所示。

圖4 接口協(xié)議測試平臺(tái)系統(tǒng)實(shí)現(xiàn)架構(gòu)

2 系統(tǒng)實(shí)現(xiàn)

以一次基于HTTP協(xié)議的GET請求為例，來詳細(xì)說明由一個(gè)最小測試單元組成的場景測試用例的實(shí)現(xiàn)過程。該請求的數(shù)據(jù)格式見表1。

表1 接口協(xié)議請求數(shù)據(jù)格式

以請求“http://www.qq.com”為例，場景用例定義如圖5所示。

圖5 基于HTTP 協(xié)議的GET 請求示例

接口協(xié)議從請求信息獲取模塊解析到的參數(shù)數(shù)據(jù)如下：

{"url":"http://www.qq.com","headers":{"Content-Type":"application/json"},"version":"HTTP/1.1","met hod":"GET"}

通過場景用例組建模塊組建這個(gè)最小的測試單元，并將組建后的場景測試用例通過接口協(xié)議執(zhí)行模塊進(jìn)行調(diào)用，并返回結(jié)果。結(jié)果數(shù)據(jù)內(nèi)容如下：

{"List":[[{"Request":{"url":"http://www.qq.com","headers":{"Content-Type":"application/json"},"version":"HTTP/1.1","method":"GET"},"Action":"Ht tpGet","Runtime":"1/1","StartTime":"","EndTime":"","Result":true,"Response":{"text":"…","code":200}}]],"Result":true,"Report":"/autotest/report/xxx","Begi nTime":"","EndTime":""}

請求獲得返回?cái)?shù)據(jù)之后，將返回?cái)?shù)據(jù)賦值給檢測變量$res，然后判斷檢測變量$res是否等于預(yù)設(shè)輸出數(shù)據(jù)0。如果檢測變量$res等于預(yù)設(shè)輸出數(shù)據(jù)0，則判定請求對(duì)應(yīng)的測試通過。反之，則判定此次測試失敗。

此外，場景用例還可以包括一個(gè)或多個(gè)基于HTTP的POST請求，對(duì)遠(yuǎn)程服務(wù)器進(jìn)行Shell操作請求，對(duì)MySQL的增刪改查請求等，通過模塊化操作可以提高復(fù)雜場景測試執(zhí)行的便捷性和多樣性。圖6演示的就是模塊化接口協(xié)議測試平臺(tái)系統(tǒng)如何去構(gòu)建一個(gè)復(fù)雜的場景測試用例。

圖6 模塊化接口協(xié)議測試平臺(tái)

當(dāng)任務(wù)測試完成后，平臺(tái)會(huì)將各種測試數(shù)據(jù)及結(jié)果聚合成測試報(bào)告，并生成HTML郵件發(fā)送到用戶在系統(tǒng)里預(yù)設(shè)好的郵箱，測試報(bào)告展示內(nèi)容如圖7所示。

圖7 測試報(bào)告內(nèi)容詳情頁

3 結(jié)論

本文基于模塊化的思想，提出了一種“各司其職”的接口協(xié)議測試方法，并詳細(xì)介紹了該方法的設(shè)計(jì)和實(shí)現(xiàn)思路。實(shí)踐證明，該可視化平臺(tái)的易操作性可以協(xié)助測試執(zhí)行人員更好地保證產(chǎn)品的交付質(zhì)量和交付節(jié)奏。

下一階段的研究目標(biāo)是期望針對(duì)不同的接口協(xié)議、不同的測試用例自動(dòng)生成對(duì)應(yīng)的測試場景，以此來進(jìn)一步提高接口測試的工作效率和平臺(tái)的自動(dòng)化能力。