基于领域驱动的测试用例设计开发方法研究

胡继东，鞠炜刚

(中兴通讯南京研究所，江苏南京 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