本發(fā)明涉及計算機技術領域，尤其涉及一種基于可編程式測試服務的創(chuàng)建方法及裝置。

背景技術：

隨著信息技術的發(fā)展，網絡服務商后臺的服務系統(tǒng)可以為用戶提供各類豐富的業(yè)務服務。業(yè)務服務的順利實現，通常依賴于服務系統(tǒng)內部的各功能單元之間的交互、以及服務系統(tǒng)與外部系統(tǒng)的交互。

目前，在對業(yè)務服務進行開發(fā)測試的過程中，為了保證業(yè)務服務在實際應用時能夠正常運行，需要對業(yè)務服務進行運行模擬測試，也即，針對業(yè)務服務進行mock。其中，mock是指在針對某一待測對象A，構造虛擬的運行環(huán)境，模仿待測對象A在實際運行場景中的運行邏輯，包括：待測對象A在實際應用時與服務系統(tǒng)內部各功能單元之間的調用及交互、以及與外部系統(tǒng)之間的調用及交互等。

現有技術中，當開發(fā)者要對待測業(yè)務服務進行mock時，通常會將待測業(yè)務服務的業(yè)務代碼部署至具有mock功能的服務器中，針對部署至服務器中的業(yè)務代碼，開發(fā)者可以根據實際需要，進行不同運行場景下的mock，其具體方式為：開發(fā)者將所需的運行場景和運行參數，以mock代碼的方式部署至服務器中，并與待測業(yè)務服務的業(yè)務代碼進行耦合，從而，服務器則會將mock代碼轉換形成mock服務(該mock服務只針對該待測業(yè)務服務)，用以實現在相應運行場景下對該業(yè)務服務進行模擬測試。

但是，在實際應用中，很多特定的業(yè)務服務需要多種類型的測試結果，由于mock代碼與待測業(yè)務服務的業(yè)務代碼耦合在一起，只能進行固定類型的測 試，若開發(fā)者想要獲得不同類型的測試結果，只能重新編寫mock代碼，并重復上述的耦合過程。另外，上述方式中mock服務只針對與其匹配的待測試業(yè)務服務，而很多業(yè)務服務之間相互關聯，其運行場景相同，采用上述方式進行mock時，其他待測業(yè)務服務不能使用該mock服務。顯然，在大量開發(fā)測試的情況下，上述mock方式將嚴重影響模擬測試的效率。

技術實現要素：

本發(fā)明實施例提供一種基于可編程式測試服務的創(chuàng)建方法及裝置，用以解決傳統(tǒng)的mock服務進行模擬測試時的效率較低的問題。

本發(fā)明實施例提供的一種基于可編程式測試服務的創(chuàng)建方法，包括：

測試平臺接收測試環(huán)境信息對應的代碼；

對所述代碼進行編譯；

根據編譯后的代碼，確定所述測試環(huán)境信息對應的服務類型；

根據預設的與所述服務類型對應的發(fā)布方式，發(fā)布所述編譯后的代碼，用以對不同類型的測試請求進行處理。

本發(fā)明實施例另提供的一種基于可編程式測試服務的創(chuàng)建方法，包括：

測試平臺接收測試請求；

確定所述測試請求對應的測試環(huán)境信息；

根據所述測試環(huán)境信息，在已發(fā)布的所有代碼中，查找與所述測試請求對應的所述測試環(huán)境信息相同的代碼；

調用查找到的所述代碼對所述測試請求進行處理。

本發(fā)明實施例另提供的一種基于可編程式測試服務的創(chuàng)建裝置，包括：

接收模塊，用于接收測試環(huán)境信息對應的代碼；

編譯模塊，用于對所述代碼進行編譯；

確定模塊，用于根據編譯后的代碼，確定所述測試環(huán)境信息對應的服務類型；

發(fā)布模塊，用于根據預設的與所述服務類型對應的發(fā)布方式，發(fā)布所述編譯后的代碼，用以對不同類型的測試請求進行處理。

本發(fā)明實施例另提供的一種基于可編程式測試服務的創(chuàng)建裝置，包括：

接收模塊，用于接收測試請求；

確定模塊，用于確定所述測試請求對應的測試環(huán)境信息；

查找模塊，用于根據所述測試環(huán)境信息，在已發(fā)布的所有代碼中，查找與所述測試請求對應的所述測試環(huán)境信息相同的代碼；

處理模塊，用于對所述測試請求進行處理。

本發(fā)明實施例提供一種基于可編程式測試服務的創(chuàng)建方法及裝置，測試平臺接收測試環(huán)境信息對應的代碼，在對該代碼進行編譯后，確定出測試環(huán)境信息對應的服務類型，并按照不同的發(fā)布方法，將編譯后的代碼發(fā)布在測試平臺中。這樣的方式，不同于現有技術中測試代碼與業(yè)務代碼綁定耦合的方式，開發(fā)者通過測試平臺，不僅可以查找已經發(fā)布且適用的代碼進行模擬測試，而且可以根據已經發(fā)布的代碼所對應的測試環(huán)境信息，對測試場景相同的其他業(yè)務服務進行測試，從而改變了現有技術中相同運行場景的不同業(yè)務服務，不能使用同一測試代碼的缺陷，有效提升了大量開發(fā)測試情況下，模擬測試的效率。

附圖說明

此處所說明的附圖用來提供對本發(fā)明的進一步理解，構成本發(fā)明的一部分，本發(fā)明的示意性實施例及其說明用于解釋本發(fā)明，并不構成對本發(fā)明的不當限定。在附圖中：

圖1為本發(fā)明實施例提供的接收的基于可編程式測試服務的創(chuàng)建過程示意圖；

圖2為本發(fā)明實施例提供的測試平臺的平臺界面的示意圖；

圖3為本發(fā)明實施例提供的對mock請求處理的過程示意圖；

圖4為本發(fā)明實施例提供的基于可編程式測試服務的創(chuàng)建裝置結構示意 圖。

圖5為本發(fā)明實施例提供的基于可編程式測試服務的創(chuàng)建裝置結構示意圖。

具體實施方式

為使本發(fā)明的目的、技術方案和優(yōu)點更加清楚，下面將結合本發(fā)明具體實施例及相應的附圖對本發(fā)明技術方案進行清楚、完整地描述。顯然，所描述的實施例僅是本發(fā)明一部分實施例，而不是全部的實施例?；诒景l(fā)明中的實施例，本領域普通技術人員在沒有做出創(chuàng)造性勞動前提下所獲得的所有其他實施例，都屬于本發(fā)明保護的范圍。

圖1為本發(fā)明實施例提供的基于可編程式測試服務的創(chuàng)建過程，該過程具體包括以下步驟：

S101，測試平臺接收測試環(huán)境信息對應的代碼。

在本申請實施例中，所述的測試平臺可以由具有模擬測試功能的服務器或者服務器集群構成。需要說明的是，本申請中采用測試平臺的方式，使得接收到的代碼公開化，也即，對于任一開發(fā)者，均可以在該測試平臺上調用其他開發(fā)者上傳的代碼。

在上述步驟S101中，所述的測試環(huán)境信息，就是待測業(yè)務服務進行模擬測試時所需的信息，該測試環(huán)境信息中定義了進行模擬測試時待測業(yè)務服務的運行場景、與服務系統(tǒng)內的各功能單元進行交互的接口、交互的數據值、返回值等信息。

本申請實施例中的所述的代碼具體可以編寫在mock腳本中，也即，對于上述步驟S101而言，接收測試環(huán)境信息對應的代碼，具體為：接收mock腳本，其中，所述mock腳本中包含以代碼方式編寫的測試環(huán)境信息。

S102，對所述代碼進行編譯。

在本申請實施例中，服務器對測試環(huán)境信息對應的代碼進行編譯，就是服 務器讀取該代碼中包含的內容的過程。也即，通過對所述代碼進行編譯，使得服務器可以獲知該測試環(huán)境信息的具體內容，以便后續(xù)進行模擬測試。

其中，所述編譯的方式包括但不限于：靜態(tài)編譯或動態(tài)編譯。其中，靜態(tài)編譯是指針對代碼中涉及的類和方法，無論當時是否使用，均全部進行加載；動態(tài)編譯是指針對代碼中涉及的類和方法，只在需要使用時才進行加載。兩種加載方式均可以用于本申請中對所述代碼的編譯過程，這里并不構成對本申請的限定。

S103，根據編譯后的代碼，確定所述測試環(huán)境信息對應的服務類型。

在實際應用中，不同的業(yè)務服務通常對應不同的服務類型，例如：網站提供網頁顯示的業(yè)務服務，那么，該業(yè)務服務對應的類型就是超文本傳輸協議(Hypertext transfer protocol，Http)服務。又例如：服務器系統(tǒng)向氣象臺獲取天氣信息的業(yè)務服務，其對應的類型是傳輸控制協議(Transmission Control Protocol，TCP)服務(即通過特定TCP接口，接收氣象臺傳輸的天氣信息)。

可見，不同的業(yè)務服務對應不同的服務類型，那么，對于業(yè)務服務的開發(fā)測試而言，也將基于相同的服務類型。因此，對于任一待測業(yè)務服務來說，其對應的服務類型，就是其測試環(huán)境代碼所對應的服務類型。故服務器可以根據編譯后的代碼，確定出不同的測試環(huán)境信息對應的服務類型。

這里需要說明的是，本申請實施例中，測試環(huán)境信息對應的服務類型，包括但不限于：Http服務、TCP服務、webservice服務、tair服務等。

S104，根據預設的與所述服務類型對應的發(fā)布方式，發(fā)布所述編譯后的代碼，用以對不同類型的測試請求進行處理。

不同的服務類型，所涉及到的交互方式、后臺所需調用的功能均不相同，為了能夠使得不同服務類型的代碼順利運行，所以在服務器針對代碼進行編譯后，便會根據測試環(huán)境信息對應的服務類型，按照不同的方式發(fā)布所述代碼。

需要說明的是，在本申請實施例中，發(fā)布后的代碼將作為所述測試平臺的一項測試服務，并在全平臺可見，也就是說，訪問該平臺的開發(fā)者，可以瀏覽、 查閱并使用已經發(fā)布的所述代碼，這樣的方式改變了傳統(tǒng)進行mock時“私有化”的方式，也即，測試代碼不再與待測業(yè)務服務的業(yè)務代碼相耦合，而轉變成一種全平臺通用的測試服務。

通過上述方法，測試平臺接收測試環(huán)境信息對應的代碼，在對該代碼進行編譯后，確定出測試環(huán)境信息對應的服務類型，并按照不同的發(fā)布方法，將編譯后的代碼發(fā)布在測試平臺中。這樣的方式，不同于現有技術中測試代碼與業(yè)務代碼綁定耦合的方式，開發(fā)者通過測試平臺，不僅可以查找已經發(fā)布且適用的代碼進行模擬測試，而且可以根據已經發(fā)布的代碼所對應的測試環(huán)境信息，對測試場景相同的其他業(yè)務服務進行測試，從而改變了現有技術中相同運行場景的不同業(yè)務服務，不能使用同一測試代碼的缺陷，有效提升了大量開發(fā)測試情況下，模擬測試的效率。

在實際應用場景下，代碼的實現基于類，其中，類是用于定義特定類型的對象而使用的方法和變量的模板。也就是說，代碼中所使用的邏輯方法以及變量的賦值，是由類進行定義的，故測試平臺要執(zhí)行該代碼時，就需要獲知該代碼的邏輯方法以及變量的賦值，也即，測試平臺需要加載該代碼中的類。而在本申請實施例中，代碼攜帶在mock腳本中，因此，在本申請實施例中，對所述代碼進行編譯，具體為：加載所述mock腳本中代碼所包含的類，以對所述代碼進行編譯。

在本申請實施例中，對mock腳本中代碼的類進行加載，往往是通過類加載器實現的，例如：通過Java虛擬機(Java Virtual Machine，JVM)對類進行加載(也即，從相應的類庫中加載代碼中類所對應的類文件)。在某些情況下，用戶所編寫的代碼中所使用的類均是默認類，其中，所述默認類是默認類庫中默認存儲的類文件所對應的類，也即，服務器可以直接使用默認類加載器對代碼中的類進行加載(加載默認類庫中的類文件)，而在實際應用中，用戶所編寫的代碼中使用到的類并非是默認類(也即，代碼中包含的類所對應的類文件并非是默認類庫中的類文件，而是第三方的類文件)，這樣一來，服務器便不 能使用默認類加載器來加載這些類。所以在本申請實施例中，加載所述mock腳本中包含的代碼所對應的類，具體為：確定所述代碼中包含的類所屬的類型，若所述類屬于默認類，則調用默認類加載器加載所述類，若所述類不屬于默認類，則調用自定義類加載器加載所述類。

需要說明的是，在本申請實施例中，測試平臺確定所述代碼中包含的類所屬的類型，其方式具體可以是通過確定代碼中類的類名以及代碼中所使用的邏輯方法的結合，來確定所述代碼中的類所屬的類型。這里并不構成對本申請的限定。

在本申請實施例中，使用默認類加載器和自定義類加載器對類進行加載的過程并不相同，下面對兩類過程進行說明，具體而言：

在服務器調用默認類加載器的情況下，就表明mock腳本中代碼包含的類是默認類，但是考慮到實際應用場景下，開發(fā)者用戶在編寫所述代碼時，使用的類名可能會根據用戶的喜好自行定義(類中定義的方法和變量仍與默認類相同，并未發(fā)生變化)，在這樣的情況下，由于類名發(fā)生了變化的類，使得默認類加載器不能準確地從默認類庫中加載該類對應的類文件，即類加載器并不能有效地對該代碼中的類進行加載，因此在本申請實施例中，調用類加載器加載所述類，具體為：確定所述代碼中包含的類對應的類名，判斷所述類名是否為默認類的類名，若是，則調用所述默認類加載器直接加載所述類，否則，則將所述類名重命名為默認類名，再調用默認類加載器加載所述類。也即，默認類加載器會對代碼中類的類名重命名為默認類名，從而，使得默認類加載器可以順利對mock腳本中代碼的類進行加載。

也就是說，若代碼中默認類的類名沒有發(fā)生變化，那么，測試平臺可以直接針對該代碼中包含的類，在默認類庫中加載該類對應的類文件。而若代碼中默認類的類名發(fā)生了變化，那么，測試平臺會將該類的類名重命名為默認類的類名，從而便可以在默認類庫中找到該類對應的類文件，并進行加載。

在服務器調用自定義類加載器的情況下，就表明代碼中使用的類并非默認 類。這就需要服務器在加載這些非默認類時，通過相應的路徑查找到非默認類對應的類文件(此時，服務器并不能在默認類庫中查找到類文件)。

另外，考慮到在實際應用中，服務器可能接收到多個不同的mock腳本，這些mock腳本中的代碼均可能使用了非默認類，這樣一來，服務器就會針對每一mock腳本，分別調用各自的自定義類加載器，通過查找不同的路徑來加載這些mock腳本中代碼的非默認類，為了不發(fā)生調用混亂的現象，故服務器會采用標記的方式，也即，在本申請實施例中，調用自定義類加載器加載所述類，具體為：確定所述類文件的存儲路徑，調用自定義類加載器，并為該自定義類加載器設置身份標識，建立所述身份標識與所述存儲路徑的對應關系，通過所述自定義類加載器，加載與該自定義加載器的身份標識對應的存儲路徑所指向的類文件。

這里需要說明的是，存儲路徑所指向的可能是類文件，也可能是存儲類文件的文件目錄。若存儲路徑所指向的是類文件，則自定義類加載器從該類文件中查找非默認類。而若存儲路徑所指向的文件目錄，則自定義類加載器在該文件目錄中查找類文件，查找到了類文件之后，在該類文件中查找非默認類。成功查找到非默認類，那么，便可以對非默認類進行加載，但是如果未查找到非默認類，那么，服務器會返回異常提示信息，以告知開發(fā)者用戶未能成功查找到非默認類，以使得開發(fā)者用戶重新調整存儲路徑或重新上傳正確的類文件。

在實際應用中，當開發(fā)者用戶在其編寫的代碼中使用了非默認類時，通常開發(fā)者用戶會將該非默認類所需的類文件上傳至所述測試平臺中，以便測試平臺在對該mock腳本中的代碼進行編譯時使用。其中，開發(fā)者用戶所上傳的類文件的文件格式可以為jar、zip等，這里并不作出具體限定。當然，在實際應用中，自定義類加載器，也可以由開發(fā)者上傳至測試平臺中，從而，當測試平臺對該開發(fā)者的代碼中的非默認類進行加載時，就會調用該開發(fā)者上傳的自定義類加載器，用以加載該開發(fā)者上傳的非默認類文件。上述方式只是對本申請實施例中的示例，在實際應用中并不局限在上述方式中，例如：在實際應用中， 自定義類加載器可以由測試平臺提供，測試平臺提供的自定義類加載器可適用于加載各種類型的類文件。這里并不構成對本申請的限定。

測試平臺通過上述方式實現對類的加載，這樣便可以順利地完成對mock腳本中代碼的編譯。當測試平臺成功編譯了代碼后，就會將編譯后的代碼發(fā)布在整個測試平臺中，這樣一來，該代碼就會對所有訪問該測試平臺的不同開發(fā)者可見，開發(fā)者可根據使用需要，調用該代碼進行相應的模擬測試。

這里需要說明的是，在實際應用中，不同的測試環(huán)境信息定義了不同的服務類型，測試平臺根據編譯后的代碼，就可以確定出該代碼對應的測試環(huán)境信息所屬的服務類型。在本申請實施例中，測試環(huán)境信息對應的服務類型如上所述，也即，至少包括：Http服務、TCP服務、webservice服務、tair服務。而對于不同的服務類型來說，在測試過程中，所要調用的服務、測試環(huán)境的運行邏輯等均不相同，所以，為了保證不同服務類型的代碼在模擬測試時可以正常有效地運行，測試平臺就需要針對不同服務類型的代碼，以不同的方式進行發(fā)布。

具體而言，在本申請實施例中，根據預設的與所述服務類型對應的發(fā)布方式，發(fā)布所述代碼，具體為：當所述服務類型為Http服務時，將所述mock腳本中的對象保存在所述服務器的內存中發(fā)布所述mock腳本，當所述服務類型為TCP服務時，通過mina服務框架發(fā)布所述mock腳本，當所述服務類型為webservice服務和tair服務時，通過xfire發(fā)布所述mock腳本。

需要說明的是，當所述測試環(huán)境信息對應的服務類型為Http服務時，就表明模擬測試時的運行環(huán)境是基本的網絡服務，那么，測試平臺會將代碼的類所包含的對象(如：各類網絡參數)存放在服務器的內存中，以實現對代碼的發(fā)布。在進行Http服務的模擬測試時，測試平臺就可從內存中調用存儲的測試所需的網絡參數，完成測試。

當所述測試環(huán)境信息對應的服務類型為TCP服務時，就表明模擬測試時的運行環(huán)境需要模擬與外部系統(tǒng)通過TCP連接進行交互的過程，此時，服務 器會使用mina框架(mina框架一種網絡通信應用框架，主要針對TCP/IP、UDP/IP協議棧的通信框架)發(fā)布所述mock腳本，以實現基于TCP連接進行通信交互場景的模擬。通過mina框架，測試平臺可在TCP服務的模擬測試時，實現對連接建立的監(jiān)聽、監(jiān)測傳輸通道上是否有數據的讀寫、發(fā)送數據時的編碼過程、接收數據時的解碼過程、對指定數據的攔截(如：黑名單攔截)等運行場景。可見，本申請實施例中使用mina框架對TCP服務進行模擬測試，可以模擬豐富的運行場景，不僅為不同的開發(fā)者提供了多種運行場景的選擇，而且通過多種運行場景的組合，其模擬測試更接近實際應用。

當所述測試環(huán)境信息對應的服務類型為webservice或tair服務時，就表明mock服務是一種網站服務或者是一種數據存儲服務，這兩類服務均模擬的是服務端，此時，服務器會使用web服務(如：Xfire，web服務引擎)發(fā)布所述mock腳本，以實現對服務端的模擬。

通過上述內容可以看出，本申請實施例中構建了一種可編程式的測試平臺(也即，mock平臺)，這樣的測試平臺與現有技術不同的是，開發(fā)者可以自己編寫所需的各種測試環(huán)境信息(以模擬不同運行場景)，形成mock腳本發(fā)送至該測試平臺上，該測試平臺會根據不同服務類型的mock腳本，采用不同的方式進行發(fā)布，使得mock腳本對全平臺可見，發(fā)布后的mock腳本不僅能夠對當前的待測業(yè)務服務進行模擬測試，其他開發(fā)者還可在該測試平臺上調用該mock腳本，以對其他待測業(yè)務進行模擬測試。

下面以一應用實例對所述測試平臺進行說明：

如圖2所示，是本申請實施例中測試平臺提供的平臺界面，對于任一訪問該測試平臺的開發(fā)者，均可以使用該平臺界面。圖2中的所述平臺界面，顯示了每一個在該測試平臺上發(fā)布的代碼，使得不同的開發(fā)者可以通過該平臺界面，直觀地瀏覽到該開發(fā)者自己所發(fā)布的，以及其他開發(fā)者所發(fā)布的代碼，并且對于每一開發(fā)者，均可以通過該平臺界面，使用任一已發(fā)布的代碼。

其中，在圖2中的區(qū)域A1中顯示的是在該測試平臺上已經發(fā)布的不同的 代碼的標識，具體包括：代碼的編號和名稱。

區(qū)域A2中顯示的是每一代碼所屬的服務類型，所述平臺界面中包括4種服務類型，分別為：http(也即Http服務)、tcp(也即TCP服務)、ws(也即webservice服務)以及tr(也即tair服務)。

區(qū)域A3中顯示的是每一代碼對應的地址，具體而言，對于http而言，其代碼的地址為統(tǒng)一資源定位符(Uniform Resource Locator，URL)。對于ws和tr，其代碼的地址都是服務器域名。對于tcp而言，其代碼的地址為端口號。

并且在圖2中的平臺界面中，還提供了操作選項(圖2中右側名為“操作”的列)，開發(fā)者可以通過操作選項對自己所發(fā)布的代碼進行編輯，且其他開發(fā)者可以通過該操作選項，使用相應的代碼進行模擬測試。當然，實際應用中可能出現不同開發(fā)者對代碼編輯的混亂現象，故在本申請實施例中，可以采用校驗開發(fā)者身份的方式，防止上述現象的發(fā)生，也即，各開發(fā)者均使用身份信息登錄至該平臺中，并且，每一開發(fā)者只能編輯自己所發(fā)布的代碼，而不能編輯其他開發(fā)者發(fā)布的代碼。這里并不構成對本申請的限定。

從上例可見，與現有技術不同的是，現有技術中的mock平臺所提供的mock服務深度嵌入在待測業(yè)務服務的業(yè)務代碼中，開發(fā)者只能使用該mock服務對該待測業(yè)務服務進行測試，而在本申請實施例中，正是通過本申請實施例中測試平臺的方式，使得用戶可以隨意地構建自身所需的各類mock服務，并且mock服務并非與待測業(yè)務服務深度耦合，其他開發(fā)者也可以使用該開發(fā)者的代碼，對其他的業(yè)務服務進行模擬測試，有效提升了該測試平臺中mock服務的可用性，并且，用戶還可以選擇從測試平臺中，將所屬該用戶且已發(fā)布的代碼撤銷，即可拔插的方式，使得該測試平臺的靈活性極大增強。

以上為本申請實施例中，建立可編程式測試平臺的過程。在可編程式測試平臺建立之后，便可以對不同的測試請求進行處理，具體地，基于可編程式測試平臺的數據處理過程如圖3所示，該過程具體如下：

S301，測試平臺接收測試請求。

在本申請實施例中，在所述測試平臺由服務器集群構成的情況下，可由該服務器集群中的任一臺服務器接收測試請求。當然，本申請實施例中，服務器集群中可根據各臺服務器的負載狀態(tài)，來指定相應的服務器來接收該測試請求，進行模擬測試。這里并不構成對本申請的限定。

這里需要說明的是，本申請實施例中所述的測試請求，就是待測對象的測試請求。在本申請實施例中，所述的待測對象就是待測業(yè)務服務。

S302，確定所述測試請求對應的測試環(huán)境信息。

不同的待測業(yè)務服務，在進行模擬測試時，需要確定該待測業(yè)務服務的測試環(huán)境信息。在本申請中，待測業(yè)務服務所需的測試環(huán)境信息，是攜帶在測試請求中的，從而，測試平臺接收到測試請求之后，就可以確定出該測試請求對應的測試環(huán)境信息。

S303，根據所述測試環(huán)境信息，在已發(fā)布的所有代碼中，查找與所述測試請求對應的所述測試環(huán)境信息相同的代碼。

在如圖1所述的可編程式測試服務的創(chuàng)建方法中，不同開發(fā)者將其編寫的測試環(huán)境信息對應的代碼發(fā)布在所述測試平臺中，從而，當測試平臺接收到所述測試請求后，就會在已經發(fā)布的各代碼中，確定出與當前待測業(yè)務服務的測試請求相匹配的代碼，用來對該待測業(yè)務服務進行測試。

S304，調用查找到的所述代碼對所述測試請求進行處理。

在查找到相應的代碼后，測試平臺就會調用該代碼，對測試請求進行處理。

通過上述步驟，在本申請實施例中的測試平臺上，當接收到的測試請求后，測試平臺會根據該測試請求對應的測試環(huán)境信息，在該測試平臺已經發(fā)布的所有代碼中，查找出與該測試環(huán)境信息相匹配的代碼，用來對所述測試對象進行模擬測試，正是由于測試平臺的共用性，使得不同的測試對象均可以通過調用測試平臺中已有的代碼進行模擬測試，有效地提升了對待測對象進行模擬測試時的效率，同樣，對于特定待測對象，想要進行多種類型的模擬測試，也可以從所述測試平臺中查找適用的代碼進行不同類型的模擬測試，不僅提升了開發(fā) 測試的效率，也提升了測試過程中的便捷性。

需要說明的是，在本申請實施例中，所述測試請求中攜帶有待測對象的默認的服務類型和/或運行環(huán)境。例如：假設某一天氣業(yè)務服務是待測對象，其自身默認的服務類型為http服務，運行環(huán)境默認為成功接收到氣象臺的天氣信息。而在實際應用中，為了測試該天氣業(yè)務服務在實際運行過程中，遇到服務錯誤時的處理方案，所以，開發(fā)者可能會指定運行環(huán)境為接收天氣信息失敗。這樣一來，用戶所指定的運行環(huán)境就與該天氣業(yè)務服務自身的運行環(huán)境發(fā)生了變化。

那么，上述步驟S302中，確定所述測試請求對應的測試環(huán)境信息，具體為：當所述測試請求中包含用戶指定的服務類型和/或運行場景時，將用戶指定的所述服務類型和/或運行場景，確定為所述測試請求對應的測試環(huán)境信息；當所述測試請求中不包含用戶指定的服務類型和/或運行場景時，將所述待測對象對應的默認的服務類型和/或運行環(huán)境，確定為所述測試請求對應的測試環(huán)境信息。

以上為本發(fā)明實施例提供的基于可編程式測試服務的創(chuàng)建方法，基于同樣的思路，本發(fā)明實施例還提供一種基于可編程式測試服務的創(chuàng)建裝置。

如圖4所示，基于可編程式測試服務的創(chuàng)建裝置包括：接收模塊401、編譯模塊402、確定模塊403以及發(fā)布模塊404，其中，

所述接收模塊401，用于接收測試環(huán)境信息對應的代碼。

所述編譯模塊402，用于對所述代碼進行編譯。

所述確定模塊403，用于根據編譯后的代碼，確定所述測試環(huán)境信息對應的服務類型。

所述發(fā)布模塊404，用于根據預設的與所述服務類型對應的發(fā)布方式，發(fā)布所述編譯后的代碼，用以對不同類型的測試請求進行處理。

在本申請實施例中，所述服務類型包括但不限于：超文本傳輸協議Http服務、傳輸控制協議TCP服務、webservice服務、tair服務等。

所述編譯模塊402，具體用于接收mock腳本。其中，所述mock腳本中包含以代碼方式編寫的測試環(huán)境信息。

所述發(fā)布模塊404，具體用于當所述服務類型為Http服務時，將所述mock腳本中代碼包含的對象保存在所述服務器的內存中發(fā)布所述mock腳本；當所述服務類型為TCP服務時，通過mina框架發(fā)布所述mock腳本；當所述服務類型為webservice服務或tair服務時，通過web服務發(fā)布所述mock腳本。

所述編譯模塊402，具體用于確定所述mock腳本中包含的類所屬的類型，若所述類屬于默認類，則調用默認類加載器加載所述類，若所述類不屬于默認類，則調用自定義類加載器加載所述類。

更為具體地，所述編譯模塊402，具體用于確定所述mock腳本中包含的類對應的類名，判斷所述類名是否為默認類的類名，若是，則調用所述默認類加載器直接加載所述類，否則，則將所述類名重命名為默認類名，再調用默認類加載器加載所述類。

以及，所述編譯模塊402，具體用于確定所述類文件的存儲路徑，調用自定義類加載器，并為該自定義類加載器設置身份標識，建立所述身份標識與所述存儲路徑的對應關系，通過所述自定義類加載器，加載與該自定義加載器的身份標識對應的存儲路徑所指向的類文件。

通過上述如圖4所示的裝置，可以構建相應的測試平臺，從而，不同的開發(fā)者用戶可以通過所述測試平臺，對不同的待測對象(待測業(yè)務服務)進行模擬測試。相應地，在本申請實施例中，還提供一種基于可編程式測試服務的創(chuàng)建裝置，如圖5所示。所述裝置包括：

接收模塊501，用于接收測試請求。

確定模塊502，用于確定所述測試請求對應的測試環(huán)境信息。

查找模塊503，用于根據所述測試環(huán)境信息，在已發(fā)布的所有代碼中，查找與所述測試請求對應的所述測試環(huán)境信息相同的代碼。

處理模塊504，用于對所述測試請求進行處理。

其中，所述測試請求中攜帶有待測對象的默認的服務類型和/或運行環(huán)境。

所述確定模塊502，具體用于當所述測試請求中包含用戶指定的服務類型和/或運行場景時，將用戶指定的所述服務類型和/或運行場景，確定為所述測試請求對應的測試環(huán)境信息；當所述測試請求中不包含用戶指定的服務類型和/或運行場景時，將所述待測對象對應的服務類型和/或運行環(huán)境，確定為所述測試請求對應的測試環(huán)境信息。

在一個典型的配置中，計算設備包括一個或多個處理器(CPU)、輸入/輸出接口、網絡接口和內存。

內存可能包括計算機可讀介質中的非永久性存儲器，隨機存取存儲器(RAM)和/或非易失性內存等形式，如只讀存儲器(ROM)或閃存(flash RAM)。內存是計算機可讀介質的示例。

計算機可讀介質包括永久性和非永久性、可移動和非可移動媒體可以由任何方法或技術來實現信息存儲。信息可以是計算機可讀指令、數據結構、程序的模塊或其他數據。計算機的存儲介質的例子包括，但不限于相變內存(PRAM)、靜態(tài)隨機存取存儲器(SRAM)、動態(tài)隨機存取存儲器(DRAM)、其他類型的隨機存取存儲器(RAM)、只讀存儲器(ROM)、電可擦除可編程只讀存儲器(EEPROM)、快閃記憶體或其他內存技術、只讀光盤只讀存儲器(CD-ROM)、數字多功能光盤(DVD)或其他光學存儲、磁盒式磁帶，磁帶磁磁盤存儲或其他磁性存儲設備或任何其他非傳輸介質，可用于存儲可以被計算設備訪問的信息。按照本文中的界定，計算機可讀介質不包括暫存電腦可讀媒體(transitory media)，如調制的數據信號和載波。

還需要說明的是，術語“包括”、“包含”或者其任何其他變體意在涵蓋非排他性的包含，從而使得包括一系列要素的過程、方法、商品或者設備不僅包括那些要素，而且還包括沒有明確列出的其他要素，或者是還包括為這種過程、方法、商品或者設備所固有的要素。在沒有更多限制的情況下，由語句“包括一個……”限定的要素，并不排除在包括所述要素的過程、方法、商品或者設 備中還存在另外的相同要素。

本領域技術人員應明白，本發(fā)明的實施例可提供為方法、系統(tǒng)或計算機程序產品。因此，本發(fā)明可采用完全硬件實施例、完全軟件實施例或結合軟件和硬件方面的實施例的形式。而且，本發(fā)明可采用在一個或多個其中包含有計算機可用程序代碼的計算機可用存儲介質(包括但不限于磁盤存儲器、CD-ROM、光學存儲器等)上實施的計算機程序產品的形式。

以上所述僅為本發(fā)明的實施例而已，并不用于限制本發(fā)明。對于本領域技術人員來說，本發(fā)明可以有各種更改和變化。凡在本發(fā)明的精神和原理之內所作的任何修改、等同替換、改進等，均應包含在本發(fā)明的權利要求范圍之內。