基于領域驅動的自動化測試框架研究與應用

胡繼東，鞠煒剛

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

基于領域驅動的自動化測試框架研究與應用

胡繼東，鞠煒剛

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

隨著軟件產品的交付周期越來越短，自動化測試的應用范圍更加廣泛。為解決自動化測試用例編寫維護復雜、效率低下的問題，在傳統測試框架的基礎上提出了一種基于領域驅動的自動化測試框架。用領域語言來描述測試用例，對被測領域進行領域建模，以組件化思想為指導，采用分層架構，用面向對象方法設計、開發了領域測試庫，同時提出了領域驅動測試的實施流程，包括啟動、建模、設計、開發、測試、版本管理和發布的過程、方法。通過采用領域驅動測試框架可以使得測試用例的組織、設計和開發更加有效，提高了測試用例的開發和維護效率，測試用例更加易于解性、清晰簡潔，能夠通過重構快速應對變化，在通信系統測試中得到了應用推廣，取得了很好的效果。

領域驅動；自動化測試；領域建模；組件化；分層架構

0 引 言

軟件測試在軟件生命周期中占有十分重要的地位，是保障軟件質量的重要手段，因此必須不斷地對軟件進行測試[1]。隨著市場競爭的加劇，軟件產品的交付周期越來越短，采用純手工測試的方法越來越不能滿足需要，因此通過自動化測試，提高軟件測試的質量和效率，縮短軟件的交付周期。但隨著軟件產品的規模和復雜度越來越高，測試腳本的編寫越來越復雜，不能滿足自動化測試的要求，需要采用新的技術和方法[2-3]。文中提出了一種基于領域驅動的自動化測試思想，在此基礎上設計開發了自動化測試框架，以更好地完成對軟件產品的自動化測試。

1 傳統測試框架

隨著自動化測試的應用范圍越來越廣，測試用例規模越來越大，復雜度越來越高，需要有相適應的自動化測試框架來支持。在傳統測試框架中，測試用例腳本由復雜的流程和實現細節描述，直接提供給測試工具執行，對被測系統進行測試[4-5]。其中測試工具是定制化的工具，測試用例腳本必須采用工具所能支持的格式來編寫，不具有通用性。由于涉及具體的流程和測試實現細節，存在以下問題：

(1)測試用例腳本細節眾多，編寫速度慢，效率低；

(2)測試用例的編寫有大量的拷貝粘貼，不符合編碼規范；

(3)一旦接口實現變化就需要修改所有相關的測試用例腳本，可維護性差；

(4)耦合度高，用例整合耗費大量精力。

這些問題導致測試用例腳本編寫維護的成本很高，速度慢，同時腳本不容易理解，給測試人員使用帶來了極大的不便。一般的關鍵字驅動框架雖然解決了部分問題，但缺乏有效的方法從測試領域出發來解決關鍵字的設計、組織難題，需要有一種新的自動化測試框架和方法來解決這些問題。為此文中研究設計了基于領域驅動的自動化測試框架，并在通信系統產品的測試中進行了有效的應用。

2 領域驅動測試概述

2.1 領域驅動測試定義

領域驅動測試就是用一種高層的領域語言來描述測試用例，在一種通用的框架調度下驅動領域測試關鍵字庫，直接驅動測試引擎發起測試的方法。

領域驅動測試是在關鍵字驅動測試的基礎上發展而來的[6-7]，其主要特點是從被測系統的領域模型出發，從測試角度進行領域建模，并通過分層設計對測試用例和領域關鍵字進行有效的分析、設計、開發和組織管理，從而可以有效地對被測系統進行測試。

2.2 領域驅動測試優點

領域驅動測試主要具備以下優點：

(1)測試用例用領域語言描述，更加清晰、簡潔、易于理解；

(2)測試用例可以通過組合領域關鍵字和參數來設置；

(3)當實現方式發生變化時，可以通過更新升級領域驅動測試庫來應對，測試用例不需要做任何修改；

(4)針對敏捷測試變化的需求，重構領域測試模型和用例，適應變化。

3 基于領域驅動的自動化測試框架

3.1 系統框架

改進后的基于領域驅動的自動化測試框架如圖1所示。

圖1 領域驅動測試系統框架

在基于領域驅動的自動化測試框架中，測試用例腳本由高層的領域語言描述，提供給一個通用的測試驅動框架。該框架進行調度執行，調用領域驅動測試庫中的相關高層領域測試關鍵字，直接驅動測試工具引擎發起測試。采用高層領域語言描述用例的一個好處是測試用例腳本清晰、簡潔、易于理解，并可以快速編寫、修改和維護。從改進前后的測試框架原理來看，實質是采用了組件化的思想和分層架構，下面進行詳細闡述。

3.2 組件化思想

基于領域驅動的自動化測試框架的測試用例腳本結構如圖2所示。

圖2 組件化的測試用例腳本結構

圖2中的各測試組件為領域驅動測試庫中的相應領域測試關鍵字。測試用例腳本由高層的領域語言和領域驅動測試庫構成，具體的測試用例腳本通過測試庫的領域測試關鍵字組合而成，可以有順序、選擇和循環三種組合關系。組件化帶來的好處是增強了測試腳本代碼的可復用性，減少了重復和冗余，同時測試人員使用領域測試關鍵字組裝測試用例腳本，也易于理解，編寫簡單[8]。

3.3 分層架構

測試用例腳本由高層領域關鍵字組成，領域測試關鍵字庫的設計采用了分層架構，以某產品的測試為例，如圖3所示。

圖3 分層架構

測試人員在表示層編寫測試用例，測試用例由服務層不同測試服務提供的高層領域關鍵字組合而成；領域驅動測試庫則由服務層、領域層和基礎設施層構成，層次清晰。

其中服務層對外提供高層領域測試接口，對內協調驅動領域層測試對象交互協作完成測試。服務層一般根據不同的業務范圍劃分為多個測試服務，每個測試服務提供一系列的高層領域測試關鍵字。例如，承載測試服務提供了建立承載、釋放承載等測試接口。

領域層提供了一系列領域對象，主要包括各種測試角色和測試對象。其中測試角色實現具體的業務測試邏輯，通過相互交互協作完成測試；測試對象則在不同的測試場景中扮演不同的角色。

基礎設施層提供了對被測設備控制以及文件、網絡、異常等基礎設施。

采用表示層、服務層、領域層和基礎設施層的分層架構[9]，測試用例腳本和測試庫結構清晰，明顯優于扁平化結構，更有利于測試用例腳本和領域關鍵字庫的組織管理。

3.4 領域建模和設計

基于領域驅動的自動化測試框架的一個重要核心思想是采用領域建模和面向對象的設計。其主要特點是從被測系統的領域模型出發，從測試角度進行領域建模，并使用面向對象方法進行設計[10-11]。

其中，建立領域模型需要根據需求的變化和理解的深入不斷進行重構。采用面向對象設計可以很有效地將領域模型映射為實現對象，同時可以采用面向對象設計的一些原則，甚至可以使用一些設計模式，來達到優化設計的目的[12-13]。

4 實施流程

領域驅動測試的實施流程分為啟動、領域建模、設計、開發和測試、版本管理和發布這五大步驟，下面介紹每一步驟的實施方法。

4.1 啟 動

在啟動階段主要評估領域驅動測試實施的必要性，如果至少具有以下因素之一，則因素越多采用基于領域驅動的自動化測試框架的必要性越大：

(1)測試用例編寫太復雜，效率低下；

(2)測試用例的測試邏輯和參數需要補充豐富；

(3)新版本跨度較大，測試用例需要大量重新修改、整合、裁剪；

(4)協議升級導致測試用例大量細節要修改；

(5)被測業務領域復雜、規模較大，可預期的需求變化多。

以某產品測試為例，確定實施領域為某產品網元業務測試。由于某產品用例編寫復雜，需要通過組合和參數豐富化用例，而且版本升級后用例大量需要重新修改、整合、裁剪，具有實施的必要性。

4.2 領域建模

領域建模主要采用以下方法進行：首先是確定范圍，然后使用通用語言進行交流，對領域的業務、功能進行交流，從核心業務開始，逐步進行，通過進一步對信息進行組織和抽象，建立領域模型，需要不斷進行重構。

以某產品為例，首先確定了實施領域為業務測試,確定了被測對象為A網元、發起測試的對象為B網元以及測試的業務范圍。通過和領域專家的交流，從核心業務承載控制開始，逐步梳理了SDP、終端操作等業務，發現了領域模型的關鍵性概念和元素，形成了通用語言。通過將A網元的領域知識進行組織，分而治之，劃分為承載測試、終端操作測試、SDP測試等幾個主要的范圍。劃分的原則是高類聚、低偶合。通過領域建模建立了A網元的領域測試模型，如圖4所示。

圖4 領域模型

模型中一共有3個測試服務，分別是承載測試服務、終端操作測試服務、SDP測試服務。分別提供了各自的高層領域測試服務，如承載測試服務提供了承載建立和承載釋放測試服務。

各測試服務由相應的測試角色交互協作提供測試服務，圖中測試角色用圓表示，例如承載測試服務由承載測試角色提供測試服務，測試對象是終端，圖中用橢圓表示。測試對象在不同的測試場景中充當不同的測試角色。

4.3 面向對象設計

采用面向對象方法進行設計，將模型映射到對象。由于SDP測試場景類和終端操作測試場景類可以繼承承載測試場景類，而SDP測試角色類和終端操作測試角色類可以繼承承載測試角色類，通過簡化設計，UML類圖如圖5所示[14-15]。

圖5 UML類圖

4.4 開發和測試

4.4.1 測試庫平臺

領域建模和面向對象設計完成后，用python對領域驅動測試庫進行了開發，測試庫平臺結構如圖6所示。

圖6 測試庫平臺結構

其中TestCompLib提供了一個可擴展的領域驅動測試庫通用平臺。其中的common部分則是整個測試庫平臺的公共基礎部分，提供測試用例集、測試用例、測試方法、測試引擎、異常日志等基類接口和公共實現。A是TestCompLib中的一個具體領域的測試庫，代表一個被測領域A。A中的TestService包括了A測試領域的各種測試服務類的定義和實現，提供各種領域測試服務，例如實現了承載測試服務(class BearTestService)及其提供的承載建立和承載釋放測試服務(def EstablishBear和def ReleaseBear)。A中的TestDomain則包括了A測試領域的各種測試對象和測試角色類的定義和實現。A中的common部分繼承自TestCompLib中的common，是A測試庫的公共基礎部分的具體實現。

4.4.2 TDD

領域驅動測試庫的服務層是根據測試場景劃分的，每個測試場景又提供高層領域測試服務接口，很自然地適用TDD。為此，針對測試庫的各測試場景設計編寫了TDD測試驅動用例，并同步設計相應的領域測試服務接口，進行測試、開發的反復迭代，最終完成了領域測試服務的實現并通過了測試，有力保障了領域測試庫的質量。

4.5 版本管理和發布

使用領域驅動測試后，測試用例采用代碼的方式進行版本管理和發布，原則是測試庫隨項目大版本發布給測試用例編寫和執行人員使用。主要采用如下方法：

(1)上層測試用例采用高層領域語言編寫，一般不會變化，但為了便于管理，按項目版本拉分支；

(2)領域測試驅動庫屬于實現層，是對具體測試的封裝，不同版本的具體測試實現可能會有差異，因此按照項目大版本拉分支；

(3)編寫測試用例時，使用對應版本分支的測試庫；

(4)對項目版本測試執行時，使用對應版本的測試用例和測試庫組合。

5 應用實例

5.1 應用情況

在產品A測試中，給測試人員提供了一個A領域驅動測試庫，并進行了實際應用，下面對應用方法和結果進行介紹。

測試人員使用領域驅動測試庫提供的領域測試關鍵字來描述編寫測試用例腳本，一般按以下步驟進行：

(1)分析測試用例涉及的測試場景；

(2)對每個測試場景分析測試行為，可以分別由哪些領域測試服務提供；

(3)從領域測試庫相應的場景庫中取對應的領域測試關鍵字來描述；

(4)組合多種領域測試關鍵字，設置不同參數，完成測試用例腳本。

以下面測試用例為例子說明：主叫IuRtp承載，被叫ARtp承載，呼叫建立后對主叫播放bcg/bwt包音，停音后釋放呼叫。

該用例涉及兩個測試服務：承載測試服務、放音測試服務。其中承載測試服務包括承載建立、承載釋放測試服務，分別對應領域測試關鍵字EstablishBear、ReleaseBear；放音測試服務包括放音、停音測試，分別對應領域測試關鍵字PlayTone、StopTone。對相關測試角色設置不同參數，組合多種領域測試關鍵字，完成后的測試用例腳本用高層領域關鍵字組合而成，如下所示：

主叫IuRtp承載，被叫ARtp承載，播放bcg/bwt包音

${termT1} SetTestTerm C1 T1

${termT2} SetTestTerm C1 T2

${BearTermT1} ActBearTestRole${termT1}IuRtp${offi-ce0}${IpAddr}

${BearTermT2} ActBearTestRole${termT2}ARtp${offi-ce0}${IpAddr}

${PlayToneT1} ActPlayToneRole${termT1}${office0}bcgbwt

EstablishBear ${BearTermT1}

EstablishBear ${BearTermT2}

PlayTone ${PlayToneT1}

StopTone ${PlayToneT1}

ReleaseBear ${BearTermT1}

ReleaseBear ${BearTermT2}

5.2 效果評價

使用基于領域驅動的自動化測試框架取得了較好的效果，主要有以下幾點：

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

(2)協議或版本升級只需要修改測試庫，用例不需要任何修改，維護方便；

(3)測試用例可以通過組合關鍵字和設置參數輕松擴展。

使用基于領域驅動的自動化測試框架前后代碼靜態統計結果對比如表1所示。

表1 代碼靜態統計結果

6 結束語

基于領域驅動的自動化測試框架應用范圍很廣，在不同的行業領域都可以應用。在新產品研發過程中，在產品需求階段就可以同步考慮對測試領域的建模，然后設計、開發相應的領域驅動測試庫來提供測試服務，構建測試用例腳本，從而采用ATTD的方法來驅動產品的開發。這種理念可以用于新功能特性的自動化用例腳本的設計開發。

未來應該向測試領域建模方法和專項領域的測試框架和模型設計兩個方向來繼續探索研究和積累實際應用經驗。

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

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

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

[4] 崔紅軍，饒若楠,邵培南.一種API自動化測試工具的設計與實現[J].計算機工程,2007,33(4):270-271.

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

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

[7] 候 勇.關鍵字驅動的自動化測試系統的研究[D].西安:西安電子科技大學,2009.

[8] Sametinger J．Software enginering with reusable companents[M].Berlin，Germany：Springer-Verlag,1997.

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

[10] 易利濤,周肆清,丁長松.信息抽取中領域本體建模方法研究[J].計算機技術與發展,2011,21(10):23-27.

[11] Boggs W,Boggs M.Mastering rational XDE[M].邱仲潘,譯.北京:電子工業出版社,2003.

[12] 邵維忠,楊芙清.面向對象的系統設計[M].北京:清華大學出版社,2003:160-174.

[13] Szysperski C． Component software：beyond object-oriented programming[M]．[s.l.]：Addison Wesley,2002．

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

[15] Roff J T.UML a beginner’s guide[M].張 瑜,譯.北京:清華大學出版社,2003:9-13.

Research and Application of Automation Testing Framework Based on Field-driven

HU Ji-dong,JU Wei-gang

(ZTE Nanjing Institute,Nanjing 210012,China)

As the delivery period of software products becomes shorter,the application scope of automation test becomes wider.In order to solve the problem of low efficiency and complexity in writing and maintaining automation test cases,an automation test framework is put forward based on domain-driven on the existing traditional test framework.The new framework describes test cases in domain language,creates model to the tested domain,guides design with the idea of modularization,adopts layered architecture,and designs and develops domain test library by using ODD.At the same time,the implementation procedure of domain-driven test is raised,which includes process and method of starting,modeling,design,development,test,version management and publishing.By adopting the domain-driven test framework,the system makes organization,design and development of test cases more efficient,and thus improves efficiency in development and maintenance of test cases.In this case,test cases become easy to understand,clear and concise,and satisfy quick changes requirements by using restructuring.Thus,the framework is widely deployed in telecommunication system tests and has achieved good results.

domain driven;automated test;domain modeling;modularization;layered architecture

2015-07-12

2015-10-16

時間：2016-03-22

國家自然科學基金資助項目(61402482)

胡繼東(1979-)，男，碩士研究生，工程師，研究方向為軟件測試、敏捷測試。

http://www.cnki.net/kcms/detail/61.1450.TP.20160322.1521.066.html

TP31

A

1673-629X(2016)04-0162-05

10.3969/j.issn.1673-629X.2016.04.036