基于行为的软件测试过程模型及其应用研究

摘要：在深入研究各种综合测试技术的基础上，通过对比分析各种主流的测试模型，提出了一种基于行为的软件测试过程模型，包括了测试设计、测试计划、测试执行、测试结果分析和测试重用等活动，把这些测试活动嵌入到软件开发的整个生命周期当中。然后将这种测试模型应用到一个大型的应用程序测试项目(AMP)中，发现这种测试模型在尽早发现Bug和回归测试选择效率上具有较好的测试效果。

关键词：软件测试模型;软件过程改进;基于行为的测试;行为规格说明;回归测试

中图分类号： TP311

文献标识码：A

0引言

近年来，以软件测试为中心的软件质量保障技术在软件生产实践中得到迅速发展，软件测试已成为软件生产中必不可少的质量保障手段。测试是交付成功的优质产品的保证，软件存在的问题很多都和测试的成效有关[1, 2]。目前软件测试已不再仅仅作为软件产品成型之后的附加活动，而已经被看作是同软件开发一起发生并发展的生命周期过程。但是现有的方法存在着一些限制和不足，大部分的研究都仍然仅仅注重于原理和策略；在验证系统需求实现上存在着不足；形式化的规格说明和方法很昂贵；很多方法都受特定的软件结构和程序语言的限制每一种建模技术和方法都只针对着整个测试过程的某个阶段，而并没有来指导整个测试流程，贯穿软件测试的始终。目前常用的测试模型有V材P汀W材P秃X材P汀V材P偷募壑翟谟谒非常明确的标明了测试过程中存在的不同级别，并且清楚地描述了这些测试级别和开发过程中各个阶段的对应关系。但V材P鸵泊嬖谛矶嗖蛔阒处[3]：1) 容易导致需求阶段隐藏的错误一直到最后验收测试时才被发现; 2) 把系统开发过程和测试过程划分为具有固定边界的不同阶段，这使得人们很难跨过这些边界来采集测试所需要的信息，而且它也阻碍了从系统描述的不同阶段中取得信息进行综合; 3) V材P兔挥忻魅返闹赋霾馐陨杓频氖被和规划，越来越多的经验和实例说明越早的进行测试设计，就越能避免系统构架设计和业务逻辑设计中的问题扩散到整个系统当中; 4) V材P腿菀兹萌瞬生“测试是开发之后的一个阶段”的误解。而W材P颓康髁巳砑测试不等于程序测试，不应该仅限于程序测试的狭小范围内，应该贯穿于软件定义与设计开发的整个过程。X材P褪且恢侄V材P偷母慕方法，其缺陷在于[4]：1) 没有指出在软件测试的各个阶段都应该进行测试设计; 2) 没有像V材P湍茄明确的需求角色的确认; 3) X材P筒⒉灰求在进行作为创建可执行程序的一个组成部分的集成测试之前，对每一个程序片段都进行单元测试，不像V材P湍茄有明确的固定边界，但X材P兔荒芴峁过单元测试的判断准则; 4)过于关注低级别即程序级别的行为，而没有抽象成一个系统的模型。为了解决这些问题，我们提出了一种综合测试方法――基于行为的测试建模方法。这种测试方法包括了测试设计、测试计划、测试执行、测试结果分析和测试重用等活动。这个软件测试过程模型以行为规格说明为中心，对已有的传统的测试模型进行了改进，吸收基于使用用例和使用场景的建模技术，改进基于需求的形式化测试规格说明成为半形式化行为规格说明，形成新的基于行为的综合测试技术。并且在基于行为测试的基础上重新考虑回归测试，提出了通过行为依赖关系分析和行为抽取技术对测试用例进行选择的回归测试解决方案。最后在AMP(American OnLine Media Player)测试项目中应用该模型，考察其实际的效果。实践表明：这种测试模型能尽早发现Bug，在回归测试选择效率上具有较好的效果。

1基于行为的软件测试过程模型的建立

对于软件测试来说，一个好的测试模型应该具有以下的特征[5]：1) 能将测试计划、测试用例设计、测试执行，测试结果分析等一系列活动有效的结合在一起；2) 能够适应于不同目的的、不同实现的各种软件系统；3) 能使软件设计中的错误尽可能早的暴露出来。为了使软件测试过程和软件开发过程能更有效的结合在一起，同时尽可能早的介入测试，从测试的角度来把握整个软件开发过程，这里提出了一个改进的基于行为的软件测试过程模型，如图1所示。

在该模型中，首先需要从需求分析中得到测试规格说明。测试规格说明是测试场景和测试用例开发的基础，同时也是系统开发的参照。它主要从业务逻辑和功能逻辑上对软件的需求进行分析和说明，既是对需求的评审，也是对系统功能的表现。然后在测试规格说明的基础上进行测试场景和测试用例的开发，这和软件的开发同步进行，并且在软件开发的过程中不断地完善和改进测试规格说明。再通过测试场景和测试用例来进行单元测试来确认详细设计，通过集成测试来确认概要设计，通过系统测试来验证需求。此模型为基于行为的测试提供一个结构化的过程，标识了测试计划、测试设计、测试执行、测试结果和分析、回归测试等各个阶段的元素，这些测试活动嵌入了软件开发的生命周期，可以使软件开发更加具有可测性，从测试观点上改进了传统的软件开发流程。并且在这个模型中，软件测试是一个定义和组织的过程。项目管理人员和测试工作人员在一开始就介入到软件开发的整个过程中来，他们制定测试目标和需求，设计测试用例，分级和选择测试用例，这些活动安排在系统开发和测试执行之前。同时基于行为的测试是一个具有生命周期的过程，即它在软件的生命周期中与软件开发活动共同进行交互和合并。

2基于行为的软件测试过程模型的应用

AMP项目是信必优公司在2005年承接AOL公司的一个测试项目[6]。它是AOL公司推出的全新的多媒体播放器，是一个C/S结构的应用软件，分为本地应用和网络应用两个功能区域。2005年，AOL在AMP的测试版中加入了AMS(AOL Music Store)的模块，在AMP中集成了一个以为平台的在线音乐购物平台。主要的功能是为AOL用户提供即时的各种音乐素材的销售。针对这个模块，有两种用户类型Master用户和Guest用户，其中Master用户具有独立的个人账户，可以进行充值、搜索、浏览、播放、购买等全部的功能，而Guest用户则只有浏览，搜索的权限。因为之前已经做过AOL Communication Suite中的Media Player部分的测试，因此这次测试可以看作是一次升级版本的测试，在整个测试过程中，我们应用了基于行为的软件测试过程模型，并同之前的测试工作进行了比较分析，以求得到该模型在实际应用中的效果。

以AMP的AMS模块为例，测试过程首先是对测试规格说明的开发，通过对系统功能需求的分析生成行为树和与之相关的条件树。树根就是整个AMS模块。根节点的孩子节点标识出系统提供的各种各样的服务种类，比如在线搜索、在线播放、在线购买等等，每一个服务下面又根据不同的结果进行了分解。这样的行为图可以清楚地描绘系统的功能需求，同时也可以体现各个功能需求之间的关系，便于进行测试。图2是对应AMP的AMS部分的条件树例图。

在形成行为树和条件树以后，利用它们来生成测试场景和测试用例，行为树的每个叶子节点都可以看作一个简单的测试场景，再通过各种关系：连续、重复、并行、选择等组合成复杂的测试场景。

从测试场景到测试用例主要是根据跟该行为相关的各种条件之间的各种组合来生成相应的测试用例，比如对购买中的账户登录这一功能，主要涉及到了4个条件变量，分别是账号、密码、余额、账号类型。对每一个条件变量我们可以分为两个等价类，账号密码是正确的和错误的，余额是充足和不足，账号类型是Master和Guest。对这4个条件变量建立简单的决策表，既可以根据组合生成不同的测试用例。同时，还可以对条件变量比如余额应用边界值分析，在AMP规定的取值范围内外取适当的值，生成不同的测试用例。

最后是最重要的回归测试部分，应用行为抽取和波形效应分析的方法，选取有效的测试用例：比如在AMS的测试过程中提出一个新的功能要求：对AOL用户允许一定金额的透支，即一个用户可以在余额不足的情况下在一定的限额内购买商品，但是要承担一定的透支利息。分析这个变动需求，可以知道最直接影响到的行为组是BG31和B324，然后根据行为依赖关系对分析和行为抽取：比如通过功能依赖，可以得到BG32，通过输入/输出依赖，可以抽取出行为组BG41，然后再通过实体关系图，可以找出和行为对应的软件构件进行修改，同时更新所有受到影响的行为和行为组。表1列出了在AMS的回归测试中一些功能或者界面上的修改，然后对这些变动需求应用了行为抽取后的结果。表2列出了根据表1的行为抽取结果进行回归测试所发现的对应bug例表。

将上述基于行为的软件测试模型应用于新版本的AMP项目测试中。软件测试人员从一开始的需求更改开始介入了软件测试的过程。在整个软件测试的始终都贯彻了基于行为的软件测试的全部过程，从功能需求开始开发测试规格说明，模拟出整个AMS部分的行为树和条件树。根据各种条件变量的取值，通过等价类、决策表、边界值等方法生成测试用例，并执行测试。在回归测试部分更是严格地按照基于行为依赖关系分析的各种行为抽取标准来进行行为抽取，对一个变动对整个软件的影响作详尽的波形效应分析，从而给选择合适有效的测试用例进行回归测试提供了便利。同时与接下该项目外包测试的印度公司最后的数据进行了比较。印度公司使用了传统的V材P徒行测试，用捕获再现的方式生成测试用例[7]，用基于源代码的回归测试方法选择测试用例[8]。而我们则全程用基于行为的软件测试模型来指导测试工作。最后的测试结果如下：我们对AMS模块共生成了280个有效的测试用例，发现了140个有效的Bug，并在规定时间之内提前达到了测试结束标准。而印度公司对该模块的测试共生成了250个有效的测试用例，发现了105个有效的Bug，在规定时间之内未能达到测试结束标准。因为外包测试的限制，无法对测试用例的覆盖率进行比较，但以上的数据可以从一个侧面说明基于行为的测试模型的整体具有较好的测试效果。同时通过分析得到的数据，可以发现基于行为的测试模型对比传统的测试方法有利于更早的发现需求设计上的错误，如图3所示；在回归测试的测试用例选择上具有较好的效果。对表1和表2中的变化需求和Bug例子分别使用了3种不同的回归测试策略来进行比较分析，分别为全部测试所有的测试用例、基于源代码的回归测试选择和基于行为的回归测试选择。得出的结果如表3所示。

3结语

在分析研究各种综合测试技术的基础上，提出了一种基于行为的软件测试过程模型，整个模型以行为规格说明为中心，同时贯穿开发和测试两个过程，能在整体功能上对系统的测试具有指导意义。该模型应用于测试项目AMP中的测试结果表明：该模型有利于更早地发现需求设计上的错误，并且能够有效地选择回归测试的测试用例。因此该模型对软件测试技术的提高有一定的借鉴作用。