基于活动图的回归测试方法研究硕士毕业论文(DOC 74页).doc

1、. . . . 基于活动图的回归测试研究摘要随着信息技术的深入发展，社会的各个领域的信息电子化进程进行的非常迅速。许多系统都是非常复杂和庞大的，而且更新换代的速度非常惊人。那么怎么保证这些系统是高效、安全、可靠的，软件的回归测试是非常必要的。但是回归测试是一个成本昂贵的过程。而在回归测试中回归测试用例的选择是最重要的一个步骤，如何选择一个尽可能小并且又能覆盖所有改变和影响的测试用例集来进行回归测试用例选择是一个重要的课题。本文对回归测试选择方法进行了研究，提出了基于UML活动图的回归测试用例选择技术和基于风险的回归测试选择技术。这两个技术是相辅相成的，能很好地完成回归测试用例的选择。主要研究容

2、与成果包括以下几个方面：1）分析了需求的可跟踪性对于进行和管理回归分析和测试的重要性。2）提出了一个基于活动图的回归测试选择策略，用来选择回归测试用例。将需求里的功能特征一一对应到活动图上，再通过活动图很直观地进行测试用例的选择。3）分析和描述了在回归测试中的风险分析，同时提供了风险敞口(Risk Exposure)作为度量回归测试用例集的质量的指标。提出了基于风险的回归测试选择技术，是基于活动图的回归选择技术的有益补充。4）用一个股票交易系统作为实验对象，验证了我们提出的方法的有效性，高效性。关键词：回归测试，风险敞口，活动图67 / 74AbstractAlong with the dee

3、ply development of information technology, lots of industrial and financial entities involve information technology into their daily business. Regression testing is essential to ensure software quality. A test team applies a regression test suite to ensure that new or modified features do not regres

4、s (make worse) existing features. Although existing research has addressed many related problems and put forward some solutions, most regression test techniques are code-based. Code-based regression test selection is good for unit testing, but it has a scalability problem. When the size of the objec

5、t under test grows, it becomes hard to manage all relevant Risk Exposure information and to create corresponding traceability matrices for validation and coverage assessment.We propose a method for regression test selection based on activity diagram and risk. There are two major parts of our work:1)

6、 We propose and justify a new regression test strategy based on activity diagram.2) We provide systematic methods for selecting regression test cases. We apply regression analysis to requirement to check throughout consistency of “requirement followed by a blank”, and design models. The basic model

7、we use for describing requirements based on customer features or behaviors is the activity diagram, which is a notation of the UML. A process is presented for identifying the test cases affected by changes. At the same time, we use risk analysis and present a method of choosing risk-based test cases

8、. Our risk analysis is based on a practical risk model, and is similar to that used by some organizations.Keywords：Regression test, Activity diagram, Risk exposure目录摘要iAbstractii第1章 绪论11.1 课题背景11.2 国外研究现状与进展21.2.1 以前相关研究21.2.2 现存理论存在的问题41.3 研究容和研究目标41.4 本文结构组织5第2章 回归测试62.1 引言62.2 回归分析和测试概念62.3 回归测试技

9、术62.4 回归分析的讨论72.5 回归测试模式92.6 软件维护的分类和回归测试的类型102.7 本章小结11第3章 方法1：基于活动图的回归测试133.1 引言133.2 需求的可追溯性133.3 UML的活动图143.3.1 活动图的元素163.3.2 活动图和测试用例关系213.3.3 简化复杂的活动图223.3.4 基于活动图设计测试用例233.4 建立基于活动图的需求可追溯性233.4.1 需求测试，设计测试和活动图263.4.2 跟踪测试用例到活动图元素273.5 基于活动图进行测试用例的选择303.5.1 纠正性维护中测试用例的选择303.5.2 基础：基于CFG的回归测试选择

10、技术313.5.3 基于活动图的回归测试选择343.5.4 纠正性和改进性维护同时发生时测试用例选择353.6 本章小结36第4章 风险和风险分析374.1 引言374.2 风险性测试374.3 风险分析374.4 风险分析活动384.5 一个实用的风险模型394.6 本章小结40第5章 方法2：基于风险的回归测试415.1 引言415.2 基于风险的回归测试方法415.3 基于风险的回归测试用例选择技术425.3.1 评估测试用例相对应的潜在的错误的成本(第1步)435.3.2 评估每个测试用例严重度(第2步)485.3.3 计算每个测试用例的风险敞口(第3步)495.3.4 选择测试用例作

11、为基于风险的测试用例505.4 本章总结51第6章 实验分析和比较526.1 引言526.2 实验设计526.3 实验结果和分析54第7章 结束语55参考文献56作者简历59致60图目录图 2.1回归测试技术7图 2.2 回归测试用例选择9图 3.1活动图例子20图 3.2 同步行为23图 3.3 一个取得汇率报价的模块的活动图24图 3.4 简化后的活动图25图 3.5 建立需求特征和测试用例之间的可跟踪的联系26图 3.6 需求特征和测试用例间的可跟踪性的联系链30图 3.7 取得报价的功能模块实施中发生错误和变化32图 3.8 控制流图C和改变后的C33图 3.9 图4-5中的活动图的改

12、变35图 4.1 风险分析活动39表目录表 3.1活动图的标识18表 3.2从图4-5得来的满足节点和边界覆盖标准的测试集25表 3.3测试用例和活动图元素28表 3.4对应测试用例的活动图的可跟踪性模型29表 3.5 CFG C的测试集T的edge覆盖模型34表 5.1一些测试用例的CC45表 5.2测试用例的CV值47表 5.3一些测试用例的成本48表 5.4测试用例的可能性严重度49表 5.5测试用例的风险敞口50表 5.6测试用例选择51表 6.1原始测试用例规模53表 6.2原始和补充测试用例的规模53表 6.3完全测试时测试用例和错误规模53表 6.4几种回归测试的实验数据54表

13、6.5几种回归测试的比较54第1章 绪论1.1 课题背景随着计算机技术、网络技术的不断发展，计算机应用的领域越来越广，软件系统功能越来越强大，其系统的规模也越来越大，越来越复杂。计算机已经普遍地应用在航空、航天、工业控制、金融、医疗、交通和电子商务等各个领域，这些软件系统的运行是否正确，已经影响到社会生活得各个方面。一旦这些软件失效，就会造成巨大的损失。尤其是这几年，电子商务与金融产品的网上交易平台等这些基于Web应用的系统的快速发展，软件产品的一点瑕疵就可能导致客户的巨额财产损失。软件测试就是减少这种损失，保证软件质量的重要手段。随着人们对软件测试的重要性的认识的不断加深，软件测试阶段在整个

14、软件开发周期中所占得比重会日益增大。根据Boehm的统计，目前软件测试在软件开发中的总成本中，其开销占到了30%50%1，在某些重大软件项目占得比重更大。回归测试是软件测试中一个很重要的环节。其目的是保证程序在修改后不会引入新的错误2。而随着软件规模的日益庞大，回归测试的成本也相应增大，甚至达到整个测试成本的一半以上3。所以回归测试成为整个软件测试的关键，是软件质量的重要保证。回归测试可以重用以前的测试过程，是一种比较有效地测试方法。但是，回归测试需要前期投入，如何减少回归测试的代价，是整个软件回归测试研究的难点和重点。在所有的难点和重点中，回归测试用例选择（Regression Test S

15、election）是重点中的重点。回归测试选择是复用已有用例基进行测试的方法。其目的是选择一个尽可能小并且又能覆盖所有改变和影响的代码的测试用例集。目前回归测试选择的研究，主要包括：1）基于代码信息的回归测试选择。该方法主要研究在已知代码的情况下，对代码相关的用例进行选择。2）基于历史记录的回归测试选择。该方法主要是根据测试的历史记录进行回归测试选择。统模语言（UML）在软件工程发展进程中具有里程碑的意义，统模语言（UML）的正式发展是从1994 年开始的，它汇集了近20 多年来各种建模技术。自提出以来，后成为研究热点，并且迅速在工业界得到广泛的应用。UML对开发高质量软件起了很大的促进作用，

16、同时也给软件测试以与回归测试带来新的研究领域。目前大多数回归用例选择技术多是基于代码的，有些是基于历史记录的。基于代码的回归测试选择对测试人员要求很高，需要测试人员阅读并理解代码，这需要很多的时间花费，并且是依赖于编程语言的。而基于历史记录的回归测试选择要求测试的所有记录非常完善，很多时候我们达不到要求。而基于UML设计的回归测试选择不依赖于编程语言，比代码级的回归测试选择更加容易且效率高。所以本文吸收前人的研究成果，结合UML活动图的特点，提出了基于UML活动图的回归测试选择技术，为了对软件质量更有信心，又提出了基于风险的回归测试选择技术，作为基于活动图的回归测试的有益补充。1.2 国外研究

17、现状与进展1.2.1 以前相关研究回归测试作为软件生命周期的一个组成部分，在整个软件测试过程中占有很大的工作量比重，软件开发的各个阶段都会进行多次回归测试。在渐进和快速迭代开发中，新版本的连续发布使回归测试进行的更加频繁，而在极端编程方法中，更是要求每天都进行若干次回归测试。许多研究人员研究了回归测试技术。他们的研究包含很广泛的课题。例如，Brown 和Hoffman8 研究了测试环境和自动化回归测试过程。Harrold，Gupta和Soffa9研究了测试用例管理技术。Rothermel和Harrold10 研究了回归测试选择技术。最近几年，大家的注意力被集中到回归测试测试用例选择领域。大部分

18、的技术是针对白盒测试的，他们选择测试用例是基于代码的相关信息11-12。只有少数的技术是针对黑盒测试，测试用例选择基于系统本身特征13-16。目前，回归测试选择的研究主要包括以下两个方面：1) 基于代码的回归测试选择。该方法主要研究在已知代码的情况下，对代码相关的测试用例进行选择。这个方法是通过比较修改前后对应代码对基线测试用例进行选择，从而得到回归测试用例集的一种技术28。先采用一些分解术将复杂的程序分解成一个个相对较小的片段来进行分析和维护。这些片段就叫做程序切片。任何一个程序都可以等价于一组程序切片的并集，而这些切片都是根据某个切片变量和切片准则计算出来的。根据切片的定义:所有能够影响到

19、的语句、谓词等都被包含到该切片变量的切片中了。所以对某个切片变量的修改一定不会影响到其他切片变量的切片。那么基于代码方法的回归测试思想可以描述如下: 针对修改后的程序，首先找出被修改的变量信息，然后运用切片方法找到由于这些变量的变化所引起的直接定义一使用关系和间接定义一使用关系(通常是一些语句或者控制流和数据流信息)，将这些信息提取出来，组成一个程序片段，设计测试用例对这些程序片段进行测试，最后把这些测试用例加人到原程序测试用例中，构成新的回归测试用例集。2) 基于历史记录的回归测试选择。就是以测试用例执行的历史记录数据为依据进行回归测试选择29。每一轮测试都有一个测试状态与之相对应，该测试状

20、态，该测试状态涵盖了当前测试中影响策略选择的因素，包括测试用例错误检测率要求、测试成本、测试频次。这些就是测试的历史信息。基于这些测试历史信息，并根据当前测试情况来选择较为合适的回归测试用例，再将生成的回归测试用例进行用例优先排序，最后利用排序后的用例来进行测试，以进一步提高回归测试效率。1.2.2 现存理论存在的问题对于基于代码的回归测试选择技术来说存在一些问题。基于代码的回归测试技术可以有效的应用到回归测试中的单元级别。但是当我们试图测试一个大的或更加复杂的组件，比如一个子系统，我们要用基于代码的回归测试技术从代码中取得所有所需信息就很困难，因此，基于代码的回归测试技术就很难适应较大的组件

21、的测试，例如子系统的测试。而且，基于代码的回归测试技术需要测试人员在一定程度上进入和理解代码17。这个需要就会产生一些实际的问题。测试人员不得不去花很多时间去读懂代码，而且对测试人员的要求会很高。这是很费时，高成本的方法。最后，基于代码的回归测试技术是有编程语言的限制。在一些软件系统里面，会使用超过一种的编程语言，比如，在Web系统里，我们可能会用到Java，JSP，HTML等语言。这会导致分析代码的过程非常复杂。同样的对于基于历史信息的回归测试选择技术也存在着一些问题。因为在这个选择过程中完全是根据测试的历史记录来进行的，那么就必定要求这个历史记录是完整，正确的。但是，实际情况是，很多项目的

22、测试历史记录是不完整的。1.3 研究容和研究目标在我们的研究中，我们提出采用基于活动图的回归测试选择技术和基于风险的回归测试选择技术，作为有效和高效的解决以上所列问题的途径。下面是本论文的主要工作：1) 我们说明了需求可追溯性对于进行和管理回归分析和测试的重要性。我们分析了在需求和测试用例之间的联系。2) 我们提供了一种新的选择回归测试用例的策略。我们的策略是基于活动图的。将需求里的功能特征一一对应到活动图上，再通过活动图很直观地进行测试用例的选择。3) 我们分析和描述了风险分析的用处，怎么使用风险敞口(RE)可以用来衡量回归测试集的质量。提供了基于风险的回归测试选择技术，作为基于活动图的回归

23、测试技术的有效补充。1.4 本文结构组织文章剩下部分组织结构如下：第二章：主要描述回归测试的背景知识，相关技术。第三章：讨论了建立基于活动图的需求可跟踪性的方法，在次基础上建立了对回归分析和选择技术。第四章：讨论了风险分析，给出一个实用的风险模式，可以在回归分析中使用。第五章：讨论了基于风险的回归测试策略，并使用例子说明。第六章：用一个实验来验证我们提出的回归测试方法。第七章：总结全文。第2章 回归测试2.1 引言Myers发现对已经存在的程序进行修改比整个系统重新进行编码更容易产生bug18。回归测试是被用来确认被修复的bug已经真正的被修复了，同时在这个过程中没有产生新的bug，系统的功能

24、还要符合需求的规定。2.2 回归分析和测试概念回归分析和测试是软件系统发生改变后的一个软件过程19。回归测试通常就是发生在被测试的系统发生改变时，原来的bug已经被完全修复，不会产生新的问题。回归测试和开发过程中的测试最主要的区别是回归测试的测试用例集会不断的重用。使用回归测试选择技术，我们仅仅重新运行被压缩过的回归测试用例，这些测试用例根据修改过的组件或系统而变化。如果选择测试用例的代价少于重新测试所有测试用例的代价，那就说明测试用例选择技术是经济有效的20。2.3 回归测试技术Rothermel和 Harrold 在自己的研究中描述回归测试技术如下所述9：程序P， 修改后的程序p，程序P的

25、测试用例集T，回归分析和测试技术就是让T的子集能满足程序P的质量要求，而从p到P的对应未改变部分功能不变。回归测试基本上包含下面几个步骤：1. 确定从P到P的改变的容2. 选择子集T T，T是基于P到P改变的测试集3. 用T测试P，确认P的正确性4. 如果需要，建立T，是关于P的新的功能的或架构的测试用例集5. 用T测试P，确认P的准确性6. 建立T，是P的回归测试集，结合了T和T。图2.1 回归测试技术2.4 回归分析的讨论对仅仅发生少量变化的软件系统进行完全的测试是很昂贵的行为，尤其是对于大型系统。利用回归分析和测试，我们可以仅仅重新测试受到影响到得那部分软件系统。回归分析和测试必须列出下

26、面的这些基本问题21：1. 怎么确定因为某些组件代码的改变而受到影响的所有组件？2. 要采取什么策略去重新测试这些受到影响的组件。3. 对于这些重新测试的组件的覆盖标准是什么？4. 怎么选择回归测试用例或改变原来的测试用例？为了解决上述问题，对于回归分析和测试策略，下列的行动是很重要的。下面是一个实用的回归测试策略：1. 确定被影响的组件和选择回归测试覆盖标准。2. 选择测试用例去测试被影响的组件。3. 执行选择好的测试用例。4. 获取和评估测试结果，包括评估发生改变的软件系统的运行情况，报告回归测试集的覆盖率。5. 修改测试计划以符合下一个阶段的回归分析和测试。第2点是关于选择测试用例去重新

27、执行的。这些被执行的测试用例可能会是新的测试用例，当然也会有选出来的适当的老的测试用例。在我们的研究当中，我们仅仅关注从原来的完整测试集中选择合适的测试用例的技术方法。Luiu将完整测试集中的测试用例分成两类19：1. 可以重新使用的测试用例：这些测试用例是用来测试没有更改部分的规格说明和相应未改变部分的执行。当规格说明和执行改变后，这些测试用例都保持有效性，不需要重新运行。2. 被影响到得测试用例：这些测试用例是同发生改变的那些规格说明和执行相关的。它们有两个分类：1) 可以重新测试的测试用例：这些测试用例是依然有效，应当被重新执行的。2) 过时的测试用例：这些测试用例对于发生改变的规格说明

28、和执行已经是不相关或已经过时了。测试用例选择过程图2-2所示。图2.2 回归测试用例选择2.5 回归测试模式Robert Binder总结当前的回归测试选择策略，分成三个模式7：1. 再测试全部用例：选择基线测试用例库中的全部测试用例组成回归测试包，这是一种比较安全的方法，再测试全部用例具有最低的遗漏回归错误的风险，但测试成本最高。全部再测试几乎可以应用到任何情况下，基本上不需要进行分析和重新开发，但是，随着开发工作的进展，测试用例不断增多，重复原先所有的测试将带来很大的工作量，往往超出了我们的预算和进度。2. 基于操作剖面选择测试：如果基线测试用例库的测试用例是基于软件操作剖面开发的，测试用

29、例的分布情况反映了系统的实际使用情况。回归测试所使用的测试用例个数可以由测试预算确定，回归测试可以优先选择那些针对最重要或最频繁使用功能的测试用例，释放和缓解最高级别的风险，有助于尽早发现那些对可靠性有最大影响的故障。这种方法可以在一个给定的预算下最有效的提高系统可靠性，但实施起来有一定的难度。3. 再测试修改的部分：当测试者对修改的局部化有足够的信心时，可以通过相依性分析识别软件的修改情况并分析修改的影响，将回归测试局限于被改变的模块和它的接口上。通常，一个回归错误一定涉与一个新的、修改的或删除的代码段。在允许的条件下，回归测试尽可能覆盖受到影响的部分。再测试全部用例的策略是最安全的策略，但

30、已经运行过许多次的回归测试不太可能揭示新的错误，而且很多时候，由于时间、人员、设备和经费的原因，不允许选择再测试全部用例的回归测试策略，此时，可以选择适当的策略进行缩减的回归测试。每种回归测试模式都有其优点和缺点。一种模式可能在某些情况下比另一种好，但是并不是在所有情况下都好。2.6 软件维护的分类和回归测试的类型在软件开发和维护阶段，当软件进行打补丁，升级或微调时，软件系统可能会发生许多变化。根据软件维护预期目的的不同，White 将软件维护分成三类22：1. 纠错性维护(Corrective maintenance)：纠错性维护是为诊断和改正软件系统中潜藏的错误而进行的活动。由于软件测试不

31、可能排除大型软件系统中所有的错误，测试阶段隐藏下来的软件错误，有可能在软件投入实际运行之后，才逐步暴露出来并造成系统故障。软件交付使用后，用户将成为新的测试人员，在使用过程中，一旦发现错误，他们会向开发人员报告并要求维护。2. 适应性维护(AdaptiveMaintenance)：适应性维护是为使软件系统适应不断变化的运行环境而进行修改的活动。一般应用软件的使用寿命很容易超过十年(比如，波音公司的CobolOSVS已经运行了22年)，但其运行环境却更新很快。近年来，硬件基本是一年半一代，操作系统的版本也在不断地更新，外部设备，外存储器和其他系统元素也频繁地升级和变化，因此为了使老的软件能够在新

32、的运行环境下正常工作，适应性维护是必须且经常发生的。3. 完善性维护(PerfectiveMaintenance): 完善性维护是根据用户在使用过程中提出的一些建设性意见而进行的维护活动。在一个应用软件成功运行期间，用户也可能请求增加新功能、建议修改已有功能或提出某些改进意见，以便使软件的功能和质量得到进一步的完善。软件的版本更新就是完善性维护的一种。完善性维护是软件维护的主要部分，通常占所有软件维护工作量的一半以上。在适应性维护和完善性维护阶段里，软件系统的变化是由于用户需求或者系统的规格说明的变化。经常是增加了新的功能。这两种维护中发生的变化同开发阶段发生的变化很类似。Leung 和 Wh

33、ite 称适应性维护和完善性维护都被认为是改进性的维护(Progressive Maintenance) 基于上面的分类，我们可以将回归测试分成两类：1. 纠错性回归测试：就是在纠错性维护后进行的回归测试，这时软件系统的需求规格说明没有发生变化。2. 改进性回归测试：就是在改进性维护后进行的回归测试，这时相应的需求规格说明已经发生变化。在论文里，我们的讨论主要针对这个分类展开。2.7 本章小结在这章中，我们提供了回归分析和测试的背景信息，列出了一般的回归测试模式。同时也将软件系统的改变，回归测试进行了分类。第3章 方法1：基于活动图的回归测试3.1 引言软件的规说明阶段(specificati

34、on phase)对于软件的整体开发过程来说是一个非常重要的阶段，UML方法是目前比较流行的软件工程开发方法，它对软件整体开发过程提供了一套有用的模型。在我们的研究中，我们使用UML中的活动图作为需求分析和设计的工具，尤其是作为工作流的标记。设计测试用例是基于活动图，这些活动图来自设计文档。我们的方法是基于项目文档，包括设计文档，系统变化的历史文档，测试执行的log记录。如果这些文档是不完全或不正确的，我们的方法不可能覆盖所有可能的变化。3.2 需求的可追溯性测试人员的任务是在产品中发现高优先级的问题。风险是问题可能发生的衡量。问题越可能发生，问题发生后的影响越大，那么风险级别越高。风险是所有

35、测试的动力所在。从某种意义上说，没有风险就没有测试，就像没有空气就没有生命一样。在第2章中，我们已经指出任何回归分析和测试策略中我们首先要做的是识别出受系统变化影响的组件。在纠正性维护中，我们可以通过哪些组件里的代码发生变化来识别哪些组件受到影响。对于改进性维护，因为系统的变化是因为需求或者是规说明的变化，我们需要明白需求，规说明和系统行为之间的联系，以识别受到影响的组件。然后，当在第一步中识别出哪些组件受到影响后，我们在第2步中选择测试这些组件的回归测试用例。要清楚这些组件和测试用例之间的联系。关于需求的可追溯性，简单的，普遍的观点是通过记账的方法，这可以防止很多问题7。需求的可追溯性是为了

36、找出因为需求变化受到影响的组件和选择出相应的测试用例的一个基本要求。“需求的可追溯性”这个专用名词最初是来自美国国防部。需求的可追溯性的一个普遍可以接受的定义是：描述和跟踪需求的整个生命的能力，包括向前的和向后的方向24。也就是说，可追溯性是这么一种能力：跟随需求从最原始状态，经过它们的规说明和开发，到产品的随后的开发和使用，再通过一段时间的不断完善，当然也包括在这些阶段中任何一个遍历过程。需求的可追溯性已经广泛被认为是有效的软件项目管理和软件质量保证的一个重要因素。在过去几年中，软件需求可追溯性的研究还是挺多的。许多可追溯性的模式被提了出来。根据Spanoudaki的说法25，需求的可追溯性

37、可以被用到：1. 协助验证系统满足需求的要求。2. 确认软件需求说明变化的影响。3. 记录和理解各种文档的变化过程。上面的需求的可追溯性的第2点用处刚好很好地满足我们的情况。我们用它来解决回归分析和测试的第一个问题：识别受到影响的组件。从用户需求到软件产品的第一个Release，一个软件开发过程通常包含四个主要阶段：需求分析，设计，实施，测试。结果是，系统的相关信息转化成不同的形式和在不同阶段的不同代码。我们使用UML的活动图区描述我们研究中的分析和设计模式。3.3 UML的活动图活动图是UML用于对系统的动态行为建模的一种常用工具。统模语言（UML是 Unified Modeling Lan

38、guage的缩写）是用来对软件密集系统进行可视化建模的一种语言。UML为面向对象开发系统的产品进行说明、可视化、和编制文档的一种标准语言。统模语言 (UML)是非专利的第三代建模和规约语言。 UML是在开发阶段，说明，可视化，构建和书写一个面向对象软件密集系统的制品的开放方法。UML展现了一系列最佳工程实践，这些最佳实践在对大规模，复杂系统进行建模方面,特别是在软件架构层次已经被验证有效。UML可以贯穿软件开发周期中的每一个阶段。被OMG采纳作为业界的标准。UML最适于数据建模，业务建模，对象建模，组件建模。UML作为一种模型语言，它使开发人员专注于建立产品的模型和结构，而不是选用什么程序语言

39、和算法实现。当模型建立之后，模型可以被UML工具转化成指定的程序语言代码。UML活动图是UML语言中描述系统动态行为的一种方法，它广泛地运用于业务建模。它描述活动的顺序，展现从一个活动到另一个活动的控制流。活动图在本质上是一种流程图。活动图的应用非常广泛，它既可以用来描述操作（类的方法）的行为，也可以描述用例和对象部的工作过程。活动图是由状态图变化而来的，他们各自用于不同的目的。活动图中一个活动结束后立即进入下一个活动。活动图用途与优缺点：活动图用于对系统的动态行为建模，它是系统行为状态的一种可视化形式。另一种可视化形式是状态图。活动图描述了从活动到活动的流，活动是状态机中进行的非原子操作。活

40、动图实际上是状态图的特殊形式，它的每个状态都有入口动作，用以说明进入该状态发生的操作。优点：最适合支持并行行为，而且也是支持多线程编程的有力工具。缺点：很难清楚地描述动作与对象之间的关系。活动图有很多作用：1. 分析用例：在项目中，我们需要理解什么行为会发生，按照什么顺序发生等等。2. 理解工作流：即使我们在深入了解用例前，我们可以协同商业专家画出活动图，理解业务流程与其如何变化的。3. 描述一个复杂的连续的运算法则4. 处理多线程应用：活动图有一系列的元素去描述多线程应用的系统行为。许多公司，比如IBM公司多年前就开始在系统设计中使用活动图。它是描述系统行为和工作流的很有力工具。许多研究人员

41、错误理解活动图的概念，觉得它仅仅就是一个控制流图(Control Flow Graph(CFG)。但是实际上，活动图不仅仅是控制流图。有如下两个原因：1. 活动图可以用来表达控制流和数据流，但是CFG仅仅可以用来表达控制流。2. 活动图可以用来表达大型系统，而CFG不能表达大型系统。在我们的研究中，我们使用活动图来详细描述系统的需求，以达到回归分析的目的。因为在面向对象开发过程中，需求分析和设计工作有时候相互混合在一起，所以活动图，作为分析和设计阶段的成果，可以比最原始的需求包含更多的信息。3.3.1 活动图的元素一个活动图的核心标志是活动状态或者说是简单的活动。一个活动就是做某个事情的状态。

42、它可以是真实的过程，比如打印一个字母，或者是执行一个软件程序，比如是执行一个类的方法26。一个活动图可能包括以下元素：1. 活动(Activity)：由人或者软件系统做的一个任务。在活动图中，同步线程也可以被叫做同步活动(Synch Activity)。2. 子活动(Sub-activity)：就是一个活动下来可以有几个同步的进程，每个进程叫做子活动。3. 起点(Start Marker)：活动图的人口(最开始的状态)。每个活动图只有一个起点。4. 终点(Stop Marker)：标志活动图的出口(最终的状态)。每个活动图只有一个终点。5. 决策点(Decision Point)：通过条件来判

43、定该走那条分支6. 同步示意条(Synchronization Bar)：同步示意条是用于显示平行分支流。同步示意条能够显示业务用例的工作流程中的并行线程。7. 信号发射(Signal Sender)：当前面的活动终止，指定的信号发射。8. 信号接收(Signal Receiver)：当信号被接收，后续的活动才能被激活。9. 转移(Transition)：表示各种活动状态的先后顺序。这种转移可称为完成转移。它不同于一般的转移，因为它不需要明显的触发器事件，而是通过完成活动（用活动状态表示）来触发。10. 防卫条件(Guard Condition)：防卫条件可以在转移上指定，以限制该转移的使用。

44、将条件放在转移箭头附近的方框中。在你可以遵循相关的转移进入下一个活动前，该条件的测试必须为真。11. 对象(Object)：对象是系统中相互关系的参与者。对象可能是一个组件，一个子系统，也可能是外面系统的接口。12. 信息(Message)：一些发送到对象的或者从对象中发出的信息。13. 泳道和时标：活动图中泳道区分了其中活动的不同职责，在泳道图中，每一个活动都只能明确地属于一个泳道。泳道和时标相组合的方法：横向按时标分组；纵向按泳道分组。活动图主要元素的图标列在表3-1中。表3.1 活动图的标识活动图描述活动的先后顺序。这种技术对于熟悉软件开发和测试的人员来说同流程图非常相似。可以被用来描述

45、系统运行中的基本流，备选流和额外流。活动图既支持条件行为，也支持并行行为：1. 条件行为用分支(Branch)和融合(Merge)表示1) 分支：一个分支有一个单独的进来的转移和几个出来的转移。用If/Else条件来控制分支的进行。2) 融合：一个融合有多个进入的转移和一个出来的转移。它标志着用分支标识的条件行为的结束。2. 并行行为用分叉(Fork)和会和(Join)表示1) 分叉：一个分叉有一个进入的转移和几个出来的转移。当这个进来的转移被触发，所有的出来的转移都并发进行。2) 会和：一个回合有多个进去的转移和一个出来的转移。只有当所有的进去的转移都完成他们的行为，出来的转移才会进行。图3

46、-1是一个简单的活动图的例子。描述的是航空公司的一个简单的订票系统的系统行为。实心圆表示活动图的起点，实际上是一个占位符，带边框的实心圆表示终点。 圆角矩形表示执行的过程或活动。菱形表示判定点，虽然在此示例中判定点只有两种可能结果；但即使有更多可能结果，它也同样容易。箭头表示活动之间的转换，各种活动之间的流动次序。 箭头上的文字表示继续转换所必须满足的条件，总是使用格式“条件”来描述。粗线条表示可能会并行进行的过程的开始和结束。图3.1 活动图例子在这个例子中，消费者可以用已经存在的系统账户预定机票，也可以在没有系统账户的情况下单独定票。如图3-1所示，在收到订单后，下面是一个分支。如果这个订

47、单是个预定，系统会根据消费者的账户信息找到指定银行账号，用这个银行账号支付相应的订单的数额，同时会在这个账户上增加奖励的点数。如果是个无账户的单独的订票，会随着订单出来需要支付的信息，客户再去支付。在预定过程中，系统会并行处理支付和奖励点数的行为。因此，这是个同步行为，就是fork。下面是一个join。系统是预定和单独订单后的共同行为，当消费者填完订单后都会到系统。这里就是一个融合(Merge)。因为系统必须跟踪没一个订单，所以消息就被发送到对象Log File中。UML 活动图记录单个操作或方法的逻辑、单个用例或商业过程的逻辑流程。在很多方面，活动图是结构化开发中流程图和数据流程图 (DFD) 的面向对象等同体。3.3.2 活动图和测试用例关系在基于需求规说明的测试中，测试用例是基于需求规说明设计出来的，而需求规说明是需求分析和设计阶段的成果。作为需求和设计文档的一部分，活动图给开发人员详细的设计和实施信息，同时给测试人