基于環境資源自動匹配的云測試框架研究與應用

鞠煒剛 歐林寶

1(中興通訊南京研究所 江蘇 南京 210012) 2(中興通訊天津研究所 天津 300308)

0 引 言

軟件測試在軟件生命周期中占有十分重要的地位，是保障軟件質量的重要手段，必須不斷地對軟件進行測試[1-2]，首先要搭建配置測試環境，然后執行測試用例獲取結果。傳統的方式是測試人員根據測試要求搭建、調整測試環境資源，隨著軟件測試環境的復雜度越來越高，這種方式越來越不能滿足需要。采用基于虛擬化技術的云測試可以有效獲取資源，生成并配置所需測試環境[3]。但也存在一定局限性，例如復雜環境自動生成時間較長，同時對不支持虛擬化需要在真實硬件組網環境下測試的軟件不能滿足要求，對這類情況需要采用一種新的技術和方法。本文提出一種測試環境資源云化，測試用例按需自動匹配環境、分布式調度執行的云測試思路。在此基礎上設計開發了云測試框架，以更好地完成對復雜環境組網下的軟件產品的測試。

1 測試環境資源使用方式概述

在軟件測試中如何高效地使用測試環境資源進行測試一直是重要的課題，包括測試環境的建立、使用、釋放和管理，要求建立、釋放時間短，利用率高等[4]。

1.1 傳統方式

在傳統方式中，測試人員根據測試需要搭建或調整測試環境資源，修改測試用例環境參數，執行測試用例，返回結果報告[5]，但存在以下問題：

(1) 測試環境資源缺乏管理，執行測試用例時很難快速找到合適的空閑環境，環境資源利用率低下。

(2) 找不到合適環境的情況下，需要根據需求搭建、調整、配置環境，測試準備時間長，效率低，而且可能存在重復搭建，浪費資源。

(3) 測試用例和環境資源數據緊耦合，移植到目標環境比較困難。

(4) 對于批量用例執行，只能在一套環境執行，效率不高，采用手工分解的方式比較困難，結果也不容易合并。

1.2 基于虛擬化的云測試

隨著云計算技術的發展誕生了云測試，云測試是一種有效利用云計算環境資源對軟件進行測試的新方式[6-7]。其中一種方法是基于虛擬化的云測試，在測試用例執行前獲取虛擬化的計算、存儲、網絡等云資源，自動創建配置廉價、便捷、高效的測試環境，測試完成后釋放資源，加速了整個軟件測試進程，同時測試環境資源按需動態申請和釋放，資源利用率很高，但是有兩個主要限制：

(1) 一些軟件產品并沒有設計在虛擬化平臺上運行，需要改造適配，而為了測試改造產品是不合適的，而另一些軟件產品必須在真實硬件環境組網下測試。

(2) 對于一些環境組網和配置復雜的軟件系統，獲取虛擬資源并自動創建、配置環境的時間較長，不能滿足測試要求。

針對以上傳統方式存在的問題和基于虛擬化技術的云測試的一些局限性，我們提出了一種測試環境資源云化，按需自動匹配環境，分布式調度執行的云測試新思路。在此基礎上設計開發了云測試框架，可以有效地使用測試環境資源進行測試，提高環境利用率和執行效率，并在通信系統產品測試中進行了有效的應用。

2 基于環境資源自動匹配的云測試框架

2.1 物理架構

基于環境資源自動匹配的云測試框架的物理架構如圖1所示。

圖1 物理架構

云測試物理框架由一個云測試服務器master節點通過網絡連接多個客戶端slave節點組成，屬于典型的分布式架構[8]，可以由大量廉價的PC機組成，也可以在IAAS上基于虛機或PAAS上基于容器來部署，非常靈活[9-10]。

云測試服務器master是云測試的調度中心，主要根據測試任務中測試用例的要求進行環境資源匹配，將用例各自分發調度到合適的測試環境執行，并匯總結果報告輸出。云測試客戶端slave節點連接測試環境并運行測試執行器進行測試，測試環境可以直接部署在客戶端slave節點，也可以由多個設備組成復雜的組網環境，由slave節點進行對接，所有的測試環境構成測試環境資源池，實現了測試環境的云化。云測試框架同時支持真實環境和虛擬化環境，以滿足各種軟件的測試需要。

2.2 工作原理

基于環境資源自動匹配的云測試框架的基本工作原理如圖2所示。

圖2 工作原理

如圖所示，在云測試框架中，每個客戶端slave節點都有一個環境資源描述文件，用來描述所連接的環境資源信息，客戶端節點會定時向服務器master上報更新環境資源信息。

測試人員通過云測試創建測試任務，任務由一個或多個測試用例構成，用例用文件描述對環境資源的需求，可以按單用例或一組用例來進行描述。

當向云測試服務器master提交測試任務時，服務器對測試任務中的每個用例根據其對環境資源的需求，調用資源匹配算法，與上報的客戶端環境資源信息進行預匹配。預匹配成功后將測試用例放到調度隊列中等待調度，同一個任務中不同的測試用例根據需要可以匹配到不同的測試環境。

當某個客戶端節點空閑后會向服務器請求測試用例執行， master從調度隊列中獲取和該客戶端節點匹配的測試用例，請求客戶端slave節點調度執行，執行完成后將測試結果報告回送給服務器。當一個測試任務中所有測試用例均執行完成后，master會匯總合并整個測試任務的結果報告。

2.3 關鍵技術

2.3.1 測試環境云化

基于環境資源匹配的云測試首先要將測試環境云化，建立共享環境資源池，供云測試系統根據用例需求進行匹配和調度。云化的基礎是測試環境標準化，在根據需求進行測試設計時，一方面分析測試業務流程，根據功能特性對測試用例進行分類，劃分測試集，另一方面要分析各種可能的測試組網環境，進行整理和歸類，形成標準化的環境集。環境標準化是建立在對本領域測試環境分類基礎上的一種對環境資源類型、數量、拓撲組網和配置屬性的標準化，其原則是根據測試需求對環境分類，再根據已分類環境的特征按本領域的標準進行部署、配置，形成滿足測試需求的環境資源池，下面給出一般的規則和方法：

1) 根據業務場景對測試環境分類 針對需求特性中不同業務場景對測試環境進行分類，不同類別環境中需要的資源及資源的業務配置屬性有所不同，例如不同業務場景需要不同類型的服務器組合及業務配置，對于相同的可以歸為一大類環境。

2) 根據非功能性需求對測試環境分類 針對需求特性中的非功能需求部分，包括高可用性、性能、安全等的要求對測試環境進行分類，不同類別的測試環境中資源的數量、拓撲組網和非功能性配置屬性有所不同，例如高可用性需要數據庫主從環境或業務服務器多活配置，對于相同的可以歸為一大類環境。

3) 對分類的環境確定標準化的部署特性 對已劃分出的幾大類典型環境，進一步對每一類測試環境需要的資源類型、數量、組網方式及業務或非功能性配置屬性進行歸納，就可以形成本領域的部署標準，從而達成針對某需求的測試環境標準化的目標。

環境標準化后即根據要求來搭建、配置測試環境，可以部署在真實或虛擬化平臺上，然后將測試環境掛接到云測試框架的slave節點上接入云測試，形成云化的共享環境資源池[11]。

2.3.2 資源描述和匹配

為了將測試用例對環境資源的需求和云化的環境資源進行匹配，必須對兩者分別進行描述，然后調用資源匹配算法進行匹配，輸出是否匹配的結果，如圖3所示。

圖3 環境資源匹配

云化的環境資源是通過slave節點接入云測試框架的，每個slave節點上都有一個環境資源描述文件，描述測試環境中資源節點和節點間拓撲連接關系，資源節點描述包括基本屬性和擴展屬性；測試用例對環境資源的需求用環境資源請求文件來描述，具有相同資源需求的測試用例或用例集可以共享同一個描述文件，描述對資源節點和節點間拓撲連接的要求，其中資源節點可以描述對資源類型和各種屬性的具體要求。

測試人員提交測試任務時，將任務中用例對環境資源的請求文件和環境資源池中已具備的環境資源描述文件應用匹配算法進行自動匹配，做到了測試用例與環境完全隔離。

2.3.3 分布式調度

一個測試任務包括多個測試用例，每個測試用例可以根據對環境資源的需求匹配調度到不同的測試環境分布式執行，執行完畢后匯總結果報告，極大提高了空閑環境利用率，同時用例分發到多個環境分布式執行，極大地提高了測試執行效率[12]。

3 云測試框架的設計和實現

3.1 框架設計

云測試在框架設計上整個系統分為云服務器master節點、客戶端Slave節點和瀏覽器三部分，master節點和slave節點通過JSON格式的消息進行通信[13]，master節點通過restful接口和瀏覽器交互，如圖4所示。

圖4 系統框架

3.1.1 云服務器master節點

master節點是云調度中心，由一個Web Server和一個調度Server組成，其中Web Server主要處理測試任務、測試環境、用戶和日志的管理，調度Server則專門負責處理用例對環境資源的匹配、任務調度和執行觸發，Web Server和調度Server通過消息通信來相互協作。整個框架設計采用了DDD的四層架構，分為表示層、服務層、領域層和基礎設施層[14]，其中表示層由Web Server來提供任務、環境、用戶和日志管理的操作界面。服務層包括Web Server提供的測試任務、環境、用戶、日志操作服務和調度Server提供的匹配、調度、執行觸發等服務。領域層則由Model提供的領域對象組成，包括任務、用例和環境等各種領域對象，服務層提供的服務由領域層對象交互協作提供?；A設施層則提供了對測試引擎、數據庫、SVN以及消息通信等底層的處理。

3.1.2 客戶端slave節點

slave節點是客戶端節點，層次相對比較簡單，分領域層和基礎設施層，其中領域層有測試用例和報告等領域對象，主要處理用例申請、用例執行和結果上報，基礎設施層則包括了對測試框架、消息通信、日志等的基礎處理。

3.2 資源匹配

3.2.1 資源描述

在云測試框架中，資源描述包括了對資源池中已有的環境資源描述和用例對環境資源要求的描述兩大類。

3.2.1.1 環境資源描述

對于資源池中已存在的環境資源，描述中應包括資源描述resources和資源間拓撲關系links這兩大部分，下面對如圖5所示的測試環境進行描述。

圖5 環境資源結構

圖5環境描述如下：

{″id″: 資源id1, ″type″:設備類型1,″attributes″:{″屬性″: ″屬性值″ }},

{″id″: 資源id2, ″type″:設備類型1,″attributes″:{″屬性″: ″屬性值″ }},

{″id″: 資源id3, ″type″:設備類型3,″attributes″:{″屬性″: ″屬性值″ }},

{″id″: 資源id4, ″type″:設備類型4,″attributes″:{″屬性″: ″屬性值″ }}]

″links″: [

{″id″:連接id1, ″nodes″: [″資源id1″,″資源id3″]},

{″id″:連接id2, ″nodes″: [″資源id2″,″資源id4″]},

{″id″:連接id3, ″nodes″: [″資源id3″,″資源id4″]}]

其中resources部分是描述資源節點，一個環境可以包括一個或多個資源節點。對于每個資源節點包括基本屬性和擴展屬性，其中id為資源id，type為資源類型，都屬于基本屬性，可以根據實際需要擴展資源屬性，擴展屬性放在attributes中，可以有一個或多個。

2.培養業務人員和財務人員稅務籌劃意識及業務能力，最大限度地節約采購成本。餐飲行業進項稅發票的取得直接關系到企業的經營成本及利潤的多寡，營改增后在企業里應對相關政策進行宣傳和培訓，尤其要對業務人員和財務人員加強增值稅及發票知識的培訓，讓他們清楚地知道能否取得可抵扣發票及取得發票的稅率對于經營成本和企業利潤都產生直接的影響。采購人員應減少向小規模納稅人的供應商采購，因為小規模納稅人一般只能開具增值稅普通發票，即使到稅務局代開發票也只是3%的稅率。在和供應商的價格談判過程中，除了要考慮采購總價還要考慮可抵扣的稅金對于成本的影響。

links部分描述了resources中資源節點的拓撲連接關系，可以根據實際情況描述一個或多個連接關系。其中每個連接包括了連接id和nodes屬性，nodes用來描述拓撲連接的兩端，例如圖5的環境描述″links″中的{″id″:連接id1, ″nodes″: [″資源id1″,″資源id3″]}，表示了資源id1連接到資源id3這樣一個連接。

3.2.1.2 用例對環境資源需求描述

″resources″：

{

″資源1″: {″reqType″: ″資源類型1″, ″擴展屬性1″: ″擴展屬性1值″},

″資源3″: {″reqType″: ″資源類型3″},

″資源1-資源3″: {″reqType″: ″link″, ″nodes″: [″資源1″,″資源3″]},

}

如上分別描述了資源節點和節點間拓撲連接關系的要求。

對于資源節點要求的描述，可以描述一個或多個需要的資源節點，這里和已有環境資源描述不同的是，在資源節點請求中只需要描述需要匹配的屬性，可以包括基本屬性和擴展屬性。對于基本屬性 ，reqType表示需要的資源類型，對于擴展屬性，根據實際需要描述一個或多個需要匹配的擴展屬性，例如上述描述中資源1攜帶了擴展屬性1和期望值1，表示希望擴展屬性1具有期望值1，如果不需要匹配擴展屬性，則可以不描述，如資源3。

對于節點間拓撲連接關系要求的描述，可根據需要描述一個或多個。例如上述例子描述了名為″資源1-資源3″的連接關系，其中″nodes″: [″資源1″,″資源3″]表示了需要資源節點1連接到資源節點3。

3.2.2 資源匹配算法

環境資源匹配算法接受兩個輸入，一是測試用例對環境資源的需求描述，二是實際存在的某個環境資源描述，通過執行匹配算法，輸出是否匹配的結果，具體的匹配算法分兩個步驟：資源節點匹配和拓撲連接關系匹配。

第1步資源節點匹配

為用例的環境資源請求中每一個資源節點從待匹配的環境資源描述文件中找到所有匹配上的資源節點，具體方法如下：

1) 遍歷用例對環境資源請求中的所有資源節點，對每個資源節點i繼續2)。

2) 遍歷環境資源描述中已存在的所有資源節點，對每個資源節點j繼續3)。

3) 比較請求的資源節點i和已有的資源節點j是否匹配。

4) 如果匹配將資源節點j加入到資源節點i的匹配節點列表matched[i][]中。

注意在3)中進行比較時，對節點的基本屬性和需要的擴展屬性進行比較匹配，當所有請求的屬性都匹配時，節點才匹配成功。

以3.2.1節中資源描述和資源請求為例，資源請求中資源節點1匹配到2個資源節點：[{″id″: 資源id1}，{″id″: 資源id2}]；資源節點3匹配到1個資源節點：[{″id″: 資源id3}]。

第2步拓撲連接關系匹配

在第1步資源節點匹配中，每個需要的資源節點都會匹配到一個或多個滿足要求的環境資源節點，接下來進行拓撲連接關系匹配，具體方法如下：

1) 針對第1步環境資源請求中每個資源節點匹配到的環境資源節點(1個或多個)，獲取笛卡爾積的各種組合關系。

2) 針對環境資源請求中對資源節點間拓撲關系的要求，遍歷笛卡爾積組合關系中的每個組合，進行拓撲連接關系匹配，記錄下每個匹配上的組合關系。

3) 如果存在一個或多個組合關系滿足匹配要求，則選擇其中一個資源節點組合作為匹配結果，否則返回無法匹配。

以3.2.1節中資源描述和資源請求為例，在第1步資源節點匹配中，資源節點1匹配到的節點為：[{″id″: 資源id1}，{″id″: 資源id2}]；資源節點3匹配到的節點為：[{″id″: 資源id3}]。那么根據步驟1)，笛卡爾積有兩個組合，分別為組合1：[{″id″: 資源id1},{″id″: 資源id3}]和組合2：[{″id″: 資源id2},{″id″: 資源id3}]。再根據步驟2)進行匹配，從這兩個組合關系中根據拓撲連接關系的要求，組合1中資源id1連接到資源id3，組合關系的兩個端點的類型符合3.2.1節資源請求中拓撲連接的要求，而組合2不符合要求，因此匹配到唯一符合要求的組合1并記錄下來，該環境滿足測試用例對環境資源的要求，匹配成功。

3.3 調度匹配過程

云測試框架的資源匹配和調度過程由master節點和slave節點協作完成[15]，如圖6所示。

圖6 匹配調度過程

其中master節點包括任務、調度、匹配、環境管理和報告5個核心模塊，slave節點包括執行器和環境管理2個核心模塊，它們之間交互協作完成了整個調度匹配，可以分為預匹配和正式匹配兩個過程。

3.3.1 預匹配過程

測試任務提交后，云服務器master根據每個測試用例對環境資源的要求和各客戶端節點slave已有的環境資源描述進行預先匹配的過程，具體步驟如下：

(1) 測試人員向云測試master節點提交測試任務，任務模塊接收到處理請求后向調度模塊發送調度請求。

(2) 調度模塊接收到請求后向匹配模塊發送匹配請求，請求對任務中的測試用例進行環境資源匹配。

(3) slave節點的環境管理模塊會定期將環境信息上報給master節點的環境管理模塊。匹配模塊從環境管理模塊獲取環境資源描述信息，調用匹配算法，進行預匹配，針對每個測試用例找到符合匹配要求的環境列表并返回調度模塊。

(4) 調度模塊將匹配的環境列表記錄到用例的預匹配數據區中，然后將用例放入等待調度隊列，并向任務模塊返回應答，預匹配過程完成。

3.3.2 正式匹配過程

(1) 當測試環境空閑后，slave節點的執行器會向master的調度模塊發送請求，請求執行用例。

(2) master的調度模塊從調度隊列中根據前面預匹配的結果找到一個和該slave環境匹配的可執行用例，然后向slave發送執行用例的請求。

(3) slave的執行器收到執行請求后，再進行一次正式匹配，如果匹配將本地環境參數注入到測試用例，執行器開始執行用例，通過消息交互對被測環境進行實際測試。

(4) slave的執行器測試完成后同時向master的報告模塊和調度模塊上報測試報告和用例執行完成的消息。

(5) 調度模塊等待空閑的slave請求執行用例，繼續對測試任務中的用例進行調度分發執行，如果存在多個滿足條件的空閑slave就可以并行執行。

(6) 調度模塊完成任務中所有用例執行后向報告模塊請求合并獲取完整的測試報告，報告模塊對各用例的執行報告進行合并，形成完整的測試報告返回給調度模塊，調度模塊將測試報告保存起來供用戶查看，測試任務匹配調度執行結束。

4 應用實例

在大型復雜通信系統產品A測試中，由于其產品特點，整個產品的一大部分對處理效率的嚴格要求，目前只能在純硬件設備上運行。而另一部分雖然實現了虛擬化，但由于系統的復雜性，獲取虛擬化資源并自動創建、配置環境的時間較長，達到了20分鐘左右。由于產品A只能部分虛擬化，純硬件部分無法自動創建，且虛擬化部分的自動創建時間也很長，無法采用基于虛擬化的云測試技術來有效提升環境的部署和利用效率，為此應用基于環境資源自動匹配的云測試框架來實施。

對于產品A根據功能特性對測試用例劃分測試集，同時采用2.3.1中測試環境標準化的原則和方法對產品A的業務場景和非功能性要求進行分析，對各種可能的測試環境組網進行整理和歸納，部署標準化的環境資源池，有8種標準化環境。

接下來對這8種標準化環境用資源描述語言進行描述，主要描述環境中資源節點關鍵屬性和資源節點間的拓撲連接關系，然后通過slave節點上報到master上。以下是其中一套環境的描述：

″resources″: [

{″id″:″net″,″type″:″NETTYPE″,″attributes″:{″ip″: ″10.43.145.28″,″bureau″:″2″,″version″:″v3.20.1″}},

{″id″:″testpc″,″type″:″TESTPC″,″attributes″:{″ip″: ″10.43.145.20″ }}]

″links″: [{″id″:″testpc_net″,″nodes″: [″testpc″,″net″]}

針對云化的標準化環境資源池，在測試用例上用環境描述語言對環境資源的要求進行描述如下：

″resources″：

{″testpc″: {″reqType″: ″TESTPC″},

″net″: {″reqType″: ″NETTYPE″ },

″testpc_net″:{″reqType″: ″link″, ″nodes″: [″testpc ″,″net″]}

}

在測試執行時，建立了5個測試任務，共1 000多條用例，其中3個測試任務用于功能測試，2個測試任務用于自動化測試。當測試任務觸發執行時，測試用例會自動根據對環境資源的要求匹配到合適的空閑環境執行。當8套標準化環境中有多套空閑且滿足用例要求時，測試任務中的用例會在這些環境中并行執行，完成后將結果匯總上報。

應用基于資源匹配和調度的云測試框架在功能測試和自動化測試中均取得了較好的效果，主要有以下幾點：

1) 產品A的各種典型測試環境云化，測試用例按需自動匹配到合適的空閑環境執行，減少了環境間的沖突，提高了環境資源的利用率。

2) 測試用例匹配到合適的環境執行，測試用例對環境的依賴大大降低，提高了靈活性和可移植性。

3) 產品A的業務場景復雜，用例多，由于云測試框架可采用分布式并行執行，使得自動化測試的時間由8小時縮短為2小時，極大地提高了效率。

5 結 語

基于資源匹配和調度的云測試框架在不同的行業領域都可以應用。需要充分考慮各種業務場景和非功能性要求對典型環境組網的要求，合理規劃云化的環境資源池，并通過環境描述語言描述后掛載到云測試上，通過環境資源匹配接受測試用例的調度執行，極大地提高了環境資源的利用率和測試任務的執行效率。

未來云測試框架應該向自動檢測目標環境并生成環境資源描述以及更豐富的匹配調度策略這兩個方向繼續探索研究，發揮更大的作用。

[1] Patton R.軟件測試[M].北京:機械工業出版社,2002:1-50.

[2] 吳顯光.軟件自動化測試[J].中國新通信,2012,14(14):67-69.

[3] 周楠,舒輝,董衛宇.基于虛擬機的網絡測試環境搭建與調度自動化實現[J].信息工程大學學報,2008,9(1):100-104.

[4] 張媛媛.測試環境管理的研究及應用[D].北京:北京郵電大學,2010.

[5] 龔丹.自動化測試之我見[J].計算機光盤軟件與應用,2012(17):83-84.

[6] 李喬,柯棟梁,王小林.云測試研究現狀綜述[J].計算機應用研究,2012,29(12):4401-4406.

[7] 李喬,鄭嘯.云計算研究現狀綜述[J].計算機科學,2011,38(4):32-37.

[8] Hanawa T,Banzai T,Koizumi H,et al.Large-scale software testing environment using cloud computing technology for dependable parallel and distributed systems[C]//Proc of the 3rd International Conference on Software Testing,Verification,and Validation.Washington DC:IEEE Computer Society,2010:428-433.

[9] 徐鵬,陳思,蘇森.互聯網應用PaaS平臺體系結構[J].北京郵電大學學報,2012,35(1):120-124.

[10] 徐風,王偉平.基于綜合形式(PAAS+IAAS)的云計算平臺的研究與構建[J].科技資訊,2010(32):19-19.

[11] Takayuki B,Hitoshi K,Ryo K,et al.D-cloud:design of a software testing environment for reliable distributed systems using cloud computing technology[C]//Proc of the 10th International Conference on Cluster,Cloud,and Grid Computing.Washington DC:IEEE Computer Society,2010:631-636.

[12] 王躍科,明德祥.基于網絡互聯的分布式測試系統開放體系結構與技術[J].計算機測量與控制,2002,10(8):496-498.

[13] 袁棟梁,孫忠林,田剛,等.基于JSON格式的信息資源共享技術的應用研究[J].計算機與現代化,2010,(9):175-178.

[14] Evans E.領域驅動設計[M].北京:人民郵電出版社,2010.

[15] 左利云,曹志波.云計算中調度問題研究綜述[J].計算機應用研究,2012,29(11):4023-4027.