消息交互系統領域驅動測試框架研究與應用

鞠煒剛 胡繼東

(中興通訊南京研究所 江蘇 南京 210012)

消息交互系統領域驅動測試框架研究與應用

鞠煒剛 胡繼東

(中興通訊南京研究所 江蘇 南京 210012)

為解決消息交互系統測試用例編寫維護復雜、效率低下的問題，基于領域驅動測試思想，針對消息交互系統的特點，提出一種通用消息交互系統領域測試模型。在此基礎上設計開發了消息交互系統領域驅動測試框架，用領域語言描述測試用例，采用領域驅動設計DDD四層架構，基于領域模型，對測試用例進行組織、設計和開發，并直接驅動執行，提高了消息交互系統的測試效率。

消息交互系統 領域驅動測試 領域測試模型 測試框架 分層架構

0 引 言

消息交互系統由多個消息處理節點組成，通過消息交互完成業務。典型的網絡通信系統，如移動通信、路由網絡等，還有云計算、大數據系統都屬于消息交互系統。消息交互系統規模大，復雜度高，應用范圍廣，需要通過自動化測試提高產品質量，縮短交付周期，但系統節點類型眾多，節點間消息協議種類豐富，交互流程復雜多變，導致測試用例編寫和維護越來越復雜，不能滿足要求，需要采用新的技術和方法[1-2]。本文基于領域驅動測試思想，針對消息系統的特點，提出了一種通用消息交互系統領域測試模型，設計實現了消息交互系統領域驅動測試框架，在通信產品測試中得到了有效應用。

1 傳統測試框架

消息交互系統傳統測試框架中，被測系統邊界是一系列真實消息節點，邊界外是模擬消息節點，測試步驟如下：

(1) 被測消息節點執行命令進行預置條件設置；

(2) 模擬消息節點通過消息交互方式向邊界內系統發起測試；

(3) 被測消息節點執行檢查命令進行結果檢查。

傳統測試框架如圖1所示[3]。

圖1 傳統測試框架

配置、檢查命令和交互消息需要詳細編輯，存在以下問題：

(1) 測試用例由消息序列組成，消息由協議細節構成，用例間存在大量重復消息和協議細節，編寫復雜，不易理解；

(2) 協議字段升級變化后相關測試用例需要修改，代價大；

(3) 預置條件和結果檢查需要通過命令方式操作，易用性和可維護性差。

這些問題導致消息交互系統測試用例編寫速度慢，維護成本高，很難應對變化，給測試人員使用帶來極大不便，為此設計了一種消息交互系統領域驅動測試框架解決這些問題。

2 領域驅動測試框架

2.1 相關工作

目前基于領域的軟件測試方法在國內外受到不少關注，研究主要集中于軟件測試領域知識表示、管理和應用的方法。其中知識表示的研究主要集中于采用各種方法對軟件測試用例進行領域知識表示，例如本體理論[4]，知識管理主要研究知識的獲取、存儲和檢索等管理方法，更有效地對測試領域知識進行有效的組織和管理，知識應用主要研究如何將軟件測試活動和知識緊密聯系起來進行有效的應用，提出了一些方法[5-6]。但是這些研究各自側重于某一方面，沒有從整體形成一個通用的體系和框架，測試領域知識的表示和組織在層次結構上相對扁平化，很難應對大型復雜系統的測試。另外針對應用越來越廣泛的消息交互系統也未發現有文獻提出適用性強的可擴展的通用領域測試模型，但是通信產品的測試又迫切需要，因此我們基于領域驅動設計DDD的分層架構提出了一種通用的領域驅動測試框架。針對消息交互系統的特點設計了一個通用的領域測試模型，并且用領域專用語言DSL來描述消息交互，自動處理基于消息收發的測試，很適合大型復雜通信系統的測試。

2.2 總體架構

消息交互系統領域驅動測試框架采用DDD四層架構[7]，由表示層、服務層、領域層、基礎設施層構成，系統總體架構如圖2所示。

圖2 領域驅動測試框架總體架構

測試人員在表示層編寫測試用例，表示層分兩個子層，上層是測試用例層，下層是領域關鍵字層，測試用例由高層領域測試關鍵字組成，高層關鍵字由低層關鍵字分層組裝而成。

表示層以下是領域驅動測試庫，由測試服務層、領域層和基礎設施層構成，層次清晰。表示層最底層測試關鍵字由測試服務層提供接口實現。

測試服務層對底層領域關鍵字提供測試接口，對內協調驅動領域層的領域對象來交互協作完成測試。

領域層提供了領域對象模型和消息的DSL模型。領域對象模型包括各類消息節點、用戶角色和業務對象，實現業務測試邏輯，通過交互協作完成測試。對于每一種模擬消息節點，定義消息DSL模型，可以根據語義自動對消息進行處理。

基礎設施層對上層提供支撐，分為兩個層次，上層是設備控制層，包括了消息節點控制和測試引擎控制，下層是通道層。

針對消息交互系統的特點，采用DDD的分層架構，結構更加清晰，有利于更好設計、開發。

2.3 測試用例組織

通過分析消息交互系統領域，將需求特性用驗收測試驅動開發ATTD用例來描述[8]。首先明確測試邊界，然后劃分不同測試領域，對每個領域劃分不同特性，特性進一步劃分不同測試集，測試集由相關的測試用例構成。不同測試用例的共性操作向所屬測試集提取，測試集的共性操作又向所屬特性提取，依次類推。

2.4 領域測試關鍵字組織

領域測試關鍵字是按基礎關鍵字和特性關鍵字組織的[9]。其中基礎關鍵字是公共基礎的領域關鍵字，各領域的測試用例都可以使用，而特性關鍵字針對某一具體領域，在基礎關鍵字基礎上封裝與該領域相關的高粒度的流程性關鍵字。基礎領域關鍵字庫的組織如圖3所示。

圖3 基礎領域關鍵字庫組織

其中公用關鍵字是與測試邊界無關的關鍵字，測試邊界相關業務關鍵字主要是各種業務關鍵字，在邊界內按場景進行劃分。

根據消息交互系統的特點，測試用例通過關鍵字拆分，一般由預置條件設置關鍵字、業務測試關鍵字和結果檢查關鍵字組成，如圖4所示。

圖4 測試用例領域關鍵字組裝結構

2.5 測試服務層

測試服務層對上層提供測試接口，協調驅動領域層的領域對象交互協作完成測試。服務層根據消息交互系統的特征，分為用戶測試服務和消息節點測試服務，分別對各種用戶業務、控制操作和消息節點控制操作進行測試，如圖5所示。

圖5 測試服務層

1) 用戶測試服務

其中用戶業務測試服務包括用戶消息發送、接收服務，業務測試關鍵字最終分解為消息發送和接收關鍵字，調用該服務完成消息發送和接收；消息節點用戶測試服務包括用戶在消息節點上進行信息設置、檢查服務，分為真實和模擬節點兩種情況。

2) 消息節點測試服務

提供對真實消息節點和模擬消息節點的各種設置和檢查服務，針對消息節點的設置和結果檢查關鍵字調用相關服務完成操作。

2.6 領域層

領域層模型可以分為消息節點模型、用戶角色模型和業務模型三大部分，用統一建模語言UML[10-11]建模類圖如圖6所示。

圖6 領域模型層

2.6.1 消息節點模型

消息節點模型描述了消息節點和它們之間的關系，消息節點包括真實和模擬節點。領域模型中，消息節點基類Ne是公共基類，具有消息節點的公共屬性，包括標識、ip地址和拓撲連接關系linkNeList屬性，真實消息節點類RealNe和模擬消息節點類SimuNe均從它繼承。

1) 真實消息節點

RealNe是各類真實消息節點的父類，擁有基礎設施層的設備控制基類對象device。具體類型真實消息節點類從RealNe繼承，提供對真實消息節點配置、檢查及其他控制的接口方法，并通過設備控制對象對真實消息節點進行控制。

2) 模擬消息節點

SimuNe是各類模擬消息節點的父類，擁有users、messageBuffer、engine屬性。其中users記錄接入的用戶列表，用于接收消息后根據用戶標識查找用戶對象；messageBuffer存儲接收到的發送給節點的非用戶消息；engine為消息節點使用的引擎代理，和實際測試引擎交互進行消息收發。

模擬消息節點類提供了消息收發方法，其中sendMsg委托engine發送消息；receiveMsg是消息接收回調函數，當基礎設施層收到消息分發到本節點時調用該函數接收。

具體類型的模擬消息節點從SimuNe繼承擴展，實現具體的設置、檢查和業務流程方法。

2.6.2 用戶角色模型

用戶角色模型包括用戶和角色對象，描述了領域模型中的用戶、角色之間的關系。用戶具有公共屬性和行為，在不同消息節點中承擔不同的角色，具有不同的屬性和行為[12]。

用戶對象User具有用戶標識、別名等屬性，并通過send和receive方法提供用戶消息發送和接收的入口處理，然后根據用戶接入的模擬消息節點類型，委托給相應的用戶角色對象處理。

用戶角色的公共基類是UserRole，各種類型的用戶角色從它繼承。UserRole存儲用戶在不同類型消息節點上的數據，具有一個消息接收緩沖區，存放接收的消息，UserRole直接關聯業務模型對象。UserRole提供了send、receive基類方法，根據消息DSL模型進行消息收發的通用處理。

各類用戶角色從UserRole基類繼承擴展，實現一些具體的消息收發和設置、結果檢查等邏輯。

2.6.3 業務模型

業務模型和用戶角色模型關聯，和具體的業務領域相關，需要根據消息交互系統的具體業務進行分析，獲得業務模型對象和關聯關系。

2.7 基礎設施層

上層進行設備控制，包括消息節點控制和測試引擎控制，其中消息節點控制使用設備控制對象對真實消息節點進行控制，而測試引擎控制通過引擎代理進行，采用json格式消息作為控制接口。下層為上層提供不同類型的通道。

3 領域驅動測試過程

消息交互系統領域驅動測試框架的具體測試過程如圖7所示。

圖7 消息交互系統領域驅動測試過程

左側大框為消息交互領域驅動測試框架，右側框為被測消息交互系統。測試框架包括主框架和測試引擎兩部分，可以分別部署在不同的測試機上，主框架從左到右依次分層，可連接多個測試引擎。

測試用例由領域驅動測試關鍵字組成，最終分解為消息收發、預置條件和結果檢查關鍵字，下面說明具體測試實現過程。

3.1 消息發送和接收

3.1.1 消息模型DSL

對模擬消息節點定義消息模型DSL[13-14]，對每一種消息，定義其在測試中發送或接收處理的語義。消息交互系統中，消息本質上是對領域模型的操作控制，結合測試進行擴充，用yml定義如下：

消息通用部分定義

消息名

方向(請求或響應)

接收條件

應答消息成功定義

消息領域控制部分定義

領域名稱1

操作

操作數據

消息領域控制部分定義消息對各領域的操作控制，包括領域名稱、對領域的操作，可以有一種或多種操作，目前定義CREATE、REMOVE、MODIFY三種基本操作，操作中可以定義操作數據，一般為消息字段和相關領域屬性的映射。根據業務領域模型和消息模型DSL定義，按照對領域定義的操作，進行消息收發處理，包括構造、保存消息和對領域對象生命周期、狀態的控制。

3.1.2 消息發送處理過程

如圖7所示，消息發送處理過程如下：

(1) 消息發送關鍵字通過服務層請求用戶對象發送消息；

(2) 用戶對象根據接入的模擬消息節點獲得用戶角色，請求其發送消息；

(3) 用戶角色請求消息節點添加用戶，建立用戶ID和用戶對象的映射，用于接收消息查找用戶；

(4) 用戶角色獲取發送消息DSL模型，根據定義從領域模型獲取數據構造發送消息，對領域對象進行生命周期和狀態控制；

(5) 用戶角色將消息編碼成json格式，請求模擬消息節點發送；

(6) 模擬消息節點委托引擎代理發送，引擎代理將消息發送給測試引擎；

(7) 測試引擎將消息協議編碼后在鏈路上發送到被測系統消息節點。

3.1.3 消息接收處理過程

消息接收處理過程如下：

(1) 被測真實消息節點回送應答或發送請求；

(2) 測試引擎收到消息后協議解碼，轉為json格式發送給引擎代理；

(3) 引擎代理的接收線程接收消息，存放在接收消息緩沖區，另一分發線程從緩沖區取消息，根據目的消息節點名，找到模擬消息節點對象，調用接收回調方法處理；

(4) 模擬消息節點根據消息中用戶ID查找用戶角色，將消息添加到角色的接收隊列中；

(5) 消息接收關鍵字通過服務層接收服務找到用戶對象，請求接收消息；

(6) 用戶對象獲得用戶角色，請求其接收消息；

(7) 用戶角色獲取接收消息DSL模型，得到消息接收條件定義，從緩沖區接收消息；

(8) 用戶角色根據領域模型中設置的預期對接收的消息進行比較；

(9) 用戶角色根據領域模型和消息模型DSL定義的接收動作進行接收處理，對領域對象進行生命周期和狀態控制。

3.2 預置條件和結果檢查

預置條件和結果檢查關鍵字分解為以下對消息節點和用戶的控制操作：

1) 對真實消息節點控制操作

請求真實消息節點對象執行配置、檢查方法，將參數自動組裝成操作命令，請求設備控制對象通過底層通道對真實消息節點執行命令。

2) 對模擬消息節點控制操作

請求模擬消息節點對象執行設置、檢查方法，對相關屬性進行設置、檢查。

3) 對用戶控制操作

對于用戶自身業務屬性設置、檢查，直接請求用戶對象處理；對于在真實消息節點上配置、檢查用戶特性的，請求真實消息節點對象處理；對于在模擬消息節點中設置、檢查用戶特性的，請求相應用戶角色處理。

4 應用實例

在移動通信系統測試中成功應用了消息交互系統領域驅動測試框架，被測系統是產品X，包括A、B網元，測試系統由模擬網元C、D組成。從其中一個核心用例出發進行領域關鍵字拆分，領域建模，驅動設計和開發，核心用例如下：

A網元打開策略開關，用戶通過C網元接入A，接入過程中A向D網元請求策略，D根據策略配置返回策略控制信息，A根據策略建立相應的承載。

測試用例通過拆分由以下領域關鍵字組成：

(1) 打開策略開關 A

(2) 用戶設置QOS策略 USER1 ，D

(3) 用戶發起帶策略附著 USER1，C，A，D

(4) 檢查用戶是否附著成功 USER1 ，A

(5) 檢查用戶是否符合QOS策略 USER1， A

(6) 用戶去附著 USER1

“用戶發起帶策略的附著”業務關鍵字進一步拆分為模擬網元C和D對真實網元A進行消息收發的一系列關鍵字組合。

應用消息交互系統領域驅動測試框架，領域層通過擴展繼承很容易實現針對A、C、D網元的用戶角色對象：AUserRole、CUserRole、DUserRole，模擬消息節點對象：SimuC、SimuD，真實消息節點對象：RealA、RealB，業務對象：Session、Bear，并對模擬網元C、D定義了消息模型DSL，擴展實現相關的消息收發、配置、設置、檢查等測試行為，完成了服務層對外提供的測試服務，領域層模型類圖如圖8所示。

圖8 產品X測試領域模型類圖

通過在X產品實際應用消息交互系統領域驅動測試框架，取得了較好的效果，主要有以下幾點：

(1) 測試用例使用領域語言描述，更容易理解和編寫；

(2) 消息協議或版本升級，只需要修改測試庫，用例不需要任何修改，維護方便，可以快速應對變化；

(3) 測試用例和領域關鍵字的設計、開發、組織更加快速、有效，比使用傳統框架節約一半時間。

5 結 語

消息交互系統領域驅動測試框架是一種通用測試框架，可以有效適應各種消息交互系統復雜的業務測試，通過領域模型分析，繼承擴展框架，對消息節點、用戶角色、業務領域建模、分層設計，快速有效地開發測試用例和領域關鍵字，更加容易編寫和維護，可以在基于消息交互的通信和互聯網產品測試中推廣。

未來應該向基于DSL的消息交互系統測試框架自動生成方面繼續探索研究。

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

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

[3] 夏晶. 基于QTP的功能自動化測試框架的研究與應用[D]. 武漢：武漢科技大學, 2010.

[4] 徐克圣，張影. 基于領域知識軟件測試方法的研究與應用[J]. 電腦知識與技術, 2014, 10(10):2457-2460.

[5] 柳永坡，鄒磊，金茂忠，等. 軟件測試領域的知識管理及模型研究[J]. 計算機應用研究, 2009, 26(1):143-145.

[6] Bj?rnson F O，Dings?yr T. Knowledge management in software engineering: A systematic review of studied concepts, findings and research methods used[J]. Information and Software Technology, 2008, 50(11):1055-1068.

[7] Eric Evans. 領域驅動設計[M]. 北京：人民郵電出版社, 2010:11.

[8] Beck K. Test-driven development by example[M]. Upper Saddle River: Addison Wesley, 2002:95-128.

[9] 王君，朱美正，李欣. 關鍵字驅動測試框架的研究與實現[J]. 計算機工程與設計, 2010, 31(10):2246-2248.

[10] 冀振燕. UML系統分析設計與應用案例[ M] . 北京：人民郵電出版社, 2003.

[11] Roff J T. UML a Beginner's Guide[ M] . 張瑜，譯. 北京：清華大學出版社, 2003:9-13.

[12] 譚宗威，劉振宇，陽小華，等. 一種實現DCI架構的方法[J]. 計算機技術與發展, 2011, 21(7):16-20.

[13] 胡海濤，劉穎. 一種基于DSL的服務組合語言[J]. 計算機工程, 2011, 37(9):107-109.

[14] Jouault F，Bézivin J. KM3: A DSL for Metamodel Specification[J]. Lecture Notes in Computer Science, 2006, 4037:171-185.

RESEARCH AND APPLICATION OF THE DOMAIN-DRIVEN TEST ARCHITECTURE FOR MESSAGE INTERACTION SYSTEM

Ju Weigang Hu Jidong

(ZTENanjingInstitute,Nanjing210012,Jiangsu,China)

A universal domain-driven model for the message interaction system based on the theory of domain-driven test and the characteristics of message interaction system is proposed to solve the problem of complexity and low efficiency in writing and maintaining test cases in the message interaction system.On the basis of this model,the domain-driven test architecture for message interaction system is designed and developed,and the test cases are described in domain language.At the same time,we organize,design and develop test cases based on domain model by using the DDD four-layer architecture,and then execute them directly.In such a way,the test efficiency of message interaction system is enhanced successfully.

Message interaction system Domain-driven test Domain test model Test framework Layered architecture

2015-10-11。鞠煒剛，工程師，主研領域：軟件測試，自動化測試。胡繼東，工程師。

TP3

A

10.3969/j.issn.1000-386x.2017.01.007