基于領域驅動的測試用例設計開發方法研究

胡繼東，鞠煒剛

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

基于領域驅動的測試用例設計開發方法研究

胡繼東，鞠煒剛

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

隨著軟件產品的交付周期越來越短，敏捷研發模式的應用范圍更加廣泛。為解決敏捷團隊中測試用例設計、開發不能滿足產品持續快速交付的問題，采用領域驅動方法，從需求特性出發，采用實例化需求的方法設計測試用例，然后對被測領域進行建模，通過領域關鍵字結構模型分析用領域語言描述測試用例，對領域對象模型進行分析，采用面向對象設計、開發，通過不斷演進和重構，迭代地完成測試用例的開發。一方面使得測試用例的組織、設計、開發更加有效，提高了測試用例的開發和維護效率，測試用例更加易于理解、清晰簡潔，能夠通過重構快速應對變化;另一方面可以采用ATTD的方法來驅動產品的開發。該方法在通信系統測試中得到了應用推廣，取得了很好的效果。

測試用例;領域驅動;實例化需求;領域建模;面向對象;重構

0 引言

隨著市場競爭的加劇，軟件產品需要高質量的持續快速交付，越來越多的團隊采用敏捷［1］研發模式取得了不錯的效果，但隨著軟件產品的需求特性越來越復雜，傳統的測試用例設計、開發方法越來越不能適應敏捷的要求，需要采用新的技術和方法。

文中提出了一種基于領域驅動的測試用例設計開發方法，該方法不僅有助于提高敏捷測試的效率，同時也可以驅動產品的需求特性開發，繼而很好地滿足敏捷測試對持續快速質量的保證。

1 傳統測試用例設計開發

在敏捷研發模式中將測試進行前移，做到早發現、早解決故障，提高了效率;但測試用例設計、開發一直采用傳統方式［2］。

對于測試用例設計，在需求分析完成后才開始在迭代周期中進行，需求分析和測試設計間存在拋接，不能滿足快速測試的要求，也很難應對需求變化。

對于測試用例開發，用例腳本由復雜的流程和實現細節表示，存在以下問題:

(1)測試用例腳本細節眾多，編寫速度慢，效率低，可讀性差。

(2)一旦實現變化就需要修改所有相關用例腳本，不能快速應對變化。

針對上述測試設計、開發存在的問題，需要一種新的測試用例設計方法來解決，為此開發了基于領域驅動的測試用例設計方法，并在通信系統產品的測試中進行了有效應用。

2 基于領域驅動的測試用例設計開發

2.1 理念與實踐全景

基于領域驅動的測試用例設計、開發的理念與實踐全景圖如圖1所示。

全景圖縱向分為目標和理念以及方法、實踐、工具兩大部分，橫向分為測試用例設計和測試用例開發兩大階段。其目標是在產品持續快速交付過程中保證產品質量，其核心理念是需求和用例設計統一，由領域來驅動測試用例的設計和開發。為了達成目標，在核心理念的指導下，采用以下方法、實踐和工具:

(1)在測試用例設計階段，采用需求實例化方法。依次采用定系統、用戶目的分析、劃分場景和功能分析等技術實踐，使用基于思維導圖的工具進行具體設計，UML［3-4］作為輔助工具進行分析。

(2)在測試用例開發階段，采用領域建模和用例/關鍵字開發方法［5-6］。其中，領域建模采用領域關鍵字結構模型分析和領域對象模型分析兩個核心的分析方法;用例/關鍵字開發采用模型驅動設計、TDD［7］和面向對象等技術實踐。

(3)在測試用例設計和開發整個過程中，隨著需求特性的增加采用演進式設計，不斷進行重構和優化。結對是一個重要的技術實踐，在測試用例設計和開發過程中用戶、BA、測試SE、QA進行結對，測試建模專家全程參與。

2.2 實例化需求

實例化需求［8］是需求分析的一種方法，它的分析過程是以用例驅動、以場景為中心、迭代和增量的，并且采用聚焦“用戶目的”和“使用場景”的描述方式。

在傳統分析方式中，對需求過早的抽象導致有價值信息的丟失，可能會導致功能放大，方案過于復雜，不利于形成共識和傳遞，采用實例化方法后實例成為需求傳遞的橋梁，在規劃、開發和測試間形成統一語言，也是對有效性和正確性驗收的標準。

從測試角度來看，采用實例化需求，測試用例的設計可以和需求分析過程有效統一起來，一方面測試設計提前，需求實例直接就是驗收測試用例，另一方面可以很好地適應敏捷迭代中需求的變化。

2.3 領域建模

領域建模從測試系統的領域模型出發，從測試角度進行建模，逐步分析出領域的測試模型，是測試用例開發重要的基礎。

在建模時應通過研討發現領域模型的關鍵性概念和元素以及描述它們的通用語言，這種語言應該具有一致性，必須消除歧義和混亂，并且能夠清晰準確地交流［9-10］。

領域建模首先要從測試用例出發進行領域關鍵字結構模型分析，逐層分析出測試領域的關鍵字結構模型樹，然后在此基礎上逐步分析出領域對象模型，整個分析過程是演進式和不斷優化的。

2.4 演進式設計和重構

需求特性是不斷增長和變化的，測試用例設計和開發也需要進行演進式設計和重構［11］。其中，領域關鍵字結構模型樹是隨著測試用例的增加演進式生長的，而領域對象模型則隨著關鍵字結構模型樹的生長而演進，領域對象模型在建立時切勿大而全。

3 用實例化需求方法進行測試用例設計

采用實例化需求方法，測試設計提前，和需求分析融合，需求實例直接就是驗收測試用例，同時隨著迭代過程中需求發生變化，用例直接適應這種變化。實例化需求主要由用戶、BA、測試SE、QA一起結對完成，建模人員和DEV參與，在這個過程中用戶是領域專家。實例化需求的基本流程如圖2所示。

需求是用戶為解決問題或達成業務目標，要求系統提供的功能或滿足的非功能性約束。需求有三個重要因素:用戶目的、系統(承接者)和功能要求。因此需求實例化基本流程也是圍繞這三個要素展開，依次是定系統、用戶目的分析(找用戶、問目的)、功能要求分析(畫場景、設功能)，其中在功能要求分析中要確定驗收準則和用戶接口定義。

3.1 定系統

實例化需求的第一步是定系統。首先用戶介紹背景，包括要解決的基本問題和達成的總體業務目標，然后結對繪制系統架構，包括物理實體關系和邏輯結構以及新舊差異。然后劃定系統邊界，這里系統邊界是指能力邊界而非物理邊界，即待開發、測試的系統，并達成一致共識。

3.2 用戶目的分析

實例化需求的第二步是用戶目的分析，分為找用戶和問目的兩個步驟。

首先是找用戶，用戶是外部使用系統的角色，具有以下三個重要特征:

(1)系統之外通過系統邊界與系統進行有意義交互的任何事物，可以是人、設備和系統;

(2)是系統行為和流程的觸發者; (3)必須是直接使用系統的用戶。

對于一些系統可以用干系人法直接找到用戶，對于較復雜的新領域系統，找用戶可以采用流程法，畫出各種業務流程，從流程中尋找相關的用戶，從用戶角度來畫，通過外部交互體現輸入、輸出。

然后是問目的，可以從Want(表象)、Need(背后的動機和訴求)，由淺及深兩個層次來探尋用戶目的。其中Want層次目的不少是易變化的，可能是以解決方案形式呈現的，需要通過挖掘探尋來理解Need層次背后的動機和訴求。

尋找目的可以從業務目的、管理目的和維護目的三個維度進行，其中業務目的是關注業務目標本身，管理目的是關注業務目標達成的過程，而維護目的則關注的是業務目標的過程評估與監控。對每個維度又可以從關注點和擔憂點兩個角度來分析，關注點是希望通過系統解決的問題，而擔憂點是擔憂系統會帶來的影響，避免出現的問題。

3.3 場景功能分析

實例化需求的第二步是場景功能分析，又分為畫場景和設功能兩個步驟。

(1)畫場景。

針對已分析用戶的每個目的進行場景分析，畫出各種場景，可以根據不同的業務特點采用不同形式，如時序圖、活動圖、數據流圖等。獲得基本場景后再根據變化和挑戰，從橫向和縱向兩個方面來擴展新的場景，對于變化一般主要有:時間、地點和周邊的變化;對于挑戰一般有:困難、業務變化、系統異常和威脅等;此外還可以從上下游、協作等角度來擴充場景。

(2)設功能。

針對每一個場景進行深度遍歷，逐步細化功能點，完成需求實例并給出相應的驗收條件，同時也完成了測試用例設計。可以采用思維導圖工具來對測試用例全景圖進行描述。

4 用領域建模方法進行測試用例開發

在使用實例化需求方法完成測試用例設計后，就可以用領域建模方法進行測試用例開發了，主要步驟是:領域關鍵字結構模型分析、領域對象模型分析、面向對象設計和開發，在完成測試用例開發的同時，還可以應用ATTD方法來驅動產品開發。

4.1 領域關鍵字結構模型分析

領域關鍵字結構模型分析由建模人員、DEV、測試SE、QA來一起結對研討完成，建模人員進行引導，可以從核心測試用例出發，逐步分析出領域的關鍵字結構模型樹，具體方法如下:

(1)初始化領域關鍵字結構樹。

首先對最核心的測試用例進行分析，分層次生成一棵關鍵字結構模型樹。從用戶角度出發，描述第一層次的領域關鍵字步驟，這里采用自然語言的方式，用通用語言來描述，需要注意的是關鍵字是從做什么的角度來描述，而不考慮實現細節，采用對象+動作的方式，第一層次從大的步驟方面來描述，不考慮細節。然后對第一層次的各領域關鍵字根據需要再進行分解拆分，形成第二層次的領域關鍵字，逐層展開，一直到最底層節點，如果一個節點的領域關鍵字可以使用基礎設施來完成，就不用再分解展開了。

(2)擴展領域關鍵字結構樹。

根據核心測試用例初始化領域關鍵字結構樹后，再按優先級對其他測試用例進行逐步分析，根據需要在已有關鍵字結構模型樹上進行擴展。對于測試用例還是先分析出第一層次的領域關鍵字，然后逐層展開，對于已經在領域關鍵字結構模型樹中存在的關鍵字，則直接使用，對于不存在的領域關鍵字，則需要加入關鍵字結構模型樹，并進行分層展開分析。

通過對各個測試用例的逐個分析，最終生成一棵全領域的關鍵字結構模型樹，由兩個測試用例生成的模型樹如圖3所示。

整個分析過程是由測試用例來驅動的，是演進式逐步迭代完成的。在開發過程中，可以直接在Robot-Framework工具上寫測試用例，將測試用例用領域關鍵字逐層進行組織，然后一步步驅動實現。在領域關鍵字拆分方面還需要遵循兩個基本原則:領域關鍵字一定是語義明確、清晰的;領域關鍵字是具有一定可復用性的［12］。

對于領域關鍵字結構模型分析有以下關鍵技巧:

①向上整合和向下細化。關鍵字結構模型樹可以根據需要進行向上整合和向下細化，形成更高層次和更低層次的領域關鍵字，高層關鍵字提供易用性，而低層關鍵字提供靈活性，通過關鍵字結構模型樹可以輕松進行。

②修剪。隨著領域建模的深入，對關鍵字結構模型樹需要進行修剪，刪除一些可能重復的關鍵字，對于一些幾乎只在一處使用的關鍵字也可以根據需要進行裁剪。

采用領域關鍵字結構模型樹分析方法后，可以將各節點的關鍵字落實到相關開發人員進行狀態跟蹤，同時對關鍵字的開發、組裝、聯調提供了良好的視圖。

4.2 領域對象模型分析

在完成領域關鍵字結構模型分析之后可以進行領域對象模型分析，這一步由建模人員、DEV結對完成。領域對象模型是基于領域關鍵字結構模型樹進行分析的，目標是分析出實現關鍵字結構模型的領域對象模型，為后續的領域關鍵字實現提供依據，具體的分析方法如下:

(1)識別領域對象。

從領域關鍵字結構模型的根節點出發對結構樹進行遍歷，一般按層次遍歷，不考慮細節。首先從領域關鍵字中逐層挖掘出核心的領域對象，由于是按層次遍歷，一般是先識別出高層次的領域對象，然后是低層次的領域對象。

(2)識別對象的關鍵行為、屬性和關系。

再次層次遍歷，分析每個領域關鍵字的動作行為，從中發現相應領域對象需要提供的核心方法和屬性，同時需要分析本領域對象和其他領域對象之間的相互關系，這包括了關聯關系、聚合關系、組合關系、依賴關系、繼承關系等。

(3)分析領域對象的交互。

對第一層的每個關鍵字進行逐層展開，直到最底層，通過對業務流程細節的分析，分析領域關鍵字如何通過現有對象模型的領域對象相互交互協作來實現其功能，如果有必要，還需要引入一些新增對象(領域對象或輔助對象)或者在已有對象上增加行為、屬性來實現。

4.3 模型驅動設計和面向對象開發

在領域對象模型分析時，采用模型驅動設計方法，將模型和設計緊密聯系，進行綁定，不再分離，在一起共同迭代。模型驅動設計應遵循以下原則:

(1)模型是設計的基礎，應支持有效的設計，否則模型將不實用，設計就可能脫離模型，模型和設計漸行漸遠;

(2)設計應該反映領域模型;

(3)設計過程中總會發現一些關鍵的知識點和細節，需要反饋補充模型;

(4)模型驅動設計，并不是考慮純粹的技術細節，不能因技術問題削弱模型。

采用面向對象設計可以有效地將領域模型映射為實現對象，同時可以采用面向對象設計的一些原則，使用一些設計模式，達到優化設計的目的［13-15］。

4.4 應用ATTD驅動產品開發

根據ATTD的思想，從驗收測試用例驅動產品開發，主要采用以下步驟:

(1)在詳細的迭代計劃會議之前，在需求研討會上討論需求特性，用需求實例化方法將需求特性用驗收測試用例表示;

(2)實現測試用例/產品需求的任務分別在詳細的迭代計劃會議上創建，并在迭代中并行開發實現，所有的活動幾乎同時開展，包括測試領域和產品領域并行建模，測試用例和產品需求并行開發、測試等;

(3)通過驗收測試在迭代演示會議上交付驗收并討論。

5 應用實例

在測試某產品需求特性“QoS策略控制專用承載”時，采用了基于領域驅動的測試用例設計開發方法。首先采用需求實例化方法進行測試用例設計，用思維導圖畫出測試用例全景，如圖4所示，這里僅畫出最核心的部分。

如圖4所示，QoS策略控制專用承載是需求特性，分為網絡和用戶發起控制兩大場景，其中網絡發起的又分為承載建立和修改兩大子場景，在網絡發起的專用承載建立子場景中，又分為采用QoS策略1和策略2兩個功能，分別對應兩個測試用例，進一步可以描述其驗收條件。

接下來從核心測試用例出發逐步分析出領域關鍵字結構模型樹，以圖4中的2個測試用例為例，領域關鍵字結構模型樹如圖5所示。

從上述領域關鍵字結構模型樹出發，分析出領域對象模型，并采用面向對象方法進行了實現，迭代完成了需求特性所有測試用例的開發，并驅動了QoS策略控制專用承載需求特性的開發，及時有效地進行了驗收。而且在迭代過程中能夠快速適應需求的變化和接口命令的調整，持續快速地保證了需求特性的高質量交付，比采用傳統方法整個交付周期縮短了近二分之一，質量提升明顯。

6 結束語

基于領域驅動的測試用例設計、開發方法是一種通用方法，在產品需求階段用需求實例化方法進行需求分析的同時完成測試用例設計，在迭代周期中根據產品需求特性開發的優先級，從相應的測試用例出發進行測試領域建模，逐步演進式地完成測試用例和領域關鍵字的開發，并同時驅動產品需求的開發，進行驗收測試，很好地滿足了敏捷測試對持續快速質量保證的要求。

未來可以從測試領域建模和產品需求領域建模的結合方面繼續進行一些探索和研究。

［1］ 陳國棟，羅省賢.Scrum敏捷軟件開發方法實踐中的改進和應用［J］.計算機技術與發展，2011，21(12):97-99.

［2］ 郭 群.軟件測試設計技術［J］.電腦知識與技術:學術交流，2007(9):1323-1324.

［3］ Roff J T.UML a beginner’s guide［M］.張 瑜，譯.北京:清華大學出版社，2003:9-13.

［4］ 冀振燕.UML系統分析設計與應用案例［M］.北京:人民郵電出版社，2003.

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

［6］ 馮玉才，唐 艷，周 淳.關鍵字驅動自動化測試的原理和實現［J］.計算機應用，2004，24(8):140-142.

［7］ Beck K.Test-driven development by example［M］.Upper Saddle River:Addison Wesley，2003:95-128.

［8］ Adzic G.實例化需求［M］.北京:人民郵電出版社，2012.

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

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

［11］付友濤，許林英.軟件工程新方法-軟件重構［J］.微型機與應用，2003，22(10):4-6.

［12］Sametinger J.Software engineering with reusable components ［M］.Berlin，Germany:Springer-Verlag，1997.

［13］邵維忠，楊芙清.面向對象的系統設計［M］.北京:清華大學出版社，2003:160-174.

［14］Szysperski C.Component software:beyond object-oriented programming［M］.［s.l.］:Addison Wesley，2002.

［15］屈喜龍.UML及面向對象的分析與設計的研究［J］.計算機應用研究，2005，22(9):74-76.

Research on Test Cases Design and Development Method Based on Domain-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 agile R＆D mode becomes wider.In order to solve the problem that test case design and development in agile teams cannot satisfy the requirement of constant rapid product delivery，the domain-driven method is adopted，and test case is designed based on feature requirements by using instantiation.Then the test domains is modeled，and test cases is described in domain language by using the domain keyword structure，and domain object model is analyzed，using design and development of object-oriented mode for implementing test cases in iterations via continuous evolution and refactoring.On the one hand，this method makes organization，design and development of test cases more efficient，thus improving efficiency in development and maintenance of test cases，and test cases become easy to understand，clear and concise，which satisfy quick changes requirements by using restructuring.On the other hand，it allows driving product development by using ATTD method.Thus，it is widely deployed in telecommunication system tests with good results.

test case;domain driven;specification by example;domain modeling;object-oriented;restructuring

TP301

A

1673-629X(2016)09-0056-05

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

2015-10-06< class="emphasis_bold">修回日期:2

2016-02-24< class="emphasis_bold">網絡出版時間:

時間:2016-08-23

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

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

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