陳威宇

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

0 引言

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

測(cè)試過(guò)程需要判斷當(dāng)前請(qǐng)求是否為異步請(qǐng)求，若當(dāng)前的請(qǐng)求是為異步請(qǐng)求，則將請(qǐng)求加入到異步測(cè)試隊(duì)列中，同時(shí)開(kāi)始執(zhí)行該請(qǐng)求，并繼續(xù)調(diào)用場(chǎng)景測(cè)試流程中的下一請(qǐng)求。若當(dāng)前請(qǐng)求是同步請(qǐng)求，則直接執(zhí)行該請(qǐng)求，等待該請(qǐng)求響應(yīng)后，再調(diào)用下一請(qǐng)求。在異步測(cè)試隊(duì)列中，需要每隔預(yù)設(shè)時(shí)間查詢隊(duì)列中的異步測(cè)試請(qǐng)求的任務(wù)狀態(tài)(即輪詢操作)，并在異步測(cè)試單元的任務(wù)已完成或超時(shí)的時(shí)候，生成響應(yīng)信息。在請(qǐ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ù)。

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

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

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

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

圖3 測(cè)試平臺(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]。本文提出的測(cè)試平臺(tái)是基于Django框架來(lái)搭建后臺(tái)服務(wù)，在框架層面完成了包括但不限于用戶鑒權(quán)、日志記錄、序列化等通用基礎(chǔ)功能，并通過(guò)裝飾器形式對(duì)每個(gè)業(yè)務(wù)模塊提供能力，這樣的好處是開(kāi)發(fā)過(guò)程中能更加聚焦每個(gè)模塊具體業(yè)務(wù)邏輯的實(shí)現(xiàn)。

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

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

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

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

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

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

以請(qǐng)求“http://www.qq.com”為例，場(chǎng)景用例定義如圖5所示。

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

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

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

通過(guò)場(chǎng)景用例組建模塊組建這個(gè)最小的測(cè)試單元，并將組建后的場(chǎng)景測(cè)試用例通過(guò)接口協(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":""}

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

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

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

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

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

3 結(jié)論

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

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