鞠煒剛 胡繼東

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

消息交互系統(tǒng)領(lǐng)域驅(qū)動測試框架研究與應(yīng)用

鞠煒剛 胡繼東

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

為解決消息交互系統(tǒng)測試用例編寫維護(hù)復(fù)雜、效率低下的問題，基于領(lǐng)域驅(qū)動測試思想，針對消息交互系統(tǒng)的特點，提出一種通用消息交互系統(tǒng)領(lǐng)域測試模型。在此基礎(chǔ)上設(shè)計開發(fā)了消息交互系統(tǒng)領(lǐng)域驅(qū)動測試框架，用領(lǐng)域語言描述測試用例，采用領(lǐng)域驅(qū)動設(shè)計DDD四層架構(gòu)，基于領(lǐng)域模型，對測試用例進(jìn)行組織、設(shè)計和開發(fā)，并直接驅(qū)動執(zhí)行，提高了消息交互系統(tǒng)的測試效率。

消息交互系統(tǒng) 領(lǐng)域驅(qū)動測試 領(lǐng)域測試模型 測試框架 分層架構(gòu)

0 引 言

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

1 傳統(tǒng)測試框架

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

(1) 被測消息節(jié)點執(zhí)行命令進(jìn)行預(yù)置條件設(shè)置；

(2) 模擬消息節(jié)點通過消息交互方式向邊界內(nèi)系統(tǒng)發(fā)起測試；

(3) 被測消息節(jié)點執(zhí)行檢查命令進(jìn)行結(jié)果檢查。

傳統(tǒng)測試框架如圖1所示[3]。

圖1 傳統(tǒng)測試框架

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

(1) 測試用例由消息序列組成，消息由協(xié)議細(xì)節(jié)構(gòu)成，用例間存在大量重復(fù)消息和協(xié)議細(xì)節(jié)，編寫復(fù)雜，不易理解；

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

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

這些問題導(dǎo)致消息交互系統(tǒng)測試用例編寫速度慢，維護(hù)成本高，很難應(yīng)對變化，給測試人員使用帶來極大不便，為此設(shè)計了一種消息交互系統(tǒng)領(lǐng)域驅(qū)動測試框架解決這些問題。

2 領(lǐng)域驅(qū)動測試框架

2.1 相關(guān)工作

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

2.2 總體架構(gòu)

消息交互系統(tǒng)領(lǐng)域驅(qū)動測試框架采用DDD四層架構(gòu)[7]，由表示層、服務(wù)層、領(lǐng)域?qū)?、基礎(chǔ)設(shè)施層構(gòu)成，系統(tǒng)總體架構(gòu)如圖2所示。

圖2 領(lǐng)域驅(qū)動測試框架總體架構(gòu)

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

表示層以下是領(lǐng)域驅(qū)動測試庫，由測試服務(wù)層、領(lǐng)域?qū)雍突A(chǔ)設(shè)施層構(gòu)成，層次清晰。表示層最底層測試關(guān)鍵字由測試服務(wù)層提供接口實現(xiàn)。

測試服務(wù)層對底層領(lǐng)域關(guān)鍵字提供測試接口，對內(nèi)協(xié)調(diào)驅(qū)動領(lǐng)域?qū)拥念I(lǐng)域?qū)ο髞斫换f(xié)作完成測試。

領(lǐng)域?qū)犹峁┝祟I(lǐng)域?qū)ο竽Ｐ秃拖⒌腄SL模型。領(lǐng)域?qū)ο竽Ｐ桶ǜ黝愊⒐?jié)點、用戶角色和業(yè)務(wù)對象，實現(xiàn)業(yè)務(wù)測試邏輯，通過交互協(xié)作完成測試。對于每一種模擬消息節(jié)點，定義消息DSL模型，可以根據(jù)語義自動對消息進(jìn)行處理。

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

針對消息交互系統(tǒng)的特點，采用DDD的分層架構(gòu)，結(jié)構(gòu)更加清晰，有利于更好設(shè)計、開發(fā)。

2.3 測試用例組織

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

2.4 領(lǐng)域測試關(guān)鍵字組織

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

圖3 基礎(chǔ)領(lǐng)域關(guān)鍵字庫組織

其中公用關(guān)鍵字是與測試邊界無關(guān)的關(guān)鍵字，測試邊界相關(guān)業(yè)務(wù)關(guān)鍵字主要是各種業(yè)務(wù)關(guān)鍵字，在邊界內(nèi)按場景進(jìn)行劃分。

根據(jù)消息交互系統(tǒng)的特點，測試用例通過關(guān)鍵字拆分，一般由預(yù)置條件設(shè)置關(guān)鍵字、業(yè)務(wù)測試關(guān)鍵字和結(jié)果檢查關(guān)鍵字組成，如圖4所示。

圖4 測試用例領(lǐng)域關(guān)鍵字組裝結(jié)構(gòu)

2.5 測試服務(wù)層

測試服務(wù)層對上層提供測試接口，協(xié)調(diào)驅(qū)動領(lǐng)域?qū)拥念I(lǐng)域?qū)ο蠼换f(xié)作完成測試。服務(wù)層根據(jù)消息交互系統(tǒng)的特征，分為用戶測試服務(wù)和消息節(jié)點測試服務(wù)，分別對各種用戶業(yè)務(wù)、控制操作和消息節(jié)點控制操作進(jìn)行測試，如圖5所示。

圖5 測試服務(wù)層

1) 用戶測試服務(wù)

其中用戶業(yè)務(wù)測試服務(wù)包括用戶消息發(fā)送、接收服務(wù)，業(yè)務(wù)測試關(guān)鍵字最終分解為消息發(fā)送和接收關(guān)鍵字，調(diào)用該服務(wù)完成消息發(fā)送和接收；消息節(jié)點用戶測試服務(wù)包括用戶在消息節(jié)點上進(jìn)行信息設(shè)置、檢查服務(wù)，分為真實和模擬節(jié)點兩種情況。

2) 消息節(jié)點測試服務(wù)

提供對真實消息節(jié)點和模擬消息節(jié)點的各種設(shè)置和檢查服務(wù)，針對消息節(jié)點的設(shè)置和結(jié)果檢查關(guān)鍵字調(diào)用相關(guān)服務(wù)完成操作。

2.6 領(lǐng)域?qū)?/p>

領(lǐng)域?qū)幽Ｐ涂梢苑譃橄⒐?jié)點模型、用戶角色模型和業(yè)務(wù)模型三大部分，用統(tǒng)一建模語言UML[10-11]建模類圖如圖6所示。

圖6 領(lǐng)域模型層

2.6.1 消息節(jié)點模型

消息節(jié)點模型描述了消息節(jié)點和它們之間的關(guān)系，消息節(jié)點包括真實和模擬節(jié)點。領(lǐng)域模型中，消息節(jié)點基類Ne是公共基類，具有消息節(jié)點的公共屬性，包括標(biāo)識、ip地址和拓?fù)溥B接關(guān)系linkNeList屬性，真實消息節(jié)點類RealNe和模擬消息節(jié)點類SimuNe均從它繼承。

1) 真實消息節(jié)點

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

2) 模擬消息節(jié)點

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

模擬消息節(jié)點類提供了消息收發(fā)方法，其中sendMsg委托engine發(fā)送消息；receiveMsg是消息接收回調(diào)函數(shù)，當(dāng)基礎(chǔ)設(shè)施層收到消息分發(fā)到本節(jié)點時調(diào)用該函數(shù)接收。

具體類型的模擬消息節(jié)點從SimuNe繼承擴(kuò)展，實現(xiàn)具體的設(shè)置、檢查和業(yè)務(wù)流程方法。

2.6.2 用戶角色模型

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

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

用戶角色的公共基類是UserRole，各種類型的用戶角色從它繼承。UserRole存儲用戶在不同類型消息節(jié)點上的數(shù)據(jù)，具有一個消息接收緩沖區(qū)，存放接收的消息，UserRole直接關(guān)聯(lián)業(yè)務(wù)模型對象。UserRole提供了send、receive基類方法，根據(jù)消息DSL模型進(jìn)行消息收發(fā)的通用處理。

各類用戶角色從UserRole基類繼承擴(kuò)展，實現(xiàn)一些具體的消息收發(fā)和設(shè)置、結(jié)果檢查等邏輯。

2.6.3 業(yè)務(wù)模型

業(yè)務(wù)模型和用戶角色模型關(guān)聯(lián)，和具體的業(yè)務(wù)領(lǐng)域相關(guān)，需要根據(jù)消息交互系統(tǒng)的具體業(yè)務(wù)進(jìn)行分析，獲得業(yè)務(wù)模型對象和關(guān)聯(lián)關(guān)系。

2.7 基礎(chǔ)設(shè)施層

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

3 領(lǐng)域驅(qū)動測試過程

消息交互系統(tǒng)領(lǐng)域驅(qū)動測試框架的具體測試過程如圖7所示。

圖7 消息交互系統(tǒng)領(lǐng)域驅(qū)動測試過程

左側(cè)大框為消息交互領(lǐng)域驅(qū)動測試框架，右側(cè)框為被測消息交互系統(tǒng)。測試框架包括主框架和測試引擎兩部分，可以分別部署在不同的測試機(jī)上，主框架從左到右依次分層，可連接多個測試引擎。

測試用例由領(lǐng)域驅(qū)動測試關(guān)鍵字組成，最終分解為消息收發(fā)、預(yù)置條件和結(jié)果檢查關(guān)鍵字，下面說明具體測試實現(xiàn)過程。

3.1 消息發(fā)送和接收

3.1.1 消息模型DSL

對模擬消息節(jié)點定義消息模型DSL[13-14]，對每一種消息，定義其在測試中發(fā)送或接收處理的語義。消息交互系統(tǒng)中，消息本質(zhì)上是對領(lǐng)域模型的操作控制，結(jié)合測試進(jìn)行擴(kuò)充，用yml定義如下：

消息通用部分定義

消息名

方向(請求或響應(yīng))

接收條件

應(yīng)答消息成功定義

消息領(lǐng)域控制部分定義

領(lǐng)域名稱1

操作

操作數(shù)據(jù)

消息領(lǐng)域控制部分定義消息對各領(lǐng)域的操作控制，包括領(lǐng)域名稱、對領(lǐng)域的操作，可以有一種或多種操作，目前定義CREATE、REMOVE、MODIFY三種基本操作，操作中可以定義操作數(shù)據(jù)，一般為消息字段和相關(guān)領(lǐng)域?qū)傩缘挠成?。根?jù)業(yè)務(wù)領(lǐng)域模型和消息模型DSL定義，按照對領(lǐng)域定義的操作，進(jìn)行消息收發(fā)處理，包括構(gòu)造、保存消息和對領(lǐng)域?qū)ο笊芷?、狀態(tài)的控制。

3.1.2 消息發(fā)送處理過程

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

(1) 消息發(fā)送關(guān)鍵字通過服務(wù)層請求用戶對象發(fā)送消息；

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

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

(4) 用戶角色獲取發(fā)送消息DSL模型，根據(jù)定義從領(lǐng)域模型獲取數(shù)據(jù)構(gòu)造發(fā)送消息，對領(lǐng)域?qū)ο筮M(jìn)行生命周期和狀態(tài)控制；

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

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

(7) 測試引擎將消息協(xié)議編碼后在鏈路上發(fā)送到被測系統(tǒng)消息節(jié)點。

3.1.3 消息接收處理過程

消息接收處理過程如下：

(1) 被測真實消息節(jié)點回送應(yīng)答或發(fā)送請求；

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

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

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

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

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

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

(8) 用戶角色根據(jù)領(lǐng)域模型中設(shè)置的預(yù)期對接收的消息進(jìn)行比較；

(9) 用戶角色根據(jù)領(lǐng)域模型和消息模型DSL定義的接收動作進(jìn)行接收處理，對領(lǐng)域?qū)ο筮M(jìn)行生命周期和狀態(tài)控制。

3.2 預(yù)置條件和結(jié)果檢查

預(yù)置條件和結(jié)果檢查關(guān)鍵字分解為以下對消息節(jié)點和用戶的控制操作：

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

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

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

請求模擬消息節(jié)點對象執(zhí)行設(shè)置、檢查方法，對相關(guān)屬性進(jìn)行設(shè)置、檢查。

3) 對用戶控制操作

對于用戶自身業(yè)務(wù)屬性設(shè)置、檢查，直接請求用戶對象處理；對于在真實消息節(jié)點上配置、檢查用戶特性的，請求真實消息節(jié)點對象處理；對于在模擬消息節(jié)點中設(shè)置、檢查用戶特性的，請求相應(yīng)用戶角色處理。

4 應(yīng)用實例

在移動通信系統(tǒng)測試中成功應(yīng)用了消息交互系統(tǒng)領(lǐng)域驅(qū)動測試框架，被測系統(tǒng)是產(chǎn)品X，包括A、B網(wǎng)元，測試系統(tǒng)由模擬網(wǎng)元C、D組成。從其中一個核心用例出發(fā)進(jìn)行領(lǐng)域關(guān)鍵字拆分，領(lǐng)域建模，驅(qū)動設(shè)計和開發(fā)，核心用例如下：

A網(wǎng)元打開策略開關(guān)，用戶通過C網(wǎng)元接入A，接入過程中A向D網(wǎng)元請求策略，D根據(jù)策略配置返回策略控制信息，A根據(jù)策略建立相應(yīng)的承載。

測試用例通過拆分由以下領(lǐng)域關(guān)鍵字組成：

(1) 打開策略開關(guān) A

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

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

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

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

(6) 用戶去附著 USER1

“用戶發(fā)起帶策略的附著”業(yè)務(wù)關(guān)鍵字進(jìn)一步拆分為模擬網(wǎng)元C和D對真實網(wǎng)元A進(jìn)行消息收發(fā)的一系列關(guān)鍵字組合。

應(yīng)用消息交互系統(tǒng)領(lǐng)域驅(qū)動測試框架，領(lǐng)域?qū)油ㄟ^擴(kuò)展繼承很容易實現(xiàn)針對A、C、D網(wǎng)元的用戶角色對象：AUserRole、CUserRole、DUserRole，模擬消息節(jié)點對象：SimuC、SimuD，真實消息節(jié)點對象：RealA、RealB，業(yè)務(wù)對象：Session、Bear，并對模擬網(wǎng)元C、D定義了消息模型DSL，擴(kuò)展實現(xiàn)相關(guān)的消息收發(fā)、配置、設(shè)置、檢查等測試行為，完成了服務(wù)層對外提供的測試服務(wù)，領(lǐng)域?qū)幽Ｐ皖悎D如圖8所示。

圖8 產(chǎn)品X測試領(lǐng)域模型類圖

通過在X產(chǎn)品實際應(yīng)用消息交互系統(tǒng)領(lǐng)域驅(qū)動測試框架，取得了較好的效果，主要有以下幾點：

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

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

(3) 測試用例和領(lǐng)域關(guān)鍵字的設(shè)計、開發(fā)、組織更加快速、有效，比使用傳統(tǒng)框架節(jié)約一半時間。

5 結(jié) 語

消息交互系統(tǒng)領(lǐng)域驅(qū)動測試框架是一種通用測試框架，可以有效適應(yīng)各種消息交互系統(tǒng)復(fù)雜的業(yè)務(wù)測試，通過領(lǐng)域模型分析，繼承擴(kuò)展框架，對消息節(jié)點、用戶角色、業(yè)務(wù)領(lǐng)域建模、分層設(shè)計，快速有效地開發(fā)測試用例和領(lǐng)域關(guān)鍵字，更加容易編寫和維護(hù)，可以在基于消息交互的通信和互聯(lián)網(wǎng)產(chǎn)品測試中推廣。

未來應(yīng)該向基于DSL的消息交互系統(tǒng)測試框架自動生成方面繼續(xù)探索研究。

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

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

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

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

[5] 柳永坡，鄒磊，金茂忠，等. 軟件測試領(lǐng)域的知識管理及模型研究[J]. 計算機(jī)應(yīng)用研究, 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. 領(lǐng)域驅(qū)動設(shè)計[M]. 北京：人民郵電出版社, 2010:11.

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

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

[10] 冀振燕. UML系統(tǒng)分析設(shè)計與應(yīng)用案例[ M] . 北京：人民郵電出版社, 2003.

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

[12] 譚宗威，劉振宇，陽小華，等. 一種實現(xiàn)DCI架構(gòu)的方法[J]. 計算機(jī)技術(shù)與發(fā)展, 2011, 21(7):16-20.

[13] 胡海濤，劉穎. 一種基于DSL的服務(wù)組合語言[J]. 計算機(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。鞠煒剛，工程師，主研領(lǐng)域：軟件測試，自動化測試。胡繼東，工程師。

TP3

A

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