基于需求变更测试模型的研究

谢 春，郑显举

(成都电子机械高等专科学校 计算机工程系，成都 610071)

软件测试是保证软件质量的重要环节，而稳定的需求则是软件测试的关键［1-2］。一个良好稳定的需求有利于开发人员和测试人员对系统进行准确的验证和评定，确认软件系统是否满足用户的需要［3］。然而实际开发过程中需求却是经常发生变化的，EBERT［4］发现，一个为期2年的项目，会有大于30%的需求发生变更。另一方面，由于新的开发方式［5］的出现，使得需求不仅受到开发团队和客户的影响，组件服务提供商同样也会导致需求的变更。显然，处理这些频繁而又复杂的需求变更仅靠配置管理是不够的。因此，采用合理的开发或测试模型，并在适当的时机借助工具的支持，才能有效控制需求变更的风险。

一般常用的开发或测试模型大都只关注怎样将测试活动融入开发的各个环节，对于需求经常变更的问题都没有很好的解决方案。例如在XP的开发方法［6］中，当需求发生变化时，团队开发人员要和客户代表一起分析并撰写新的需求并对全部需求进行优先级排序，这就会对当前迭代造成影响，会有部分需求挪至下一迭代阶段实现，仍然无法从根本上解决需求变更的问题。在Scrum方法［7］中，开发过程被分成数个小周期的冲刺阶段，在每个冲刺阶段中需求变化是被忽视的，期间出现的任何需求变化，将作为下次冲刺的需求部分，不对当前状态产生影响。前置测试模型［8］是将测试执行和开发结合在一起，一段程序编写完成就立即进行测试，这样就能在较早时间发现错误并将其改正，从而降低测试成本。然而，该模型仍旧是以确定需求为前提，测试的设计和执行都是以固定的需求为纲，一旦需求发生变化，则需要改动以此为基础的许多工作。本研究针对以往模型的不足，在原有测试模型的基础上提出一个应对需求变更的新测试模型，以帮助开发人员更好地应对不断变化的需求。

1 需求变更对模块组装方式的影响

需求是软件开发和测试的纲领，其变更主要来自客户要求的变化，具体来说可以分为3种:

1)需求减少。此类需求变更相对来说较少发生，如客户由于经费的原因缩减项目规模，减少软件系统中的功能需求等。这种需求变更处理起来也很方便，只要屏蔽相关模块即可。

2)需求增加。此类的需求变更有时会发生，主要是由于客户想增加某一功能而导致需要编写新的功能模块。这种需求变更对整个系统而言就是增加新的功能模块，对其它模块来说就是重新编写集成测试中所需要的桩模块和驱动模块。

3)需求改变。此类的需求变更最多，如客户的业务流程改变会导致软件项目中的某个逻辑序列或信息传递途径的改变。对于这种需求变更而言，由于目前通常采用面向对象的开发方法，系统中对象相对稳定，所以改变的只是对象中的方法和对象之间的关系。因此，只要提高基线用例库的可信度并选择恰当的回归测试包就可提高测试效率。

软件测试包括4个阶段，即单元测试、集成测试、确认测试和系统测试。相对于软件开发过程的自顶向下而言，测试过程正好相反，是自底向上逐步集成。集成方式有一次性组装和逐步增殖组装［9］。对于一次性组装方式来说，需求变更发生后，对象会有新的方法、新数据结构以及新的对象间关系，所以系统复杂性增加，从而导致错误(bug)查找难度成倍地提高。对于增殖组装方式而言，自顶向下增殖的方式和自底向上增殖的方式对应于需求变更各有缺点。具体来说，自顶向下增殖方式需要建立桩模块，而桩模块要能够较好地模拟实际子模块的功能是比较困难的，因为桩模块在接收了所测模块发送的信息后需要按照它所代替的实际子模块功能返回应该回送的信息，这中间涉及复杂算法和底层输入输出模块，难度较大而且也最容易出问题。此外，到组装和测试的后期，因需求变更所增加新模块一旦出现问题，就会成倍地增加回归测试的工作量。而自底向上增殖方式的缺点是被测试系统一直未能作为一个实体存在，直到最后一个模块加上去后才形成一个实体。也就是说，在自底向上组装和测试的过程中，对主要的控制模块直到最后才接触到，因此由于需求变更所产生或修改的模块是否满足需求，直到最后一步之前是未知的。这2种增殖方式的组装方向都是单向的，难以满足软件开发过程中需求变更的要求。

当使用自顶向下组装方式时，遇到的问题是对应于需求变更的模块过晚的测试，违背了最可能出现问题的部分最先测试的原则［10］。当使用自底向上组装方式时，遇到的问题类似，前者是模块失效，导致系统的反复回归测试，后者则对于测试处于失控状态，尽管测试顺利，但不能说明整个系统的具体状况。

综上所述，可以采取以下方法加以改进:1)衍变的自顶向下的增殖方式。强化对需求变更模块的测试，自底向上组装成为功能比较完整且相对独立的子系统，然后由系统主模块开始自顶向下进行增殖测试。这种方法既避免了自顶向下增殖组装时测试的失败导致的反复回归测试，又避免失去对测试过程的控制。采用这种改进后的策略，在遇到需求变更的情况时，系统的模块会对应地变化，新变化的模块出问题的概率相对较大(即质量风险高)，因此先加强它的测试就可以有效规避质量风险，然后再利用自顶向下组装的优势组装成一个稍大的子系统，从而改进测试过程。2)基于服务的增殖方式。首先对含服务请求操作的新模块进行自底向上直至根结点的组装和测试，然后对含提供服务操作的新模块做自顶向下的组装与测试。这种方法符合面向对象消息发送的原则，更重要的是能够简化桩模块的编写工作。采用这种组装策略，在遇到需求变更的情况时，最大的变化是对象的方法和对象间关系的改变，组装时重点考虑对象间关系的变化，即考虑服务提供者和服务请求者之间的关系，简化桩模块的编写，同时分别利用自顶向下和自底向上的优点，从而改进测试过程。

2 对于传统模型的改进与工具的选择

2.1 模型的改进

笔者采用了如图1所示的改进的测试模型。该模型以系统需求为起点进行系统分析与设计，同时制定测试计划;以需求变更为切入点修正测试计划，即对需求变更进行控制，并以此来跟踪需求变更对系统中原有的对象的影响。此外，为了突出对于需求变更的处理，这里简化了系统分析设计的描述，但并不是不重视系统的分析与设计，相反，良好的系统分析与设计是这个测试模型能顺利实施的最基本的前提条件［11］。该模型主要有如下3个特点:

图1 基于需求变更的测试模型

1)在设计阶段进行计划和测试设计。设计阶段建立测试计划和进行测试设计至关重要。没有测试计划和设计的测试过程只是验证了程序的正确性，无法验证整个系统本该实现的东西。V模型中验收测试最早被定义好，并在最后执行，以验证所交付的系统是否真正符合用户业务的需求。相对于V模型，本测试模型还包含了对需求进行的测试，这样可以保障对需求变更的控制。

2)测试和开发结合在一起。本模型中，测试执行和开发结合在一起形成一个迭代的过程。在普通情况下，先进行的测试是单元测试，因为这是测试人员通过测试来发现错误最经济的方式。需求变更后，则可以结合需求变更采用不同的集成测试方式，并且可以跨越各个不同的测试阶段灵活地进行测试。在技术测试计划中定义好单元测试与集成测试的组装类型，就可有效地改善软件测试质量，提高测试效率。

3)验收测试和技术测试保持相互独立。验收测试独立于其他的技术测试阶段，这样可以提供双重验证，保证设计及程序编码能够最终符合用户的需求。

2.2 工具的选择

从功能角度看，为了满足以上模型的需求，需求管理工具需要提供以下基本功能:1)支持需求的记录以及分解和对需求按照优先级或者其他方式进行排序。2)需求之间依赖关系的标识，隐藏需求依赖关系的识别和定义，对变化的需求影响范围进行分析等。3)支持版本记录和基线记录，并支持不同版本之间的比较，根据需要恢复到历史版本等功能。4)需求到设计、代码、测试等工作产品之间的链接，并且在需求变化的时候，提示相关联工作产品的功能。5)支持各种状态下的提醒以及提供交流的功能，方便异步或者远程交流等。6)对流程的定制功能，以便适应不同的流程控制方法，不同的机构也可以对各种主流的变更管理在流程上针对自己的情况做定制。

如果有需求管理工具能覆盖上面这些功能，那就可以对本研究提出的需求变更测试模型进行支持。目前比较常用的需求管理工具有 Borland的 CaliberRM，IBM Rational的 RequisitePro与 ClearQuest。其中CaliberRM功能相对较全，对需求变更管理的大部分功能都有支持，但在工作产品链接上以及交流方面的支持相对较弱。而RequisitePro和ClearQuest相对于前两者则功能较弱，这是因为这2个都是IBM Rational的产品，RequisitePro是一个需求管理工具，而ClearQuest是一个变更管理工具，要提供需求变更管理，需要把两者结合使用。但是ClearQuest虽然对变更管理支持得很好，却不是专门为需求变更所开发的，即使与RequisitePro搭配也很难针对需求的特点定制使用。总体来说，这些主流的需求管理工具都提供了对需求变更管理能力的支持，但是并没有做到很完美，例如对于交流的支持、工作产品的链接查看等有待改进。

3 测试改进实例

EHR人力资源管理系统是陕西骅冠信息技术有限公司针对特定企业进行定制开发的人力资源管理系统。它由公司组织结构、员工基本信息管理、招聘管理、考勤管理、薪资管理、绩效考评等模块组成。在该系统测试的具体实施过程中，采用本文提出的基于需求变更的测试模型与CaliberRM辅助需求管理软件。首先以需求分析为基础编写需求文档，然后进行需求评审，制定测试计划，在开发过程中，针对需求变更做出适当记录，为以后的测试改进打下基础(过程如图2所示)。

仔细阅读规格说明、设计文档、使用说明书及测试大纲、测试内容及测试的通过准则，全面熟悉系统，编写测试计划，设计测试用例，作好测试前的准备工作。为了保证测试的质量，将测试过程分成代码审查、单元测试、集成测试和验收测试等几个阶段。代码会审由一组人通过阅读、讨论和争议对程序进行静态分析。会审小组在充分阅读待审程序文本、控制流程图及有关要求、规范等文件基础上，召开代码会审会，由编码者讲解程序的逻辑。实践表明，编码者在讲解过程中能发现许多原来没有发现的错误，并通过讨论发现更多问题。例如，对某个局部性小问题修改方法的讨论，可能发现涉及到模块的功能、模块间接口和系统结构的大问题，导致对需求定义的重定义、重设计验证。单元测试集中在检查软件设计的最小单位模块上，通过测试发现实现该模块的实际功能与定义该模块的功能说明不符合的情况，甚至编码的错误。由于单一模块规模小、功能和逻辑简单，测试者可清楚地了解该模块的逻辑结构，采用结构测试方法彻底测试，然后辅以功能测试，覆盖输入域(如图3所示)。

单元测试完成后展开集成测试，模块按照设计要求组装起来同时进行测试，目的是发现与接口有关的问题。如数据通过接口时丢失;一个模块与另一个模块由于疏忽造成互相有害的影响;子功能模块组合起来不产生预期的主功能;个别看起来可以接受的误差积累到不能接受的程度;全程数据结构可能有错误等。在集成测试阶段，针对需求变更的不同类型，采取合适的测试方案，在EHR人力资源管理系统中，用户由于对绩效考评方法的变更导致需求发生了变化，但是由于系统中的对象没有发生本质的变化，所以可以采取基于服务请求方向的集成组装测试策略。

集成测试完成后展开系统测试，从产品的角度检验软件。经过这样的测试过程后，软件基本满足质量要求，测试宣告结束，经验收后将软件提交用户。

纵观HER人力资源管理系统的测试，从初始阶段跟踪需求变更，将需求变更分类，在集成测试阶段依据需求变更的不同类型采取恰当的集成测试策略，其间优化维护测试用例库，并以此展开回归测试，降低了测试工作量，改善了测试的效率，减低了测试成本，提高了软件产品的质量。

4 结语

本文从需求变更的原因入手，通过分析软件测试过程，详细说明了测试系统的组织以及工程设计的原则，着重探讨了集成测试中模块组装的策略，分析了一次性组装和增殖组装方式各自的优缺点，在基于需求变更控制的基础上改进了软件测试方法。对传统测试模型进行了改进，形成了基于需求变更的新模型。该模型以系统需求为起点进行系统分析与设计，同时制定测试计划;以需求变更为切入点修正测试计划，为软件测试活动作出具体的指导。

［1］KENNER C，FALK J.计算机软件测试［M］.北京:机械工业出版社，2004.

［2］PERRY W E.软件测试的有效方法［M］.北京:机械工业出版社，2004.

［3］LEFFINGWELL D，WIDRIG D.软件需求管理:用例方法［M］.北京:中国电力出版社，2004.

［4］EBERT C.Understanding the product life cycle:FOUR key requirements engineering techniques［J］.Software，IEEE，2006，23(3):19-25.

［5］KOHL R J.Requirements engineering changes for COST-intensive systems［J］.IEEE Software，2005，22(4):63-64.

［6］BECK K，ANDRES C.解析极限编程:拥抱变化［M］.北京:电子工业出版社，2006.

［7］SCHWABER K，BEEDLE M.Agile software development with scrum［M］.［S.1.］:［s.n.］，2002.

［8］BINDER R V.Design for testability in Object-Oriented system［J］.Communications of the ACM，2004，37(9):87-101.

［9］GAUSS D C，WEINBERG G M.探索需求:设计前的质量［M］.北京:清华大学出版社，2004.

［10］GUPTA N，MATHUR P A，SOFFA M L.Automated test data generation using an iterative relaxation method［J］.Software Engineering Notes，1998，23(6):231-244.

［11］DOONG R K，FRANKL P G.The approach to testing Object-oriented programs［J］.ACM Transactions on Software Engineering and Methodology，2004(3):101-177.