本發(fā)明涉及測試領域，特別涉及一種模擬服務的方法、裝置及集中管理平臺。

背景技術：

隨著社會科學技術的發(fā)展，企業(yè)的管理內(nèi)部服務的系統(tǒng)涉及到的業(yè)務場景和聯(lián)調(diào)測試數(shù)據(jù)非常復雜，企業(yè)應用的系統(tǒng)很少孤立存在，大部分系統(tǒng)都是依賴于不同軟件供應商提供的服務拼裝到一起。而現(xiàn)有多種服務模擬框架或者系統(tǒng)基本都是需要編寫代碼而且主要是研發(fā)僅限于單元測試或者集成測試，且只支持HTTP、SOCKS等通用協(xié)議的模擬。而對于測試人員主要做是是黑盒測試，但編碼能力有限制和業(yè)務壓力，其要編寫一個mock去模擬外部服務困難重重，非常影響工作效率。特別是，一些大型互聯(lián)網(wǎng)公司，一個系統(tǒng)往往是依賴多個外部系統(tǒng)，涉及到的業(yè)務場景和聯(lián)調(diào)測試數(shù)據(jù)非常復雜，常常會遇到以下幾種情況：1、A服務調(diào)B服務，B服務由于某些原因不可用或不穩(wěn)定(例如登陸頁面調(diào)一個登陸的passport.api，但是passport.api連不上導致無法登陸)；2、A服務調(diào)B服務，B服務的數(shù)據(jù)或場景難以構造(例如登陸頁面調(diào)一個登陸的passport.api，passport.api會在某些極端情況下返回一些錯誤碼；3、自動化測試時，A服務調(diào)B服務，由于B服務不可控，數(shù)據(jù)經(jīng)常變動導致測試數(shù)據(jù)經(jīng)常變化。

因為以上原因，導致因依賴外部服務而無法進行服務操作，影響工作效率。

技術實現(xiàn)要素：

本發(fā)明的主要目的是提出一種模擬服務的方法、裝置及集中管理平臺，旨在提高模擬服務的工作效率。

為實現(xiàn)上述目的，本發(fā)明提出的一種模擬服務的方法，包括步驟：

模擬外部服務行為啟動模擬器初始化操作，在初始化后的模擬器的樁匹配器中編輯模擬匹配條件及預設響應；

模擬器啟動的與被測服務同一IP的監(jiān)聽鏈路攔截由被測服務發(fā)出的請求；

解析所攔截的請求并將解析后的請求傳送至模擬器的樁匹配器；

模擬器的樁匹配器接收解析后的請求，根據(jù)模擬匹配條件執(zhí)行匹配命令。

優(yōu)選地，所述模擬外部服務行為啟動模擬器初始化操作，在初始化后的模擬器的樁匹配器中編輯模擬匹配條件及預設響應的步驟包括：

根據(jù)被測服務的請求選擇模擬測試架構，且在所選擇的模擬測試架構中，模擬外部服務行為啟動一個或多個不同協(xié)議服務的模擬器；

根據(jù)被測服務的當前協(xié)議服務請求選擇模擬器當前協(xié)議鏈路的配置，將被測服務請求的IP修改為模擬器的IP，以將被測服務的請求指向模擬器啟動的監(jiān)聽鏈路的端口；

根據(jù)模擬外部服務行為的意圖，在模擬器的樁匹配器中編輯模擬匹配條件及預設響應為樁，參數(shù)化樁生成樁參數(shù)。

優(yōu)選地，所述根據(jù)被測服務的當前協(xié)議服務請求選擇模擬器當前協(xié)議鏈路的配置的步驟包括：若被測服務的當前協(xié)議服務為通用協(xié)議服務，則修改DNS配置，把被測服務請求的IP指向模擬器的IP，配置Nginx，利用Nginx的端口映射，把被測服務的請求指向模擬器啟動的監(jiān)聽鏈路的端口；若被測服務的當前協(xié)議服務為自定義協(xié)議服務，通過OSP的靜態(tài)路由的IP和端口，把被測服務請求的IP直接指向模擬器的IP和對應OSP鏈路的監(jiān)聽鏈路的端口。

優(yōu)選地，所述解析攔截的請求并將解析后的請求傳送至模擬器的樁匹配器的步驟包括：解析所攔截的請求生成請求參數(shù)；將請求參數(shù)轉(zhuǎn)換為統(tǒng)一的封裝不同協(xié)議的請求對象；傳送請求對象至模擬器的樁匹配器。

優(yōu)選地，所述模擬器的樁匹配器接收解析后的請求，根據(jù)模擬匹配條件執(zhí)行匹配命令的步驟包括：樁匹配器接收解析后的請求；調(diào)用樁參數(shù)；解析樁參數(shù)，以釋放模擬匹配條件和預設響應；調(diào)用模擬匹配條件，執(zhí)行匹配命令。

優(yōu)選地，所述模擬器的樁匹配器接收解析后的請求，根據(jù)模擬匹配條件執(zhí)行匹配命令的步驟之后包括：若匹配成功，模擬器的樁匹配器發(fā)送預設響應至被測服務；若匹配失敗，模擬器的樁匹配器轉(zhuǎn)發(fā)解析后的請求至外部服務，并接收外部服務發(fā)出的對請求的真實響應，傳送至被測服務。

優(yōu)選地，在所述模擬器的監(jiān)聽鏈路攔截由同一IP的被測服務發(fā)出的請求的步驟和所述解析攔截的請求并將解析后的請求傳送至模擬器的樁匹配器的步驟之間還包括：模擬器的監(jiān)聽鏈路監(jiān)測所攔截的請求；若監(jiān)測所攔截的請求不需要返回預設響應時，暫停所述監(jiān)聽鏈路，直接轉(zhuǎn)發(fā)被測服務發(fā)出的請求至外部服務，并接收外部服務對請求的真實響應返回至被測服務；若監(jiān)測所攔截的請求不需要使用模擬器時，停止所述監(jiān)聽鏈路，模擬服務關閉監(jiān)聽端口，返回報錯信息。

優(yōu)選地，所述模擬外部服務行為啟動模擬器初始化操作，在初始化后的模擬器的樁匹配器中編輯模擬匹配條件及預設響應的步驟之前包括：呈現(xiàn)解耦依賴的執(zhí)行情況時，執(zhí)行解耦依賴。

本申請還提供了一種模擬服務的裝置，包括：初始化模塊，用于模擬外部服務行為啟動模擬器初始化操作，在初始化后的模擬器的樁匹配器中編輯模擬匹配條件及預設響應；監(jiān)聽模塊，用于與被測服務同一IP的模擬器啟動的監(jiān)聽鏈路攔截由被測服務發(fā)出的請求；報文解析模塊，用于解析所攔截的請求并將解析后的請求傳送至模擬器的樁匹配器；執(zhí)行模塊，用于模擬器的樁匹配器接收解析后的請求，根據(jù)模擬匹配條件執(zhí)行匹配命令。

優(yōu)選地，還包括響應模塊，用于若匹配成功，模擬器的樁匹配器發(fā)送預設響應至被測服務；還用于若匹配失敗，接收外部服務發(fā)出的對請求的真實響應，傳送至被測服務；轉(zhuǎn)發(fā)模塊，用于若匹配失敗，模擬器的樁匹配器轉(zhuǎn)發(fā)解析后的請求至外部服務；解耦依賴模塊，用于呈現(xiàn)解耦依賴的執(zhí)行情況時，執(zhí)行解耦依賴；監(jiān)測模塊，用于模擬器的監(jiān)聽鏈路監(jiān)測所攔截的請求；監(jiān)測執(zhí)行模塊，用于若監(jiān)測所攔截的請求不需要返回預設響應時，暫停模擬器的鏈路，直接轉(zhuǎn)發(fā)被測服務發(fā)出的請求至外部服務，并接收外部服務對請求的真實響應返回至被測服務；還用于若監(jiān)測所攔截的請求不需要使用模擬器時，停止模擬器的鏈路，模擬服務關閉監(jiān)聽端口，返回報錯信息。

優(yōu)選地，所述初始化模塊包括：模擬測試架構單元，用于根據(jù)被測服務的請求選擇模擬測試架構，且在在所選擇的模擬測試架構中，模擬外部服務行為啟動一個或多個不同協(xié)議服務的模擬器；模擬多種協(xié)議服務單元，用于模擬外部服務行為啟動一個或多個不同協(xié)議服務的模擬器；服務端口配置單元，用于根據(jù)被測服務的當前協(xié)議服務請求選擇模擬器當前協(xié)議鏈路的配置，以修改被測服務請求的IP為模擬器的IP，將被測服務的請求指向模擬器啟動的監(jiān)聽鏈路的端口；樁單元，用于根據(jù)模擬外部服務行為的意圖，在模擬器的樁匹配器中編輯模擬匹配條件及預設響應為樁，參數(shù)化樁生成樁參數(shù)。

優(yōu)選地，所述服務端口配置單元包括：通用協(xié)議配置子單元，用于若被測服務的當前協(xié)議服務為通用協(xié)議服務，則修改DNS配置，把被測服務請求的IP指向模擬器的IP，配置Nginx，利用Nginx的端口映射，把被測服務的請求指向模擬器啟動的監(jiān)聽鏈路的端口；自定義協(xié)議配置子單元，用于若被測服務的當前協(xié)議服務為自定義協(xié)議服務，通過OSP的靜態(tài)路由的IP和端口，把被測服務請求的IP直接指向模擬器的IP和對應OSP鏈路的監(jiān)聽鏈路的端口。

優(yōu)選地，所述報文解析模塊包括：解析單元，用于解析所攔截的請求生成請求參數(shù)；封裝單元，用于將請求參數(shù)轉(zhuǎn)換為統(tǒng)一的封裝不同協(xié)議的請求對象；傳送單元，用于傳送請求對象至模擬器的樁匹配器。

優(yōu)選地，所述執(zhí)行模塊包括：接收單元，用于樁匹配器接收解析后的請求；調(diào)用單元，用于調(diào)用樁參數(shù)；釋放單元，用于解析樁參數(shù)，以釋放模擬匹配條件和預設響應；執(zhí)行單元，用于調(diào)用模擬匹配條件，執(zhí)行匹配命令。

本發(fā)明還公開了一種模擬服務的集中管理平臺，包括：一個或多個不同協(xié)議的如上所述的模擬服務的裝置；及UI交互模塊，用于建立UI交互測試模型及交互規(guī)范，編輯靜態(tài)HTML，以負責所有模擬服務的交互對接；及日志管理模塊，用于提供日志管理功能，可對模擬測試的結(jié)果進行日志的記錄、查看、下載及清理；及模擬數(shù)據(jù)庫，用于存儲模擬服務的所有數(shù)據(jù)。

在本發(fā)明中，通過采用簡單的配置操作，如NGINX配置、模擬器的多種協(xié)議鏈路配置及樁配置，和豐富智能匹配規(guī)則，如包含、相等、正則表達式匹配和外部傳參等完成模擬服務的自動化配置，實現(xiàn)了一種智能化匹配，簡化工作程序，提高模擬服務的工作效率。

附圖說明

為了更清楚地說明本發(fā)明實施例或現(xiàn)有技術中的技術配置，下面將對實施例或現(xiàn)有技術描述中所需要使用的附圖作簡單地介紹，顯而易見地，下面描述中的附圖僅僅是本發(fā)明的一些實施例，對于本領域普通技術人員來講，在不付出創(chuàng)造性勞動的前提下，還可以根據(jù)這些附圖示出的結(jié)構獲得其他的附圖。

圖1為本發(fā)明模擬服務的方法第一實施例的流程示意圖；

圖2為本發(fā)明一實施例中模擬外部服務行為啟動模擬器初始化操作，在初始化后的模擬器的樁匹配器中編輯模擬匹配條件及預設響應的流程示意圖；

圖3為本發(fā)明一實施例中根據(jù)被測服務的當前協(xié)議服務請求選擇模擬器當前協(xié)議鏈路的配置的流程示意圖；

圖4為本發(fā)明一實施例中解析攔截的請求并將解析后的請求傳送至模擬器的樁匹配器的步流程示意圖；

圖5為本發(fā)明一實施例中模擬器的樁匹配器接收解析后的請求，根據(jù)模擬匹配條件執(zhí)行匹配命令的流程示意圖；

圖6為本發(fā)明模擬服務的方法第二實施例的流程示意圖；

圖7為本發(fā)明模擬服務的方法第三實施例的流程示意圖；

圖8為本發(fā)明模擬服務的裝置的第一實施例的功能模塊示意圖；

圖9為本發(fā)明模擬服務的裝置的第二實施例的功能模塊示意圖

圖10為本發(fā)明一實施例中初始化模塊的細化功能模塊示意圖；

圖11為本發(fā)明一實施例中服務端口配置單元的細化功能模塊示意圖；

圖12為本發(fā)明一實施例中報文解析模塊的細化功能模塊示意圖；

圖13為本發(fā)明一實施例中執(zhí)行模塊的細化功能模塊示意圖。

本發(fā)明目的的實現(xiàn)、功能特點及優(yōu)點將結(jié)合實施例，參照附圖做進一步說明。

具體實施方式

下面將結(jié)合本發(fā)明實施例中的附圖，對本發(fā)明實施例中的技術配置進行清楚、完整地描述，顯然，所描述的實施例僅僅是本發(fā)明的一部分實施例，而不是全部的實施例?；诒景l(fā)明中的實施例，本領域普通技術人員在沒有作出創(chuàng)造性勞動前提下所獲得的所有其他實施例，都屬于本發(fā)明保護的范圍。

需要說明，若本發(fā)明實施例中有涉及方向性指示(諸如上、下、左、右、前、后……)，則該方向性指示僅用于解釋在某一特定姿態(tài)(如附圖所示)下各部件之間的相對位置關系、運動情況等，如果該特定姿態(tài)發(fā)生改變時，則該方向性指示也相應地隨之改變。

參照圖1，圖1為本申請實施例提供的一種模擬服務的方法的流程示意圖，本發(fā)明提供了一種模擬服務的方法，步驟如下：

步驟S10，模擬外部服務行為啟動模擬器初始化操作，在初始化后的模擬器的樁匹配器中編輯模擬匹配條件及預設響應；

在步驟S10中，模擬器初始化操作需要完成兩個方面的預備，第一，需要部署測試環(huán)境(主要指硬件環(huán)境)，以為模擬器的模擬服務提供穩(wěn)定而可控的環(huán)境，提高模擬器的工作質(zhì)量和效率。預先運行構建或部署與被測服務和外部服務之間網(wǎng)絡通信服務接口的對接、建立WEB UI交互測試模型、構建多種測試類型框架、封裝有不同協(xié)議的鏈路配置，根據(jù)被測服務的協(xié)議服務部署被測服務的服務端口配置及呈現(xiàn)解耦依賴情況時，執(zhí)行解耦依賴，以繞開所依賴的外部服務的端口。而這些測試環(huán)境的部署均有一個集中管理數(shù)個模擬器的模擬服務平臺來完成，首先建立模擬器與被測服務和外部服務之間的網(wǎng)絡通信；接著建立WEB UI界面交互測試模型及交互規(guī)范，以下的步驟均在界面操作，而無需編碼；再針對被測服務的需求構建多種測試類型的框架，比如：單元測試、集成測試、自動化測試、功能測試及壓力測試，每種測試類型的框架內(nèi)存儲有模擬外部服務行為的測試用例的測試模塊；根據(jù)不同協(xié)議服務給每個模擬器封裝不同協(xié)議的鏈路配置；根據(jù)被測服務的協(xié)議服務修改被測服務的目標服務端口配置，被測的A服務(即被測服務)原來是依賴外部的B服務(即外部服務)，現(xiàn)在A服務的目標服務不指向B服務而改為指向模擬器。第二，需要部署測試服務(主要指軟件環(huán)境)，以為本發(fā)明的測試方法提供測試對象。測試服務包括測試管理單元和測試執(zhí)行單元，模擬器等同于測試管理單元，所述模擬器管理單次模擬測試的運行，而模擬器中虛擬一個樁匹配器(Stub Matcher)等同于測試執(zhí)行單元，所述樁匹配器實行模擬測試執(zhí)行控制，具體來說是，模擬器中的測試模塊存儲模擬外部服務行為的測試用例，樁匹配器用于模擬測試模塊的調(diào)用條件的元件，以代替測試模塊的接口，接受或傳遞測試模塊的數(shù)據(jù)，其中，所述測試模塊的調(diào)用條件即為在樁匹配器中編輯的模擬匹配條件，或者是，通過注冊自定義服務事件的API函數(shù)編輯自定義服務的模擬測試匹配條件。樁匹配器根據(jù)模擬測試匹配條件實行測試控制。

特別說明地是，構建功能測試框架時，是單獨啟動的平臺提供的壓測包，所述的壓測包支持通用協(xié)議和自定義協(xié)議，通用協(xié)議如HTTP協(xié)議(超文本傳輸協(xié)議)和自定義協(xié)議如OSP協(xié)議(一種網(wǎng)域間授權、路由和計費的國際標準協(xié)議)，場景事例：OSP協(xié)議的壓測服務模擬，而且壓測包也是使用Web界面指定鏈路的樁設置，無需重復配置。步驟為：首先一鍵下載平臺提供的壓測包，啟動壓測模擬器，進行壓力模擬測試，通過界面直接查看測試結(jié)果。

本申請模擬器的初始化還包括創(chuàng)建模擬器，所述模擬器用于模擬與被測的A服務進行真實交互的外部B服務。所述模擬器可以采用JETTY服務器，該JETTY服務器為一個開源的servelet容器(servelet是用JAVA編寫的服務器端程序，主要功能在于交互式地瀏覽和修改數(shù)據(jù)，生成動態(tài)WEB內(nèi)容)，是基于JAVA的WEB容器。JETTY服務器可以作為嵌入式服務器使用，JETTY服務器的運行速度較快，而且是輕量級的，JETTY服務器是使用Java語言編寫的，它的API以一組JAR包的形式發(fā)布。JAR包(JAVA的封裝包)管理用于RPC協(xié)議模擬(Remote Procedure Call Protocol--遠程過程調(diào)用協(xié)議，它是一種通過網(wǎng)絡從遠程計算機程序上請求服務，而不需要了解底層網(wǎng)絡技術的協(xié)議)，統(tǒng)一管理客戶端的JAR包，可以理解地，JAR包可用于解析不同協(xié)議服務。則測試中當被測的A服務通過接口調(diào)用外部的B服務進行交互時，改為調(diào)用模擬器模擬該交互，即把原本被測的A服務請求修改指向，不再指向B服務而改為指向模擬器。

步驟S20，模擬器啟動的與被測服務同一IP的監(jiān)聽鏈路攔截由被測服務發(fā)出的請求；

在步驟S20中，模擬器的初始化完成后會啟動所有的鏈路監(jiān)聽，當模擬器啟動的監(jiān)聽鏈路監(jiān)聽到與被測服務同一IP的請求，才會攔截該所監(jiān)聽到的請求，即裭測服務的發(fā)出的請求。本申請中的“IP”即為IP地址(Internet Protocol Address，又譯為網(wǎng)際協(xié)議地址)。

步驟S30，解析所攔截的請求并將解析后的請求傳送至模擬器的樁匹配器；

在步驟S30中，對所攔截的請求進行報文解析，將請求的報文數(shù)據(jù)按照系統(tǒng)內(nèi)定義規(guī)則解析，解析后的請求生成請求的相關數(shù)據(jù)，再將請求的相關數(shù)據(jù)傳送至模擬器的樁匹配器。所述步驟S30實際是模擬器普通模擬匹配執(zhí)行之前被測服務請求接收的過程

步驟S40，模擬器的樁匹配器接收解析后的請求，根據(jù)模擬匹配條件執(zhí)行匹配命令。

在步驟S40中，所述模擬器的樁匹配器接收解析后的請求的步驟應該理解地是模擬器的樁匹配一旦接收請求就意味著模擬匹配的啟動執(zhí)行，所述樁匹配器開始實行模擬測試執(zhí)行控制。所述模擬測試執(zhí)行控制包括模擬匹配條件的調(diào)用、模擬匹配的運行判斷及判斷后的響應執(zhí)行等。所述的步驟S40實際是模擬器普通模擬匹配執(zhí)行之前的樁參數(shù)化相呼應的解參過程，

參照圖2，具體地，在本實施例中，步驟S10包括：

步驟S101，根據(jù)被測服務的請求選擇模擬測試架構，且在所選擇的模擬測試架構中，模擬外部服務行為啟動一個或多個不同協(xié)議服務的模擬器；

在步驟S101中，外部服務行為可能是一種協(xié)議服務的測試用例，也可能是多種協(xié)議服務的測試用例，而一個被測服務可能同時依賴多個不同的外部服務，預先存儲模擬所述外部服務行為的測試用例于測試管理單元——模擬器，所以模擬器的初始化操作的啟動時，需要啟動一個或多個與外部服務相對應的模擬器。

所述模擬測試架構是提供模擬測試用例的模擬測試分析工具，它包括模擬測試的測試模塊、管理模塊和統(tǒng)計分析模塊，所述測試模塊用于執(zhí)行不同測試類型的模擬匹配命令時，提供所調(diào)用的模擬測試用例，且所述的模擬測試用例是可反復使用的；所述管理模塊用于管理不同模擬測試類型的模擬測試用例的調(diào)用；所述統(tǒng)計分析模塊用于統(tǒng)計且分析所述模擬測試的結(jié)果。所述模擬測試架構根據(jù)模擬測試預期的不同區(qū)分為不同的測試類型，再模擬不同的測試類型建立的模擬測試架構，所述模擬測試架構包括單元測試架構、集成測試架構、功能測試架構和壓力測試架構，每種所述模擬測試架構是提取每種測試類型的共性部分組成的獨立的體系結(jié)構。

步驟S102，根據(jù)被測服務的當前協(xié)議服務請求選擇模擬器當前協(xié)議鏈路的配置，以修改被測服務請求的IP為模擬器的IP，將被測服務的請求指向模擬器啟動的監(jiān)聽鏈路的端口；

在步驟S102中，模擬服務的集中管理平臺接收請求后，獲取請求URL(Uniform Resource Locator，統(tǒng)一資源定位符)地址上的協(xié)議類型，轉(zhuǎn)交給適配協(xié)議類型的模擬器進行處理，應該理解地是，模擬服務的集中管理平臺有模擬通用協(xié)議服務和模擬自定義協(xié)議服務之分，所以服務端口配置單元根據(jù)不同協(xié)議服務修改被測服務、外部服務和模擬器的端口配置，以便模擬器進入代理服務器的角色。

步驟S103，根據(jù)模擬外部服務行為的意圖，在模擬器的樁匹配器中編輯模擬匹配條件及預設響應為樁，參數(shù)化樁生成樁參數(shù)。

在步驟S103中，所述根據(jù)模擬外部服務行為的意圖，即為模擬外部服務行為的測試用例的調(diào)用條件，也就是說，所述調(diào)用條件與所述外部服務行為的意圖是相對應。而在計算機系統(tǒng)中，將所述調(diào)用條件函數(shù)化生成為模擬匹配條件。所述函數(shù)化即把模擬匹配條件由系統(tǒng)內(nèi)定規(guī)則定義為函數(shù)式，而預設響定義為函數(shù)式的返回值，而由模擬匹配條件及預設響應編輯成的樁即為由兩者組成的計算式。所述參數(shù)化樁生成樁參數(shù)，又是計算機運行中另一技巧，所述參數(shù)化樁就是在函數(shù)定義時候傳入形參，而相對地，解析參數(shù)就是調(diào)用函數(shù)時傳入實參。樁參數(shù)化的過程是：配置樁的參數(shù)的格式，添加樁參數(shù)，完成參數(shù)化，生成樁參數(shù)。樁的參數(shù)化用以適配多種協(xié)議的不同外部服務。應該理解地是，樁函數(shù)可以自動生成，也可自定義，但自動生成的樁函數(shù)與自定義的樁函數(shù)其主要差別在于：自定義的樁函數(shù)調(diào)用優(yōu)先級別高于原函數(shù)，原函數(shù)的優(yōu)先級別高于自動生成的樁函數(shù)。舉個例子，假定在代碼中能夠找到某個函數(shù)的原本定義，此時自動生成的樁函數(shù)是無效的，因為原函數(shù)優(yōu)先級別高于自動生成的樁函數(shù)。而自定義樁函數(shù)可以帶來的好處在于：調(diào)用原函數(shù)可能其返回值為一個固定值，不能返回一個期望值，以使得測試不同的代碼分支。而樁函數(shù)的返回值，可由用戶自由控制，因而具備更大的靈活性。

所述的模擬匹配具有豐富的匹配規(guī)則，樁的匹配條件邏輯上支持多個樁之間的AND，OR和NOT關系；匹配的操作符支持equals(值相等)，contains(值包含)，regex(值正則表達式匹配)。而所述的預設響應根據(jù)不同的模擬匹配條件，通過beanshel(一種JAVA源碼解釋器)動態(tài)生成。

需要說明的是，樁根據(jù)測試用例數(shù)據(jù)中的特定數(shù)據(jù)的不同，而區(qū)分為公共樁和私有樁，所述公共樁即可在該鏈路里新建并被調(diào)用，也可以是抓取redis(redis是一個開源的使用ANSI C語言編寫、支持網(wǎng)絡、可基于內(nèi)存亦可持久化的日志型、Key-Value數(shù)據(jù)庫，并提供多種語言的API)的數(shù)據(jù)自動生成，可被與公共樁關聯(lián)于同一個IP下的鏈路調(diào)用，所述私有樁只能在該鏈路里新建，并只為該鏈路私有。這里所說的新建樁包括自定義樁函數(shù)和原函數(shù)。

特別需要說明地是，公共樁還具有錄制規(guī)則，所述公共樁的錄制途徑有兩種：1、從外部服務系統(tǒng)抓取流量進行錄制，場景：平臺與ApiTester(接口測試平臺)和DCT(造數(shù)據(jù)平臺)對接時，因為ApiTester和DCT的測試時,所有正常的接口請求和響應會發(fā)送一個公共的redis做緩存，平臺會定時從redis提取這些數(shù)據(jù)自動生成公共樁；2、當模擬器不匹配請求時，通過樁錄制器(Stub Recorder)錄制模擬器攔截且不匹配直接轉(zhuǎn)發(fā)的請求和響應生成為公共樁。所述公共樁錄制規(guī)則可以由內(nèi)部代碼預先建立默認規(guī)則后自動生成錄制規(guī)則，也可以在頁面人為設置。

而本發(fā)明的參數(shù)化樁也是智能匹配功能的一種體現(xiàn)。樁的匹配條件和模擬響應也都隨之參數(shù)化，應該理解地是，如果樁配置的參數(shù)格式是＄{參數(shù)名}，當設置了參數(shù)格式后，樁參數(shù)也必須設置，否則被測服務請求均會匹配不成功，只有重新設置了樁參數(shù)，讓樁參數(shù)替換掉匹配條件和模擬響應的格式化參數(shù)，這時再請求一次，才可以看到應該得到的響應。

參照圖3，在本實施例中，所述步驟S102具體來說包括以下步驟：

步驟S1021，若被測服務的當前協(xié)議服務為通用協(xié)議服務，則修改DNS配置，把被測服務請求的IP指向模擬器的IP，配置Nginx，利用Nginx的端口映射，把被測服務的請求指向模擬器啟動的監(jiān)聽鏈路的端口；

步驟S1022，若被測服務的當前協(xié)議服務為自定義協(xié)議服務，通過OSP的靜態(tài)路由的IP和端口，把被測服務請求的IP直接指向模擬器的IP和對應OSP鏈路的監(jiān)聽鏈路的端口。

應該理解地是，本實施例中，把協(xié)議服務分為通用協(xié)議服務和自定義協(xié)議服務，具體地，服務模擬平臺針對不同協(xié)議服務有以下幾種模擬的方案：

1)HTTP/Thrift協(xié)議模擬：

用戶通過修改DNS配置(全名Domain Name System，域名系統(tǒng)，因特網(wǎng)上作為域名和IP地址相互映射的一個分布式數(shù)據(jù)庫，能夠使用戶更方便的訪問互聯(lián)網(wǎng)，而不用去記住能夠被機器直接讀取的IP數(shù)串)，把B服務的IP指向平臺模擬器的IP，通過平臺內(nèi)置的Nginx把A服務的請求指向模擬器啟動的監(jiān)聽鏈路的端口。

2)OSP協(xié)議模擬：

用戶把B服務的IP通過OSP的靜態(tài)路由的IP和端口直接指向模擬器的IP和對應OSP鏈路的監(jiān)聽鏈路的端口。

需要補充說明的是，Nginx是一個高性能的HTTP和反向代理服務器，本發(fā)明只是用了Nginx的端口映射功能，用于HTTP協(xié)議或Thrift協(xié)議模擬(Thrift是一個服務端和客戶端的架構體系，使不同語言開發(fā)的系統(tǒng)可以通過該框架進行通信)，平臺內(nèi)置Nginx，用戶無需再使用服務器操作Nginx，只需在頁面上配置。如在Nginx配置頁面配置是：Server Name:cart.api.vip.com listen Port:80默認監(jiān)聽端口:1234，實際會在Nginx生成一個配置文件內(nèi)容如下：

表示cart.api.vip.com域的請求并且端口是80的，統(tǒng)一轉(zhuǎn)發(fā)到監(jiān)聽端口是1234的鏈路。例如請求是http://cart.api.vip.com:80/xxx,通過Nginx轉(zhuǎn)發(fā)后變?yōu)閔ttp://127.0.0.1:1234。

Nginx反向代理的原理是指以代理服務器來接受internet上的連接請求，然后將請求轉(zhuǎn)發(fā)給內(nèi)部網(wǎng)絡上的服務器，并將從服務器上得到的結(jié)果返回給internet上請求連接的客戶端，此時代理服務器對外就表現(xiàn)為一個服務器。

具體地，參照圖4，步驟S30包括：

步驟S301，解析所攔截的請求生成請求參數(shù)；

在步驟S301中，所述鏈路啟動的時候會啟動一個InboundChannel(InboundChannel專門用于A服務和模擬器間通信的通道)，用于監(jiān)聽收到的來自A服務的請求。

步驟S302，將請求參數(shù)轉(zhuǎn)換為統(tǒng)一的封裝不同協(xié)議的請求對象；

在步驟S302中，收到請求后，通過Request Extrator(請求出口)對請求的參數(shù)進行提取(如uri,body的參數(shù))，轉(zhuǎn)為一個RequestElement(請求對象)，如：HTTP，OSP等不同協(xié)議的請求內(nèi)容統(tǒng)一轉(zhuǎn)換為RequestElement(請求對象)，即封裝有不同協(xié)議的請求參數(shù))。

步驟S303，傳送請求對象至模擬器的樁匹配器。

在步驟S303中，模擬器再把RequestElement傳入樁匹配器(Stub Matcher)與用戶預設的樁進行匹配。應該理解地是，整個把請求解析為RequestElement的操作均是由模擬器的內(nèi)部代碼實現(xiàn)。

具體地，參照圖5，步驟S40包括：

步驟S401，樁匹配器接收解析后的請求；

步驟S402，調(diào)用樁參數(shù)；

步驟S403，解析樁參數(shù)，以釋放模擬匹配條件和預設響應；

步驟S404，調(diào)用模擬匹配條件，執(zhí)行匹配命令。

樁可以是一個常量，也可以是一個變量，這樣，把樁定義為一個函數(shù)，函數(shù)定義時候傳入的參數(shù)叫形參，而調(diào)用函數(shù)時傳入的參數(shù)叫實參，模擬器先替換掉樁里區(qū)配條件和預設響應的參數(shù)，釋放出模擬匹配條件和預設響應的原函數(shù)，然后再調(diào)用模擬匹配條件，執(zhí)行匹配命令。

參照圖6，在第二實施例中，在步驟S40之后還包括：

步驟S50，若匹配成功，模擬器的樁匹配器發(fā)送預設響應至被測服務；

步驟S60，若匹配失敗，模擬器的樁匹配器轉(zhuǎn)發(fā)解析后的請求至外部服務，并接收外部服務發(fā)出的對請求的真實響應，傳送至被測服務。

在第二實施例中，步驟S50和步驟S60是步驟S40之后還包括響應措施，即當匹配成功，模擬器的樁匹配器發(fā)送預設響應至被測服務；當匹配失敗時，模擬器轉(zhuǎn)發(fā)請求至外部服務，并接收外部服務發(fā)出的對請求的真實響應，傳送至被測服務。此時，所述的樁匹配器僅做為一個中轉(zhuǎn)站，轉(zhuǎn)發(fā)請求并接收外部服務對請求的真實響應，再轉(zhuǎn)發(fā)至被測服務。

參照圖7，在第三實施例中，在步驟S20與步驟S30之間還包括：

步驟S70，模擬器的監(jiān)聽鏈路監(jiān)測所攔截的請求；

步驟S80，若監(jiān)測所攔截的請求不需要返回預設響應時，暫停模擬器的鏈路，直接轉(zhuǎn)發(fā)被測服務發(fā)出的請求至外部服務，并接收外部服務對請求的真實響應返回至被測服務；

步驟S90，若監(jiān)測所攔截的請求不需要使用模擬器時，停止模擬器的鏈路，模擬服務關閉監(jiān)聽端口，返回報錯信息。

在本實施例中，考慮到企業(yè)用戶業(yè)務的復雜性，為了滿足用戶各種業(yè)務的需求不同，所述模擬器通過鏈路狀態(tài)的控制來完成監(jiān)測請求的功能，應該理解地是，監(jiān)測請求的同時是結(jié)合業(yè)務的需求，如果業(yè)務不需要匹配直接轉(zhuǎn)發(fā)的時候可以暫停模擬器的鏈路，如果業(yè)務不使用模擬器，可以停止模擬器的鏈路，模擬服務關閉監(jiān)聽端口，被測服務再發(fā)起請求到模擬器，會收到連接失敗的報錯信息。

在第四實施例中，步驟S10之前還包括：

呈現(xiàn)解耦依賴的情況時，執(zhí)行解耦依賴，以繞開所依賴外部服務的接口。

在本實施例中，被測的A服務原來是依賴外部的B服務，現(xiàn)在在被測的A服務和外部的B服務之間建立一個開放式的集中管理諸多所述模擬器的平臺，而平臺通過接口與不同的外部服務器協(xié)同交互來處理被測服務的業(yè)務。應當理解地是，計算中的耦合偏向于兩者或多者的彼此影響，解耦就是要解除這種影響，增強各自的獨立存在能力，可以無限降低存在的耦合度，但不能根除，否則就失去了彼此的關聯(lián)，失去了存在意義。

服務模擬平臺的作用是服務解耦，可用于研發(fā)或測試人員繞開外部服務單獨測試自己負責的服務。服務解耦場景：1)A服務調(diào)B服務，B服務由于某些原因不可用或不穩(wěn)定，例如登陸頁面調(diào)一個登陸的passport.api，但是passport.api連不上導致無法登陸；2)A服務調(diào)B服務，B服務的數(shù)據(jù)或場景難以構造，例如登陸頁面調(diào)一個登陸的passport.api，passport.api會在某些極端情況下返回一些錯誤碼；3)自動化測試時，A服務調(diào)B服務，由于B服務不可控，數(shù)據(jù)經(jīng)常變動導致測試數(shù)據(jù)經(jīng)常變化。比如：Jetty可以從test case中控制其運行，從而可以使自動化測試不再依賴外部環(huán)境，順利實現(xiàn)自動化測試。

參照圖8，本發(fā)明還公開了一種模擬服務的裝置，該裝置包括：

初始化模塊10，用于模擬外部服務行為啟動模擬器初始化操作，在初始化后的模擬器的樁匹配器中編輯模擬匹配條件及預設響應；

監(jiān)聽模塊20，用于與被測服務同一IP的模擬器啟動的監(jiān)聽鏈路攔截由被測服務發(fā)出的請求；

報文解析模塊30，用于解析所攔截的請求并將解析后的請求傳送至模擬器的樁匹配器；

執(zhí)行模塊40，用于模擬器的樁匹配器接收解析后的請求，根據(jù)模擬匹配條件執(zhí)行匹配命令。

在本實施例中，模擬器初始化操作需要完成兩個方面的預備，第一，需要部署測試環(huán)境(主要指硬件環(huán)境)，以為模擬器的模擬服務提供穩(wěn)定而可控的環(huán)境，提高模擬器的工作質(zhì)量和效率。預先運行構建或部署與被測服務和外部服務之間網(wǎng)絡通信服務接口的對接、建立WEB UI交互測試模型、構建多種測試類型框架、封裝有不同協(xié)議的鏈路配置，根據(jù)被測服務的協(xié)議服務部署被測服務的服務端口配置及呈現(xiàn)解耦依賴情況時，執(zhí)行解耦依賴，以繞開所依賴的外部服務的端口。而這些測試環(huán)境的部署均有一個集中管理數(shù)個模擬器的模擬服務平臺來完成，首先建立模擬器與被測服務和外部服務之間的網(wǎng)絡通信；接著建立WEB UI界面交互測試模型及交互規(guī)范，以下的步驟均在界面操作，而無需編碼；再針對被測服務的需求構建多種測試類型的框架，比如：單元測試、集成測試、自動化測試、功能測試及壓力測試；根據(jù)不同協(xié)議服務給每個模擬器封裝不同協(xié)議的鏈路配置；根據(jù)被測服務的協(xié)議服務修改被測服務的目標服務端口配置，被測的A服務(即被測服務)原來是依賴外部的B服務(即外部服務)，現(xiàn)在A服務的目標服務不指向B服務而改為指向模擬器。第二，需要部署測試服務(主要指軟件環(huán)境)，以為本發(fā)明的測試方法提供測試對象。測試服務包括測試管理單元和測試執(zhí)行單元，模擬器等同于測試管理單元，而模擬器中虛擬一個樁匹配器等同于測試執(zhí)行單元，具體來說是，在模擬器中預先存儲模擬外部服務行為的測試用例，在模擬器的樁匹配器中編輯模擬測試的匹配條件及預設響應，或者是，通過注冊自定義服務事件的API函數(shù)編輯自定義服務的模擬測試匹配條件及預設響應，在模擬器中的樁匹配器里將模擬測試匹配條件及預設響應編輯為樁，且將樁參數(shù)化生成樁參數(shù)，樁匹配器根據(jù)模擬測試匹配條件實行測試控制。

特別說明地是，構建功能測試框架時，是單獨啟動的平臺提供的壓測包，所述的壓測包支持通用協(xié)議，比如HTTP協(xié)議和自定義協(xié)議，比如OSP協(xié)議的壓測時的服務模擬，而且壓測包也是使用Web界面指定鏈路的樁設置，無需重復配置。步驟為：首先一鍵下載平臺提供的壓測包，啟動壓測模擬器，進行壓力模擬測試，通過界面直接查看測試結(jié)果。

本發(fā)明所述的方法完全采用WEB UI的可視化操作界面，配置共享，用戶使用時無需任何技能，也不需了解技術細節(jié)也就是說無需自己編碼，就能實現(xiàn)服務的摸擬，大大地提高了聯(lián)調(diào)測試的效率。

本申請模擬器的初始化還包括創(chuàng)建模擬器，所述模擬器用于模擬與被測的A服務進行真實交互的外部B服務。所述模擬器可以采用JETTY服務器，該JETTY服務器為一個開源的servelet容器，是基于JAVA的WEB容器。Jetty可以作為嵌入式服務器使用，Jetty的運行速度較快，而且是輕量級的，Jetty是使用Java語言編寫的，它的API以一組JAR包的形式發(fā)布。JAR包管理用于RPC協(xié)議模擬，統(tǒng)一管理客戶端的JAR包，可以理解地，JAR包可用于解析不同協(xié)議服務。則測試中當被測的A服務通過接口調(diào)用外部的B服務進行交互時，改為調(diào)用模擬器模擬該交互，即把原本被測的A服務請求修改指向，不再指向B服務而改為指向模擬器。

本申請模擬器啟動后，模擬器啟動的監(jiān)聽鏈路的端口開始監(jiān)聽，當監(jiān)聽到具有與模擬器相同IP的請求時，攔截該請求，報文解析請求，并將解析后的請求發(fā)送至樁匹配器。樁匹配器接收請求后，根據(jù)模擬匹配條件執(zhí)行匹配命令，樁匹配器開始測試控制，若匹配成功，樁匹配器推出模擬測試的預設響應返回至被測服務。

參照圖8，本發(fā)明提供的一種模擬服務的裝置的第二實施例，所述的模擬服務的裝置還包括：

響應模塊50，用于若匹配成功，模擬器的樁匹配器發(fā)送預設響應至被測服務；還用于接收外部服務發(fā)出的對請求的真實響應，傳送至被測服務；

轉(zhuǎn)發(fā)模塊60，用于若匹配失敗，模擬器的樁匹配器轉(zhuǎn)發(fā)解析后的請求至外部服務；

解耦依賴模塊70，用于呈現(xiàn)解耦依賴的執(zhí)行情況時，執(zhí)行解耦依賴；

監(jiān)測模塊80，用于模擬器的監(jiān)聽鏈路監(jiān)測所攔截的請求；

監(jiān)測執(zhí)行模塊90，用于若監(jiān)測所攔截的請求不需要返回預設響應時，暫停模擬器的鏈路，直接轉(zhuǎn)發(fā)被測服務發(fā)出的請求至外部服務，并接收外部服務對請求的真實響應返回至被測服務；還用于若監(jiān)測所攔截的請求不需要使用模擬器時，停止模擬器的鏈路，模擬服務關閉監(jiān)聽端口，返回報錯信息。

在第二實施例中，還包括響應模塊50，即當匹配成功，模擬器的樁匹配器發(fā)送預設響應至被測服務；當匹配失敗時，模擬器轉(zhuǎn)發(fā)請求至外部服務，并接收外部服務發(fā)出的對請求的真實響應，傳送至被測服務。匹配失敗時，所述的樁匹配器僅做為一個中轉(zhuǎn)站，轉(zhuǎn)發(fā)請求并接收外部服務對請求的真實響應，再轉(zhuǎn)發(fā)至被測服務。

在第三實施例中，還包括監(jiān)測模塊80和監(jiān)測執(zhí)行模塊90，考慮到企業(yè)用戶業(yè)務的復雜性，為了滿足用戶各種業(yè)務的需求不同，所述模擬器通過鏈路狀態(tài)的控制來完成監(jiān)測請求的功能，應該理解地是，監(jiān)測請求的同時是結(jié)合業(yè)務的需求，如果業(yè)務不需要匹配直接轉(zhuǎn)發(fā)的時候可以暫停模擬器的鏈路，如果業(yè)務不使用模擬器，可以停止模擬器的鏈路，模擬服務關閉監(jiān)聽端口，被測服務再發(fā)起請求到模擬器，會收到連接失敗的報錯信息。

在第四實施例中，還包括解耦依賴模塊70，被測的A服務原來是依賴外部的B服務，現(xiàn)在在被測的A服務和外部的B服務之間建立一個開放式的集中管理諸多所述模擬器的平臺，而平臺通過接口與不同的外部服務器協(xié)同交互來處理被測服務的業(yè)務。應當理解地是，計算中的耦合偏向于兩者或多者的彼此影響，解耦就是要解除這種影響，增強各自的獨立存在能力，可以無限降低存在的耦合度，但不能根除，否則就失去了彼此的關聯(lián)，失去了存在意義。

服務模擬平臺的作用是服務解耦，可用于研發(fā)或測試人員繞開外部服務單獨測試自己負責的服務。服務解耦場景：1)A服務調(diào)B服務，B服務由于某些原因不可用或不穩(wěn)定，例如登陸頁面調(diào)一個登陸的passport.api，但是passport.api連不上導致無法登陸；2)A服務調(diào)B服務，B服務的數(shù)據(jù)或場景難以構造，例如登陸頁面調(diào)一個登陸的passport.api，passport.api會在某些極端情況下返回一些錯誤碼；3)自動化測試時，A服務調(diào)B服務，由于B服務不可控，數(shù)據(jù)經(jīng)常變動導致測試數(shù)據(jù)經(jīng)常變化。比如：Jetty可以從test case中控制其運行，從而可以使自動化測試不再依賴外部環(huán)境，順利實現(xiàn)自動化測試。

參照圖9，所述初始化模塊10包括：

模擬測試架構單元101，用于根據(jù)被測服務的請求選擇模擬測試架構，且在所選擇的模擬測試架構中，模擬外部服務行為啟動一個或多個不同協(xié)議服務的模擬器；

模擬多種協(xié)議服務單元102，用于接收請求后，獲取請求URL地址上的協(xié)議類型，轉(zhuǎn)交給適配協(xié)議類型的模擬服務的裝置進行處理，以根據(jù)被測服務的當前協(xié)議服務請求選擇模擬器當前協(xié)議鏈路的配置；

服務端口配置單元103，用于根據(jù)被測服務的當前協(xié)議服務請求選擇模擬器當前協(xié)議鏈路的配置，以修改被測服務請求的IP為模擬器的IP，將被測服務的請求指向模擬器啟動的監(jiān)聽鏈路的端口；

樁單元104，用于根據(jù)模擬外部服務行為的意圖，在模擬器的樁匹配器中編輯模擬匹配條件及預設響應為樁，參數(shù)化樁生成樁參數(shù)。

具體地，所述模擬測試架構101是提供模擬測試用例的模擬測試分析工具，它包括模擬測試的測試模塊、管理模塊和統(tǒng)計分析模塊，所述測試模塊用于執(zhí)行不同測試類型的模擬匹配命令時，提供所調(diào)用的模擬測試用例，且所述的模擬測試用例是可反復使用的；所述管理模塊用于管理不同模擬測試類型的模擬測試用例的調(diào)用；所述統(tǒng)計分析模塊用于統(tǒng)計且分析所述模擬測試的結(jié)果。所述模擬測試架構根據(jù)模擬測試預期的不同區(qū)分為不同的測試類型，再模擬不同的測試類型建立的模擬測試架構，所述模擬測試架構包括單元測試架構、集成測試架構、功能測試架構和壓力測試架構，每種所述模擬測試架構是提取每種測試類型的共性部分組成的獨立的體系結(jié)構。

所述模擬多種協(xié)議服務單元102用于接收請求后，獲取請求URL地址上的協(xié)議類型，轉(zhuǎn)交給適配協(xié)議類型的模擬器進行處理，它又包括模擬通用協(xié)議服務和模擬自定義協(xié)議服務。

所述服務端口配置單元103用于根據(jù)不同協(xié)議服務修改被測服務、外部服務和模擬器的端口配置，以便模擬器進入代理服務器的角色。

所述的樁單元104用于模擬測試用例的調(diào)用條件的單元，以代替測試用例的接口，接受或者傳遞測試用例的數(shù)據(jù)，其中，所述測試模塊的調(diào)用條件，即為模擬匹配條件。

外部服務行為可能是一種協(xié)議服務的測試用例，也可能是多種協(xié)議服務的測試用例，而一個被測服務可能同時依賴多個不同的外部服務，預先存儲模擬所述外部服務行為的測試用例于測試管理單元——模擬器，所以模擬器的初始化操作的啟動時，需要啟動一個或多個與外部服務相對應的模擬器。

在模擬器初始化的過程中，模擬器中的樁匹配器用于模擬測試用例的調(diào)用條件的元件，以代替測試用例的接口，接受或者傳遞測試用例的數(shù)據(jù)，其中，所述測試模塊的調(diào)用條件，即為模擬匹配條件。判斷所調(diào)用的測試用例數(shù)據(jù)的意圖，并依據(jù)該測試用例數(shù)據(jù)中的特定數(shù)據(jù)編輯模擬的匹配條件及預設響應生成為樁；進一步地，為了提高匹配的智能化，所述參數(shù)化樁，應該理解的是，外部服務的多變性決定了模擬匹配條件及預設響應的多變，即樁可以是一個常量，也可以是一個變量，這樣，把樁理解為一個樁函數(shù)，模擬的匹配條件為計算式，預設響應為返回值，而參數(shù)化樁就是在函數(shù)定義時候傳入形參，而相對地，解析參數(shù)就是調(diào)用函數(shù)時傳入實參。樁參數(shù)化的過程是：配置樁的參數(shù)的格式，添加樁參數(shù)，完成參數(shù)化，生成樁參數(shù)。樁的參數(shù)化用以適配多種協(xié)議的不同外部服務，故樁函數(shù)可以自動生成，也可自定義，但自動生的樁函數(shù)與自定義的樁函數(shù)其主要差別在于：自定義的樁函數(shù)調(diào)用優(yōu)先級別高于原函數(shù)，原函數(shù)的優(yōu)先級別高于自動生成的樁函數(shù)。舉個例子，假定在代碼中能夠找到某個函數(shù)的原本定義，此時自動生成的樁函數(shù)是無效的，因為原函數(shù)優(yōu)先級別高于自動生成的樁函數(shù)。而自定義樁函數(shù)可以帶來的好處在于：調(diào)用原函數(shù)可能其返回值為一個固定值，不能返回一個期望值，以使得測試不同的代碼分支。而樁函數(shù)的返回值，可由用戶自由控制，因而具備更大的靈活性。故在本實施例中，這個樁函數(shù)的返回值即預設響應，采用beanshell動態(tài)生成。

而本發(fā)明的參數(shù)化樁也是智能匹配功能的一種體現(xiàn)。樁的匹配條件和模擬響應也都隨之參數(shù)化，應該理解地是，如果樁配置的參數(shù)格式是＄{參數(shù)名}，當設置了參數(shù)格式后，樁參數(shù)也必須設置，否則被測服務請求均會匹配不成功，只有重新設置了樁參數(shù)，讓樁參數(shù)替換掉匹配條件和模擬響應的格式化參數(shù)，這時再請求一次，才可以看到應該得到的響應。

在本實施例中，需要說明的是樁包括公共樁和私有樁，它們根據(jù)測試用例數(shù)據(jù)中的特定數(shù)據(jù)的不同而不同，所述公共樁即可在該鏈路里新建并被調(diào)用，也可以是抓取redis的數(shù)據(jù)自動生成，可被與公共樁關聯(lián)于同一個IP下的鏈路調(diào)用，所述私有樁只能在該鏈路里新建，并只為該鏈路私有。這里所說的新建樁包括自定義樁函數(shù)和原函數(shù)。

特別需要說明地是，公共樁還具有錄制規(guī)則，所述公共樁的錄制途徑有兩種：1、從外部服務系統(tǒng)抓取流量進行錄制，場景：平臺與ApiTester(接口測試平臺)和DCT(造數(shù)據(jù)平臺)對接時，因為ApiTester和DCT的測試時,所有正常的接口請求和響應會發(fā)送一個公共的redis做緩存，平臺會定時從redis提取這些數(shù)據(jù)自動生成公共樁；2、當模擬器不匹配請求時，通過樁錄制器(Stub Recorder)錄制模擬器攔截且不匹配直接轉(zhuǎn)發(fā)的請求和響應生成為公共樁。所述公共樁錄制規(guī)則可以由內(nèi)部代碼預先建立默認規(guī)則后自動生成錄制規(guī)則，也可以在頁面人為設置。

所述的模擬匹配具有豐富的匹配規(guī)則，樁的匹配條件邏輯上支持多個樁之間的AND，OR和NOT關系；匹配的操作符支持equals(值相等)，contains(值包含)，regex(值正則表達式匹配)。而所述的預設響應根據(jù)不同的模擬匹配條件，通過beanshell動態(tài)生成。

參照圖10，所述服務端口配置單元103包括：

通用協(xié)議配置子單元1031，用于若被測服務的當前協(xié)議服務為通用協(xié)議服務，則修改DNS配置，把被測服務請求的IP指向模擬器的IP，配置Nginx，利用Nginx的端口映射，把被測服務的請求指向模擬器啟動的監(jiān)聽鏈路的端口；

自定義協(xié)議配置子單元1032，用于若被測服務的當前協(xié)議服務為自定義協(xié)議服務，通過OSP的靜態(tài)路由的IP和端口，把被測服務請求的IP直接指向模擬器的IP和對應OSP鏈路的監(jiān)聽鏈路的端口。

應該理解地是，本實施例中，把協(xié)議服務分為通用協(xié)議服務和自定義協(xié)議服務，具體地，服務模擬平臺針對不同協(xié)議服務有以下幾種模擬的方案：

1)HTTP/Thrift協(xié)議模擬(通用協(xié)議模擬)：

用戶把B服務的IP(通過修改DNS配置)地址指向平臺模擬器，通過平臺內(nèi)置的Nginx把A服務的請求指向模擬器啟動的監(jiān)聽鏈路的端口。

2)OSP協(xié)議模擬(自定義協(xié)議模擬)：

用戶把B服務的IP通過OSP的靜態(tài)路由的IP和端口直接指向模擬器的IP和對應OSP鏈路的監(jiān)聽鏈路的端口。

需要補充說明的是，Nginx是一個開源的反向代理服務器，平臺只是用了Nginx的端口映射功能，用于HTTP協(xié)議或Thrift協(xié)議模擬，平臺內(nèi)置Nginx，用戶無需再使用服務器操作Nginx，只需在頁面上配置。如在Nginx配置頁面配置是：Server Name:cart.api.vip.com listen Port:80默認監(jiān)聽端口:1234，實際會在Nginx生成一個配置文件內(nèi)容如下：

表示cart.api.vip.com域的請求并且端口是80的，統(tǒng)一轉(zhuǎn)發(fā)到監(jiān)聽端口是1234的鏈路。例如請求是http://cart.api.vip.com:80/xxx,通過Nginx轉(zhuǎn)發(fā)后變?yōu)閔ttp://127.0.0.1:1234。

Nginx反向代理的原理是指以代理服務器來接受internet上的連接請求，然后將請求轉(zhuǎn)發(fā)給內(nèi)部網(wǎng)絡上的服務器，并將從服務器上得到的結(jié)果返回給internet上請求連接的客戶端，此時代理服務器對外就表現(xiàn)為一個服務器。

參照圖11，所述報文解析模塊30包括：

解析單元301，用于解析所攔截的請求生成請求參數(shù)；

封裝單元302，用于將請求參數(shù)轉(zhuǎn)換為統(tǒng)一的封裝不同協(xié)議的請求對象；

傳送單元303，用于傳送請求對象至模擬器的樁匹配器。

在本實施例中，所述報文解析模塊實際上完成的是模擬器普通模擬匹配執(zhí)行之前被測服務請求接收的過程，鏈路啟動的時候會啟動一個InboundChannel(InboundChannel專門用于A服務和模擬器間通信的通道)，用于監(jiān)聽收到的來自A服務的請求，收到請求后，通過Request Extrator對請求的參數(shù)進行提取(如uri,body的參數(shù))，轉(zhuǎn)為一個RequestElement請求對象(HTTP，OSP等不同協(xié)議的請求內(nèi)容統(tǒng)一轉(zhuǎn)換為RequestElement請求對象即封裝有不同協(xié)議的請求參數(shù))。模擬器再把RequestElement傳入Stub Matcher(樁匹配器)與用戶預設的樁進行匹配。整個把請求解析為RequestElement的操作均是由模擬器的內(nèi)部代碼實現(xiàn)。

參照圖12，所述執(zhí)行模塊40包括：

接收單元401，用于樁匹配器接收解析后的請求；

調(diào)用單元402，用于調(diào)用樁參數(shù)；

釋放單元403，用于解析樁參數(shù)，以釋放模擬匹配條件和預設響應；

執(zhí)行單元404，用于調(diào)用模擬匹配條件，執(zhí)行匹配命令。

在本實施例中，所述執(zhí)行模塊實際上完成的是模擬器普通模擬匹配執(zhí)行之前的樁參數(shù)化相呼應的解參過程，樁可以是一個常量，也可以是一個變量，這樣，把樁定義為一個函數(shù)，函數(shù)定義時候傳入的參數(shù)叫形參，而調(diào)用函數(shù)時傳入的參數(shù)叫實參，模擬器先替換掉樁里區(qū)配條件和預設響應的參數(shù)，釋放出模擬匹配條件和預設響應的原函數(shù)，然后再調(diào)用模擬匹配條件，執(zhí)行匹配命令。

本發(fā)明還公開了一種模擬服務的集中管理平臺，包括：

一個或多個不同協(xié)議的如上所述的模擬服務的裝置；及

UI交互模塊，用于建立UI交互測試模型及交互規(guī)范，編輯靜態(tài)HTML，以負責所有模擬服務的交互對接；及

日志管理模塊，用于提供日志管理功能，可對模擬測試的結(jié)果進行日志的記錄、查看、下載及清理；及

模擬數(shù)據(jù)庫，用于存儲模擬服務的所有數(shù)據(jù)。

在本發(fā)明中，所述的模擬服務的集中管理平臺完全采用WEB UI的可視化操作界面，配置共享，用戶使用時無需任何技能，也不需了解技術細節(jié)也就是說無需自己編碼，就能實現(xiàn)服務的摸擬，大大地提高了聯(lián)調(diào)測試的效率。

在實際應用中，模擬服務的集中管理平臺就是對上述一個或多個不同協(xié)議服務的所述模擬器進行集中管理的平臺，模擬服務平臺的核心原理是一個代理服務平臺，為進行模擬服務的模擬器構建適配的測試環(huán)境；根據(jù)被測服務的請求類型尋找合適的模擬器及不同協(xié)議的鏈路配置，以提供相對應的服務；對多個模擬器的集中管理，配置共享，提高聯(lián)調(diào)測試工作效率；日志記錄及數(shù)據(jù)庫提供集中管理的常規(guī)服務；呈現(xiàn)解耦依賴情況時，執(zhí)行解耦依賴，以繞開所依賴外部服務的接口，方便測試人員進行自己負責的測試服務。

所述的模擬服務的集中管理平臺使得測試人員的聯(lián)調(diào)測試、開發(fā)聯(lián)調(diào)、異常場景及復雜測試場景的測試更趨簡化，還使得壓測數(shù)據(jù)及環(huán)境的簡化

在實際應用中，本發(fā)明提供的一種模擬服務的方法及裝置的實際操作過程如下：

一、模擬服務的方法

以HTTP協(xié)議模擬為例：

1.模擬器自帶一個Nginx接收請求，Nginx根據(jù)用戶的配置的轉(zhuǎn)發(fā)端口，Nginx收到請求后，把轉(zhuǎn)發(fā)到對應鏈路啟動的監(jiān)聽端口。

2.鏈路啟動的時候會啟動一個InboundChannel(InboundChannel專門用于A服務和模擬器間通信的通道)，用于監(jiān)聽收到的來自A服務的請求。收到請求后，通過Request Extrator對請求的參數(shù)進行提取(如uri,body的參數(shù))，轉(zhuǎn)為一個RequestElement請求對象(HTTP，OSP等不同協(xié)議的請求內(nèi)容統(tǒng)一轉(zhuǎn)換為RequestElement請求對象)。

3.模擬器再把RequestElement傳入Stub Matcher(樁匹配器)與用戶預設的樁進行匹配。

4.匹配失敗就會通過OutboundChannel(OutboundChannel是專門用于模擬器和B服務通信的通道，只在轉(zhuǎn)發(fā)時才建立)轉(zhuǎn)發(fā)到真實服務并接收響應，并且通過Stub Recorder(樁錄制器，專門用于把錄制模擬器攔截且轉(zhuǎn)發(fā)的響應錄制為公共樁)錄制響應，然后把真實響應通過InBoundChannel返回給請求方(A服務)。

5.匹配成功后，會把預設響應通過InBoundChannel直接返回給請求方(A服務)。

所述的模擬器實現(xiàn)模擬服務的普通匹配過程實際操作流程：

1、模擬器的鏈路配置，包括：鏈路ID、鏈路IP、鏈路名稱、鏈路監(jiān)聽端口、是否使用匹配、目標服務目標IP、目標服務Host/URL、目標服務端口及協(xié)議類型，其中，第一個鏈路都會起一個監(jiān)聽端口，目標服務設置用戶匹配失敗后的轉(zhuǎn)發(fā)，支持協(xié)議類型包括：HTTP、DSP、Thrift等；

2、鏈路列表及狀態(tài)控制，鏈路狀態(tài)包括：啟動、暫停(只轉(zhuǎn)發(fā)不匹配使用)和停止；

3、Nginx配置，用于HTTP協(xié)議或Thrift協(xié)議模擬，平臺內(nèi)置Nginx，用戶無需再在服務器上操作Nginx，只需在頁面上配置；

4、JAR包管理，用于RPC協(xié)議模擬，統(tǒng)一管理客戶端的JAR包，便于解析不同協(xié)議服務。

5、樁配置，指定模擬匹配規(guī)則、預設響應、樁參數(shù)等設置，每個鏈路可設置多個樁；

6、公共樁錄制規(guī)則設置，公共樁的錄制途徑有兩種：1、從外部服務系統(tǒng)抓取流量進行錄制；2、當模擬器不匹配請求時，通過樁錄制器(Stub Recorder)錄制模擬器攔截且不匹配直接轉(zhuǎn)發(fā)的請求和響應生成為公共樁。所述公共樁錄制規(guī)則可以手工設置，如果有不存在的條件，還可以自動生成錄制規(guī)則；

7、日志記錄，模擬匹配失敗時記錄轉(zhuǎn)發(fā)的日志，模擬匹配成功時記錄反回預設響應的日志；

8、單獨啟動的服務壓測包進行壓力測試，支持HTTP和DSP協(xié)議的壓測時服務模擬，一鍵下載壓測包，啟動壓測模擬器，壓測模擬器自身進行壓力測試，查看測試結(jié)果。

二、模擬服務的集中管理平臺

所述的模擬服務的集中管理平臺就是對所述模擬器進行集中管理的平臺，模擬服務平臺的核心原理是一個代理服務平臺，所述平臺的工作內(nèi)容包括為進行模擬服務的模擬器構建適配的測試環(huán)境；根據(jù)被測服務的請求類型尋找合適的模擬器及鏈路配置，以提供相對應的服務；對多個模擬器的集中管理，配置共享，提高聯(lián)調(diào)測試工作效率；日志記錄及存儲模擬服務的數(shù)據(jù)等等，平臺的操作步驟：

步驟一，建立UI交互測試模型，以使用戶所有的操作基本都是從平臺的WEB界面進行，無需編碼；

步驟二，利用測試模型，生成測試框架，包括：單元測試框架、集成測試框架、功能測試框架及壓力測試框架；

步驟三，呈現(xiàn)解耦依賴的情況時執(zhí)行解耦依賴，以繞開所依賴外部服務的接口；

步驟四，編寫測試事件，通過模擬外部服務的測試用例或注冊自定義服務事件的API函數(shù)，將已編寫好的腳本編輯到測試框架中相應的模擬器中；

步驟五，在模擬器中，實施模擬測試匹配，返回相對應的響應；

步驟六，日志記錄，可進行日志的記錄、查看、下載及清理，若匹配成功，返回預設響應的日志；若匹配失敗，返回轉(zhuǎn)發(fā)的日志；

步驟七，模擬數(shù)據(jù)庫收集測試數(shù)據(jù)，存儲并管理，

所述測試框架是提供模擬測試用例的模擬測試分析工具，它包括模擬測試的基礎模塊、管理模塊和統(tǒng)計分析模塊，所述基礎模塊用于執(zhí)行不同測試類型的模擬匹配命令時，提供所調(diào)用的模擬測試用例，且所述的模擬測試用例是可重用的；所述管理模塊用于管理不同模擬測試類型的模擬測試用例的調(diào)用；所述統(tǒng)計分析模塊用于統(tǒng)計且分析所述模擬測試的結(jié)果。所述測試架構根據(jù)模擬測試預期的不同區(qū)分為不同的測試類型，再模擬不同的測試類型建立的模擬測試架構，所述模擬測試架構包括單元測試架構、集成測試架構、功能測試架構和壓力測試架構，每種所述模擬測試架構是提取每種測試類型的共性部分組成的獨立的體系結(jié)構。適用場景：

1)功能測試、集成測試和單元測試

測試或研發(fā)人員在做功能測試、集成測試、單元測試甚至功能開發(fā)的時候，通過把自身服務對接到平臺模擬器，可以簡單的繞開外部不穩(wěn)定、不可用、復雜的外部服務服務繞開掉并可以模擬外部服務的任意返回。用戶只需要關注自身服務的功能和邏輯從而實現(xiàn)對外部服務的解耦依賴。

2)性能測試

測試人員做壓測的時候，把平臺提供的壓測包下載到壓測機上并啟動。壓測包是可獨立啟動的高性能模擬服務，和平臺本身通過接口對接并在啟動時獲取樁和鏈路相關數(shù)據(jù)。用戶壓測的時候無需部署外部依賴服務和造大批量外部壓測數(shù)據(jù)，只要簡單的把外部依賴改為連接模擬器并關注被測服務本身的性能和壓測數(shù)據(jù)。所述平臺提供的壓測包，支持通用協(xié)議和自定義協(xié)議的壓測時服務模擬，而且壓測包也是使用Web界面指定鏈路的樁設置，無需重復配置。步驟為：首先一鍵下載平臺提供的壓測包，啟動壓測模擬器，進行壓力模擬測試，通過界面直接查看測試結(jié)果。

需要說明的是，在本文中，術語“包括”、“包含”或者其任何其它變體意在涵蓋非排他性的包含，從而使得包括一系列要素的過程、方法、物品或者裝置不僅包括那些要素，而且還包括沒有明確列出的其它要素，或者是還包括為這種過程、方法、物品或者裝置所固有的要素。在沒有更多限制的情況下，由語句“包括一個……”限定的要素，并不排除在包括該要素的過程、方法、物品或者裝置中還存在另外的相同要素。上述本發(fā)明實施例序號僅僅為了描述，不代表實施例的優(yōu)劣。通過以上的實施方式的描述，本領域的技術人員可以清楚地了解到上述實施例方法可借助軟件加必需的通用硬件系統(tǒng)的方式來實現(xiàn)，當然也可以通過硬件，但很多情況下前者是更佳的實施方式。基于這樣的理解，本發(fā)明的技術配置本質(zhì)上或者說對現(xiàn)有技術做出貢獻的部分可以以軟件產(chǎn)品的形式體現(xiàn)出來，該計算機軟件產(chǎn)品存儲在一個存儲介質(zhì)(如ROM/RAM、磁碟、光盤)中，包括若干指令用以使得一臺終端設備(可以是手機，計算機，服務器或者網(wǎng)絡設備等電子設備)執(zhí)行本發(fā)明各個實施例所述的方法。

以上僅為本發(fā)明的優(yōu)選實施例，并非因此限制本發(fā)明的專利范圍，凡是在本發(fā)明的發(fā)明構思下，利用本發(fā)明說明書及附圖內(nèi)容所作的等效結(jié)構變換，或直接/間接運用在其他相關的技術領域均包括在本發(fā)明的專利保護范圍內(nèi)。