（计算机软件与理论专业论文）mda中需求测试的一种方法.pdf

摘要 为了改进软件开发方法，本文在模型驱动架构中的c i m 模型中使用了更为抽 象的需求模型，在这种基础上，本文提出了一种需求测试方法的流程。这也是m d a 提出后，软件测试研究的重要方面。 要进行需求测试，就要首先获得需求模型，在文中采用了表格驱动的方式， 将功能性需求和非功能性需求分别以用例和表格模板方式进行获取和描述。在此 基础上，对功能性需求测试本文提出了一种测试流程并给出了部分算法：由用例 模型中获取测试用例，从用例模型中转换得到顺序图并从顺序图中得到事件序列， 然后将测试用例代入相应的事件序列中来进行测试；对非功能性需求主要是将其 量化，使之成为可度量的标准。这样就将需求测试提前到软件设计阶段。相对于 以前在软件实现后进行的测试，这就极大的降低了软件开发的风险。 关键词：模型驱动架构需求获取需求管理需求测试 a b s t r a c t t oi m p r o v et h ed e v e l o p m e n tm e t h o d ，i nt h i st h e s i sc i m ( c o m p u t a t i o ni n d e p e n d e n t m o d e l ) i nt h em d a ( m o d e ld r i v e na r c h i t e c t u r e ) u s e sam o r ea b s t r a c tm o d e lo f r e q u i r e m e n tt h a ne v e r b a s e do ni t ，ap r o c e s so fr e q u i r e m e n tt e s ti sg i v e ni nt h i st h e s i s a n d r e q u i r e m e n tt e s th a sb e c o m ea ni m p o r t a n ta s p e c to fs o f t w a r et e s ts i n c et h e n t or u nar e q u i r e m e n t t e s t ，w eh a v et oo b t a i nar e q u i r e m e n tm o d e lf i r s t i nt h i st h e s i s w ea d o p taf o r m - d r i v e na p p r o a c ht oo b t a i nr e q u i r e m e n tm o d e l si nt h ep r o j e c t t h e r e q u i r e m e n t sa r ed i v i d e di n t of u n c t i o n a la n dn o n f u n c t i o n a lr e q u i r e m e n t st ob ea c q u i r e d a n dd e s c r i b e ds e p a r a t e l yu s i n gu s ec a s e sa n dt a b l et e m p l a t e s b a s e do nr e q u i r e m e n t m o d e l s ，ap r o c e s sa n dt h ea l g o r i t h mo ff u n c t i o n a lr e q u i r e m e n tt e s ta r eg i v e ni nt h i s t h e s i s t e s tc a s e sa n ds e q u e n c ed i a g r a m sa r eo b t a i n e df r o mr e q u i r e m e n tm o d e l s ，a n d t h e nw eg e ts e q u e n c e so fe v e n t sf r o ms e q u e n c ed i a g r a m s ，a f t e rt h i sw er u nat e s tb y p u t t i n gt e s tc a s e si n t os e q u e n c e so fe v e n t s f o rn o n - f u n c t i o n a lr e q u i r e m e n tw em a i n l y q u a n t i f yt h e ma n dm a k ei tm e a s u r a b l es t a n d a r d u s i n gt h i sm e t h o dw ec a na d v a n c e r e q u i r e m e n tt e s tt os o f t w a r ed e s i g np h a s e c o m p a r e dt op r e v i o u sr u n n i n gr e q u i r e m e n t t e s ta f t e rs o f t w a r ei m p l e m e n t a t i o n ，t h i sm e t h o dg r e a t l yr e d u c e st h er i s ko fs o f t w a r e d e v e l o p m e n t k e y w o r d ：m o d e ld r i v e na r c h i t e c t u r e r e q u i r e m e n tm a n a g e m e n t r e q u i r e m e n te l i e i t a t i o n r e q u i r e m e n tt e s t 西安电子科技大学 学位论文独创性( 或创新性) 声明 秉承学校严谨的学风和优良的科学道德，本人声明所呈交的论文是我个人在 导师指导下进行的研究工作及取得的研究成果。尽我所知，除了文中特别加以标 注和致谢中所罗列的内容以外，论文中不包含其他人已经发表或撰写过的研究成 果；也不包含为获得西安电子科技大学或其它教育机构的学位或证书而使用过的 材料。与我一同工作的同志对本研究所做的任何贡献均已在论文中做了明确的说 明并表示了谢意。 申请学位论 本人签名： 不实之处，本人承担一切的法律责任。 日期迦& ：量： 关于论文使用授权的说明 本人完全了解西安电子科技大学有关保留和使用学位论文的规定，即：研究 生在校攻读学位期间论文2 1 2 作的知识产权单位属西安电子科技大学。学校有权保 留送交论文的复印件，允许查阅和借阅论文：学校可以公布论文的全部或部分内 容，可以允许采用影印、缩印或其它复制手段保存论文。同时本人保证，毕业后 结合学位论文研究课题再撰写的文章一律署名单位为西安电子科技大学。 ( 保密的论文在解密后遵守此规定) 本学位论文属于保盔，在一年解密后适用本授权书。 本人签名：捌 日期递壁笸：篁 导师签名：1 翥旧期一 第一章绪论 第一章绪论 1 1 研究背景 软件开发的几十年历程业已证明，在开发生命周期中划分阶段的做法是很有 好处的。从经典的瀑布模型到螺旋模型和过程迭代方法，从快速软件开发至i j r a t i o n a l 统一过程( r a t i o n a lu n i f yp r o c e s s ，r u p ) 。这些过程和方法都描述了将整个软件开发 分为需求、设计、编码和测试等阶段，并对每个阶段进行过程的定义和管理。但 是，我们也应该看到，软件开发本身就是一个完整的过程，虽然我们可以将其划 分为不同的阶段和过程来加以管理。在现实的软件开发过程中，更是各个过程并 发执行。因此，我们应该将这些过程加以集成，找到集成过程的方法和模型，使 这些人为分离的过程能够紧密的结合在一起工作。 在这种情况下，出现了模型驱动架构( m o d e ld r i v e na r c h i t e c t u r e ，m d a ) 。m d a 的核心思想是用更高抽象层次的模型代替原来的代码作为核心来开发软件，解决 传统软件开发模式中需求分析和设计中所做的模型和文档与编码实现中的代码存 在的严重不一致的问题，使软件开发过程自始至终都保持高度一致，从而大幅度 提高软件开发效率，增强软件的可移植性、协同工作能力和可维护性，为文档编 制的便利性指明道路【l 】。模型驱动架构主要是分离业务功能设计与实现技术之问的 紧耦合关系，将关注点放在系统应用本身而非中间件平台，从而减小技术变化对 系统所造成的影响。目前软件界认同的m d a 软件开发过程只包括建模、开发、发 布等阶段，但不包括需求、测试等阶段。这并不是说在m d a 框架下需求和测试阶 段不需要存在，事实上它们都是很重要的，只是现在使用的m d a 开发过程中还没 有涉及到，也还没有这方面工具进行支持【2 j 。因此，为了使m d a 框架更加完整， 需要将m d a 的开发过程扩展到需求阶段， 真正做到模型驱动技术从业务模型开始。 件测试技术扩展到需求测试。 并且要与现存的m d a 开发过程相衔接， 为了保证软件的质量，本文对应的将软 软件需求获取是软件系统开发过程中最为困难也是最为重要的部分，只有真 正满足用户需求的软件产品才能为用户所接受，不能满足这一点的产品不管采用 了多么先进的技术对用户来说也是毫无用处的。需求往往是最能省钱的地方。根 据l e f m g w e l l 在1 9 9 7 年的研究，软件项目4 0 一6 0 的问题根源都是在需求的获取 和分析阶段埋下的，而这些问题放到产品发布后再改正，比在需求阶段就改正， 需要多付出6 8 - - 2 0 0 倍的成本。传统的结构化软件开发方法在需求阶段侧重的是业 务数据或者是业务流程，却没有把二者结合起来考虑，开发出来的产品结构复杂 m d a 中需求测试的一种方法 难以维护、可重用性差。面向对象技术把数据及其处理过程集成到类中，克服了 结构化方法的缺点，但是忽视了用户的需求。以前说软件开发技术，往往忽视了 用户才是软件产品的最终使用者，大多数公司主要注意的是实现阶段的技术。需 求阶段草草了事的居多，他们大多以功能为中心而忽视了用户的参与，通常会导 致最终产品与客户间的期望差异。但是随着软件业的发展，现在很多公司也己经 注意到了需求技术的重要性。正因为软件需求的重要性，在m d a i 具中才有必要 增加对需求的支持。而从目前的一些需求获取和管理工具来看，完全由工具代替 人与用户进行交流是不现实的。所以在工具中需要尽可能的对用户提供直观性的 支持和多样化的选择，使得到的需求尽可能的接近用户表达的需求。 软件测试也经过了较长的发展过程。由于软件危机以及越来越严重的软件质 量问题，软件测试的重要性也越来越受到重视。最初的软件测试主要是代码测试， 集中在软件开发过程的后期。由于近期一些大的项目开发失败，大部分原因集中 在软件需求部分，软件测试的理念也不断发生变化，逐渐由代码测试扩展到整个 软件开发过程的全程测试1 3 】。软件的质量管理要求我们在每个阶段都要进行验证和 确认过程。因此需求阶段还需要对需求本身进行测试。因为在许多失败的项目中， 大部分的返工是由于需求方面的错误所导致的，并且因为需求的缘故而导致大量 的返工，造成进度延迟、缺陷的发散，这是一件极其痛苦的事情。因此我们要求 在项目的源头( 需求) 就开始测试。这也符合软件缺陷的一个理念：早发现就等于低 代价【4 j 。基于以上这些原因，需求测试开始备受关注。 很多时候，测试用例在实际处理过程中没有起多大作用，测试人员在实际测试 时根本没有按测试用例执行，测试用例的编写非常困难，编写出来的测试用例不 能真正体现用户的需要。分析认为，对测试用例重要性的认识不够，测试流程不 完善，针对测试用例的管理流程更不完善是其中的原因，但根本原因在于需求获 取阶段。 目前提出的一些需求测试方法，这类方法更多的还是静态手工方面的测试， 其中最常使用的手段是同行评审。当然也有一些自动化的工具，但这些工具会要 求我们按照某个固定的格式进行需求的表述( 例如形式化方法) ，而这些表述方法很 少具有通用性，所以在适用性上会受到限制。现在文中将静态手工方法和自动化 方法相结合，提供一种比较具有通用性的工程方法。 在很多项目的需求分析和评审阶段，测试员不会参与进来。但是这样的做法 往往忽略了很多东西，例如：不熟悉系统相关业务的测试员可以通过需求分析和 评审获取更多有关的领域知识；需求的可测试性没有得到很好的评估，可测试性 是清晰性的一种形式。所以在需求测试评审时，最好有测试人员参与其中。 需求测试不等同于后面阶段集成测试或者系统测试，后面的测试都是软件已 经编写完成的条件下，判断软件是否会出错。而在m d a 工具中需求测试，是在确 第一章绪论 保需求获取过程中获取的需求是真是假的前提下，来验证所得到的功能性需求中 的流程是否正确以及非功能性需求是否能够得到保证，通常情况下这些需要在软 件开发过程中甚至软件开发完成后进行，在m d a 模型中，由于能从最初的需求模 型得到一些形式化的模型，从而借助这些模型能将这些测试过程提前，从而能更 早的发现错误，纠正错误，降低软件开发的风险。 1 2 研究目标及内容 由于在m d a 中模型是经过一步步细化和转换来实现模型驱动的，所以最初的 需求表示方法会影响到后面的转换过程，并且也限制了需求测试所采用的方法。 现有的需求管理工具中的多对需求进行复杂多样的分类并以各种图表来表示。这 样在进行测试的时候就要对各种图表以及图表之间的关系都要进行测试。这样无 疑增加了测试的复杂度。为了降低这些复杂度，使需求表示更具直观性，需求测 试更易进行，针对这些问题，本文给出了一种m d a 中计算无关模型( c o m p u t a t i o n i n d e p e n d e n tm o d e l ，c i m ) 层的需求获取方法并在此基础上提出了一种需求测试方 法。 研究的主要内容为： 1 1m d a 中需求获取方法及实现 2 ) m d a 中需求测试方法流程 3 ) 需求测试流程中各模块算法设计 通过这种简单直观的需求表示方法，降低了需求测试的复杂度，可以保证模 型转换中所需的信息量且以较小的代价提高软件的可信度，在测试中对获取的需 求分别进行测试。对功能性需求给出测试流程及每步算法；对非功能性需求进行 量化处理。 1 3 本文的工作与创新 本文的所做工作主要有： 1 ) 在需求获取中提出用用例和非功能性需求表格来描述需求，这种方法中使 用自然语义，因而能更好的与用户进行交流，这样也实现了m d a i 具中 的c i m 模型。 2 ) m d a 需求描述的基础上提出了一种需求测试方法的流程：将从需求用例 中得到的测试用例代入到顺序图的事件序列中进行测试。 3 ) 给出了需求测试每一步所需的算法。 本文的创新之处在于将尝试需求与m d a 相结合，完善m d a 的软件开发过 4 一 m d a 中需求测试的一种方法 程。在m d a 中采取了用例和非功能性需求表格这种更抽象，更接近用户的需 求模型：同时在需求测试方法中，在现有一些技术的基础上，提出了一种流 程方法，从用例模型中得到测试用例；从顺序图中得到事件序列；最后将测 试序列代入事件序列中进行测试。这就使需求测试提前到了软件设计阶段， 而不是软件实现后进行。 1 4 论文的组织结构 本文第一章介绍了当前软件开发过程的发展，m d a 的简要概念，需求工程和 需求测试的重要性，提出了本文的研究目标需求获取和需求测试的方法，以 及其优点。 第二章介绍了m d a 的相关知识和用例分析技术中的一些方法和注意事项，为 需求管理和测试方法提供基础。 第三章简单分析现有需求管理工具采用的方法和需求测试的概况，并对需求 管理工具进行系统比较。 第四章主要介绍m d a 中需求获取方法，由于m d a 中的c i m 层使用了功能性和 非功能性需求的表示的组合方法，所以这里重点介绍两种图表：用例图和非功能 性表，以及一些辅助性表格。最后简要介绍了这种方法的实现。 第五章介绍需求测试的方法流程和算法并通过相关例子对其进行说明。这种 方法主要是针对需求表示法中两种重要图表分别设计的。 第六章结束语对本文的内容做了总结，并提出下一步工作的构想和目标。 第二章m d a 相关知识及用例驱动方法兰 第二章m d a 相关知识及用例驱动方法 2 1m d a 相关知识 2 1 1m d a 中的基本概念 m d a 是对象管理组织的一个标准。m d a 把建模( m o d e l i n g ) 和生成器( g e n e r a t o r ) 推向了软件开发的前台而软件的编写工作则在很大程度上退到了幕后。而模 型是对系统的一部分结构、功能或行为正式规约。首先，模型是一种系统规约， 这种规约可以是对结构的规约也可以是对系统功能或系统行为的规约：其次，这 种规约必须是正式的，即必须使用一种严格定义没有歧义的语言。所以一个模型 必须和一种严格定义了语法和语义的建模语言绑定在一起。根据模型的这种定义， 程序代码也是模型。 m d a 将软件系统的模型分为c i m ，平台无关模型p i m ( p l a t f o r mi n d e p e n d e n t m o d e l ) 和平台相关模型p s m ( p l a t f o r l ns p e c i f i cm o d e l ) 。 计算无关模型是m d a 基于计算无关视角建立的系统模型，用于描述系统需 求、功能、行为和运行环境，也称为业务模型。之所以被称为计算无关，主要c i m 侧重于表达系统的外部行为和运行环境，而不是表现系统的内部结构和实现细节 等相关内容。它代表了生命周期中的需求模型【5 ，6 】。 在m d a 框架中，c i m 为领域专家与系统设计专家之间关于领域需求的沟通 和交流提供了桥梁，并直接支持p i m 、p s m 模型的构造和实现。 平台无关模型是m d a 基于平台无关视角建立的系统模型。p i m 是抽象出的业 务逻辑。之所以被称为平台无关，主要是p i m 不包括与实现平台和技术相关的特 定信息。p i m 所表现出的平台无关性，使其能够在任何技术平台上得以实现。它 代表了生命周期中的分析模型【5 ，6 】。 平台相关模型是m d a 基于平台相关视角建立的系统模型。p s m 从相应p i m 转换而来，它包括了p i m 中所定义的业务逻辑规范，也包含了与选定平台和技术 相关的实现细节。它代表了生命周期中的详细设计模型【5 ，6 】。 m d a 中各种模型扮演着不同的角色，我们希望从一种模型( 源模型) 自动得到 另一种模型( 目标模型) ，这就是模型变换。模型变换由一系列的变换规则组成，形 式上可以看作一个函数。这些变化规则是无歧义的规约，规定了如何从源语言描 述的源模型转换到目标语言描述的目标模型，目标模型的含义必须和源模型的含 6 一 m d a 中需求测试的一种方法 义一致。由于m d a 中的p i m 和p s m 都是使用特定的u m l 来描述，所以m d a 中的模型变换主要是u m l 模型的变换。 2 1 2m d a 的过程和优缺点 在目前实现m d a 的多数软件中，其实现过程主要集中在以下3 个步骤： ( 1 ) 用u m l 对应用领域进行高度抽象的建模，这个模型和实现它的技术( 或者 底层技术) 完全没有关系。这个模型我们称之为平台无关模型。 ( 2 ) 然后，p i m 将被转换为一个或多个平台相关模型。这个翻译的过程一般是 自动实现的。p s m 将用一个特定的实现技术来描述系统。它将用到这种技 术所提供的种种架构，l l o j e j b ，数据库模型，c o m 组件等等。 ( 3 ) 最后，p s m 将被翻译成源代码。因为每个p s m 已经完全依靠某种特定的技 术，这个步骤一般是比较简单的。 以往m d a 流程中最难的一步，是从p i m 生成一个p s m 。它要求要应用的基础 技术具有丰富且巩固的知识，另一方面，源模型必须具备自动生成p s m 所要求的 足够信息量。 实际上，在m d a 规范中，还存在更加抽象的模型c i m 模型。c i m 模型是m d a 基于计算无关视角建立的系统模型，用于描述系统需求、功能、行为和运行环境， 也称为业务模型。之所以被称为计算无关，主要c i m 侧重于表达系统的外部行为和 运行环境，而不是表现系统的内部结构和实现细节等相关内容。不过对于目前多 数软件都忽略这一模型。在本文的需求获取和测试过程中需求模型正是使用了这 种业务模型。 m d a 是一种较新的技术，它同样有一些优缺点，以及一些待解决的问题。 其中，m d a 的优点有： ( 1 ) 对建模的投资将更加持久的有效远长于目前实现它所应用的技术。这 将更有利于保护投资。 ( 2 ) 具有技术上的灵活性。 ( 3 ) 将不再受技术或应用所具有的不同变化周期的影响在m d a 的帮助 下，可以中立的保持两方面的多样性。 m d a 的缺点有： ( 1 ) m d a 意味着更多的“组装而不是“开发 一在为一个应用建立p i m 的 时候，基本上没有技术上的周旋空间。这对于今天的很多开发人员来说， 还是难以想象的。 ( 2 ) 软件开发的创造性在一定程度上减弱了。开发人员常常觉得，就一种新技 术展开争论，在技术的前沿工作，是十分吸引人的。可是在m d a 流程下， 第二章m d a 相关知识及用例驱动方法z 大量的工作是建立模型，这和具体的技术相距甚远，但符合对象管理组织 的建议。 ( 3 ) 潜在的不成熟性。u m l 2 0 还在幼年时代。m d a 工具出现的时间也相对很 短。这里还隐藏了很多风险。 在m d a 的开发过程中，还有很多有待解决的问题： ( 1 ) 数据和应用程序的移植：目前在商业领域经常需要面对的问题是，大量的 数据和应用程序如何向新的，m d a 为基础的系统中移植。纯粹的m d a 流 程将把数据模型和数据库表结构看成是技术细节。它们不应该对平台无关 模型( p i m ) 层产生任何影响那么，m d a 工具或生成器也负责生成数据 库脚本吗? ( 2 ) 软件维护：编制不同的发行版本，补丁或者升级，是对目前正在运行的程 序进行维护的重要组成部分。m d a 怎么处理这些问题呢? 每次进行一次 全新的安装? ( 3 ) 投资回报率：从什么样的环境和系统开始计算? 从应用m d a 的第二个项 目? 还是从第五个开始? ( 4 ) 购买软件架构还是自主开发? ( 5 ) 生成器和相关工具造成了对其生产商的依赖这种对生产商的依赖是 我们以往一直极力避免的。 ( 6 ) 企业应用整合：m d a 中模型高度的抽象，但是对于已经在运转的应用系 统，怎么得到这种抽象呢? 可以看到潜在很多实际问题。这些问题正是我们编写m d a 支持工具的原因： 在很多项目当中，某些以上的问题已经得到了实验性的回答，而在我们的项目开 发过程中，这些问题也逐步得到合理的解决方案。 2 2 1 软件需求 2 2 用例驱动的需求分析技术 随着软件技术的发展，计算机软件需求越来越复杂，规模也日益庞大，在软 件开发以及更新维护过程中，软件需求变更也成为必然。这时，传统的软件工程 开发模式已经不能满足用户的需求。进入9 0 年代以来，一种新的被称为“用户主 导，面向领域的需求分析方法”被提了出来，即如何从各种各样的应用专业领域 中特别是直接从最终用户处捕获需求，并完整、准确地予以描述与分析，需求工 程成为研究的热点之一。 8 一 m d a 中需求测试的一种方法 对本文来讲，如何更好的用户进行沟通，获取真实一致完整的需求，并以一 种适当的方式将需求描述出来，为需求测试提供便利，是本文研究的重点。因为 这些问题都与需求工程紧密相关，所以下面对需求工程的概念，重要性做出介绍。 ( 1 ) 软件需求工程 需求工程是随着计算机的发展而发展的，在计算机发展的初期，软件规模不 大，软件开发所关注的是代码编写，需求分析很少受到重视。后来软件开发引入 了生命周期的概念，需求分析成为其第一阶段。随着软件系统规模的扩大，需求 分析与定义在整个软件开发与维护过程中越来越重要，直接关系到软件的成功与 否。人们逐渐认识到需求分析活动不再仅限于软件开发的最初阶段，它贯穿于系 统开发的整个生命周期。8 0 年代中期，形成了软件工程的子领域需求工程 ( r e q u i r e m e n te n g i n e e r i n g ，r e ) 。进入9 0 年代以来，需求工程成为研究的热点之一。 从1 9 9 3 年起每两年举办一次需求工程国际研讨会，自1 9 9 4 年起每两年举办一次需 求工程国际会议，在1 9 9 6 年s p r i n g e r - v e r l a g 发行了一新的刊物 账户在步骤2 处重新加入基本 余额流 用例2场景4步骤2 提款金额 账户 不执行备选流3 ，执行基本 余额流 用例3场景4步骤2 提款金额= 账户不执行备选流3 ，执行基本 余额 流 对于8 个场景中的每一个场景都需要确定测试用例。可以采用矩阵或决策表来 确定和管理测试用例。表5 2 显示了一种通用格式，其中各行代表各个测试用例， 而各列则代表测试用例的信息。 下面是一个由用例生成测试用例的更符合实际情况的示例。 吴 客户 吴 o 转帐 吴 行系统 a t m 撮作员 系统启动 图5 3 用例图示例 该用例图描述了一台a t m 机正常工作时的参与者和用例。 下面是上图中提款用例的基本流和某些备用流。其中基本流为： 本用例的开端是a t m 处于准备就绪状态。 ( 1 ) 准备提款：客户将银行卡插入a t m 机的读卡机。 ( 2 ) 验证银行卡：a t m 机从银行卡的磁条中读取账户代码，并检查它是否属 于可以接收的银行卡。 ( 3 ) 输入p i n ：a t m 要求客户输入p i n 码( 4 位) 。 ( 4 ) 验证账户代码和p i n ：验证账户代码和p i n 以确定该账户是否有效以及 所输入的p i n 对该账户来说是否正确。对于此事件流，账户是有效的而 且p i n 对此账户来说正确无误。 第五章需求测试方法 3 9 _ 一 ( 5 ) a t m 选项：a t m 显示在本机上可用的各种选项。在此事件流中，银行 客户通常选择“提款”。 ( 6 ) 输入金额：要从a t m 中提取的金额。对于此事件流，客户需选择预设的 金额( 1 0 美元、2 0 美元、5 0 美元或1 0 0 美元1 。 ( 7 ) 授权：a t m 通过将卡i d 、p i n 、金额以及账户信息作为一笔交易发送给 银行系统来启动验证过程。对于此事件流，银行系统处于联机状态，而且 对授权请求给予答复，批准完成提款过程，并且据此更新账户余额。 ( 8 ) 出钞：提供现金。 ( 9 ) 返回银行卡：银行卡被返还。 ( 1 0 ) 收据：打印收据并提供给客户。a t m 还相应地更新内部记录。 用例结束时a t m 又回到准备就绪状态。备选事件流如表5 3 。 根据表5 3 ，在不进行迭代的情况下，我们需要测试提款用例能正确的实施， 那么以下的事件流必须能保证被正确的实施： 基本流：提取预设金额 各选流2 ：a t m 内没有现金 备选流3 ：a t m 内现金不足 备选流4 ：p i n 有误 备选流5 ：账户不存在账户类型有误 各选流6 ：账面金额不足 从上面的用例和事件流我们可以得到以下场景： 表5 4 场景描述表 场景1 ：成功的提款 基本流 场景2 ：a t m 内没有现金基本流备选流2 场景3 ：a t m 内现金不足基本流备选流3 场景4 ：p i n 有误( 还有输入机会)基本流备选流4 场景5 ：p i n 有误( 不再有输入机会)基本流备选流4 场景6 ：账户不存在账户类型有误基本流备选流5 场景7 ：账户余额不足基本流 备选流6 为方便起见，备选流3 和6 ( 场景3 和7 ) 内的循环以及循环组合未纳入上 表。对于这7 个场景中的每一个场景都需要确定测试用例。可以采用矩阵或决策 表来确定和管理测试用例。我们可以采用一种类似于表5 2 的通用格式，其中各行 代表各个测试用例，而各列则代表测试用例的信息。在本示例中，对于每个测试 用例，需要存在一个测试用例i d 、条件( 或说明) 、测试用例中涉及的所有数据元 素( 作为输入或已经存在于数据库中) 以及预期结果。 m d a 中需求测试的一种方法 表5 3 备选事件流表 备选流标事件发生条件和预期结果 号 1 银行卡无在基本流步骤2 验证银行卡中，如果卡是无效的，则卡被退 效回，同时会通知相关消息。 2a t m 内没 在基本流步骤5a t m 选项中，如果a t m 内没有现金，则 有现金“提款”选项将无法使用。 3a t m 内现 在基本流步骤6 输入金额中，如果a t m 机内金额少于请求 金不足提取的金额，则将显示一则适当的消息，并且在步骤6 中 输入金额处重新加入基本流。 4 p i n 有误 在基本流步骤4 验证账户和p i n 中，客户有三次机会输入 p i n 。如果p i n 输入有误，a t m 将显示适当的消息；如果 还存在输入机会，则此事件流在步骤3 中输入p i n 处重新 加入基本流。如果最后一次尝试输入的p i n 码仍然错误，则 该卡将被a t m 机保留，同时a t m 返回到准备就绪状态， 本用例终止。 5 账户不存在基本流步骤4 验证账户和p i n 中，如果银行系统返回的代 在码表明找不到该账户或禁止从该账户中提款，则a t m 显示 适当的消息并且在步骤9 中返回银行卡处重新加入基本流。 6 账面金额 在基本流步骤7 授权中，银行系统返回代码表明账户余额 不足少于在基本流步骤6 中输入金额内输入的金额，则a t m 显示适当的消息并且在步骤6 中输入金额处重新加入基本 流。 7 达到每日在基本流步骤7 授权中，银行系统返回的代码表明包括本 最大的提提款请求在内，客户已经或将超过在2 4 小时内允许提取的 款金额最多金额，则a t m 显示适当的消息并在步骤6 中输入金额 上重新加入基本流。 x记录错误如果在基本流步骤1 0 收据中，记录无法更新，则a t m 进 入“安全模式”，在此模式下所有功能都将暂停使用。同时 向银行系统发送一条适当的警报信息表明a t m 已经暂停工 作。 y退出 客户可随时决定终止交易( 退出) 。交易终止，银行卡随之退出。 z 翘起a t m 包含大量的传感器，用以监控各种功能，如电源检测器、 不同的门和出入口处的测压器以及动作检测器等。在任一时 刻，如果某个传感器被激活，则警报信号将发送给警方而且 a t m 进入“安全模式”，在此模式下所有功能都暂停使用， 直到采取适当的重启重新初始化的措施。 2 ) 用例图转换为顺序图 接下来介绍用例转换成顺序图的方法： 用例可以被转换成顺序副3 0 3 。本文简要介绍用例描述规范语言的语法，其 中要是分析1 3 种英文句式的结构并给出用例模型到顺序图的转换规则。 l i w ul i 给出了几条规则【3 2 】用以使用例描述更加规范化，我们也可以在研究中 第五章需求测试方法 使用这些规则。 a s h o m b y 等人在t h ea d v a n c e dl e a r n e r sd i c t i o n a r yo fc u r r e n te n g l i s h t 3 3 q b 给出了2 5 种英语句子的动词形式。l i w ul i 根据这2 5 种动词形式给出了1 3 种句 式结构【3 4 】。1 3 种句式如下： ( 1 ) s u b j e c tv e r b ( 2 ) s u b j e c tv e r bo b j e c t ( 3 ) s u b j e c tv e r bo b j e c t ( t o ) v e r b l ( o b j e c t l ) ( 4 ) s u b j e c tv e r bo b j e c ta d j e c t i v e ( 5 ) s u b j e c tv e r bo b j e c to b j e c t l ( 6 ) s u b j e c tv e r bo b j e c tc o n j u n c t i v et ov e r b l ( o b j e c t l ) ( 7 ) s u b j e c tv e r bg e r u n d ( o b j e c t ) ( 8 ) s u b j e c tv e r bo b j e c tp r e p o s i t i o no b j e c t l ( 9 ) s u b j e c tv e r bo b j e c to b j e c t l ( 10 ) s u b j e c tv e r b ( f o r ) c o m p l e m e n t ( 1 1 ) s u b j e c tv e r b ( 12 ) s u b j e c tb ep r e d i c a t i v e ( 13 ) s u b j e c tv e r bp r e p o s i t i o no b j e c t 为了描述用例中的事件流使用了l i 定义的这1 3 中旬式结构。 根据这1 3 种句式结构，同时由于用例描述表中对用例的描述使用规定的用例 描述规范语言的语法，就能判断用户所描述的事件属于哪一种句式，在判断出使 用了那种句式的基础上，可以在表5 5 【3 4 1 中找到对应的消息发送者和接受者，这样 就确定了它们之间的消息传递方向，据此来画出顺序图。 4 2 _ 一 m d a 中需求测试的种方法 表5 5 句式结构分析表 n o s y n t a c t i cs t r u c t u r e s e n d e rr e c e i v e ra c t i o n a r g u m e n t l s u b j e c tv e r bo b j e c ts u b j e c to b j e c to rt h e v e r b c l a s so fo b j e c t 2 s u b j e c tv e r bo b j e c t ( t o )s u b j e c to b j e c tv e r b ( + o b j e c t1 )( o b j e c t l ) v e r bl ( o b j e c t l ) 3 s u b j e c tv e r bo b j e c ts u b j e c to b j e c tp a r t i c i p l e( o b j e c t l ) p a r t i c i p l e ( o b j e c t1 )v e r b ( + o b j e c t l ) 4 s u b j e c tv e r bo b j e c ts u b j e c to b j e c t b ea d j e c t i v e a d j e c t i v e 5 s u b j e c tv e r bo b j e c ts u b j e c to b j e c ts e t + o b j e c t l( o b j e c t l ) o b j e c t l 6 s u b j e c tv e r bo b j e c ts u b j e c t v e r b o b j e c t ， c o n j u n c t i v et ov e r b l v e r bl ( + o b j e c ( o b j e c t l )t 1 ) 7 s u b j e c tv e r bg e r u n ds u b j e c t v e r bg e r u n d ( o b j e c 0v e r b ( + o b j e c t ) 8 s u b j e c tv e r bo b j e c ts u b j e c to b j e c t lv e r b + o b j e c t ( o b j e c t ) p r e p o s i t i o no b j e c t l 9 s u b j e c tv e r bo b j e c ts u b j e c to b j e c t v e r b o b j e c t l o b j e c t l l o s u b j e c tv e r b ( f o r )s u b j e c t v e r b c o m p l e m e n t c o m p l e m e n t 1 1 s u b j e c tv e r bs u b j e c t v e r b 1 2 s u b j e c tb ep r e d i c a t i v e s u b j e c tb e + p r e d i c a t i v e 1 3 s u b j e c tv e r bs u b j e c tv e r b + p r e p o s i t i o no b j e c t p r e p o s i t i o no b j e c t 例子：t h ea t mr e t u r n st h ec a r dt ot h ec u s t o m e r 根据句子的主谓宾结构，可以 判断这个句子符合句式8 “s u b j e c tv e r bo b j e c tp r e p o s i t i o no b j e c t l ”。对照表5 5 ，可 知“a t m 是消息的发送者，“c u s t o m e r 是消息的接收者，发送消息的动作是“r e t u r n t h ec a r d ”。据此可以画出转换后所得到的顺序图片段如图5 4 所示。 第五章需求测试方法 4 3 - 一 图5 4 转换的顺序图片段 3 ) 从顺序图中得到事件序列 从顺序图上的语义也可以类似地获取消息驱动的方法执行序列，这就要求我 们精化顺序图的语义，对顺序图上任意两个事件之间规定了其时间先后关系，这 样我们就可以将消息序列精化为事件序列。 我们的目的是事件执行序列，然后通过验证用例生成的测试用例中的系统预 期行为与事件执行序列的一致性就可以确定需求中是否存在与规约不一致的错 误。 顺序图用直观的消息序列来表示系统行为，但在运行时刻每一个消息都由一 个消息发送事件和一个消息接受事件组成，因而事件序列在更细粒度上表示的系 统的行为。但是由于描述的消息可能是异步消息，消息传递的时间长短不确定， 以及面向对象软件的多线程执行，使得消息之间的先后顺序只能决定同一消息的 发送事件先于相应的接受事件，不能预先确定不同消息的发送、接受事件之间的 先后顺序，一个对象只能控制自身发送消息事件的时间先后，对于接收消息事件， 由于系统的底层结构是未知的，因此接收消息的时间也是不确定的。很难直接从 顺序图上得到合理的事件序列，这正是由于顺序图在描述事件顺序时本身的语义 不精确，所以确定顺序图上所有事件可能的发生顺序是首先要解决的问题。顺序 图中事件的先后顺序应该通过每个对象生命线上的消息或事件的直观顺序以及对 象之间的消息交互约束推导出来。 顺序图上事件之间的先后顺序可以确定时，就可以确定特定场景下刻画系统 行为的事件序列。由于消息之间的约束导致有些事件之间存在特定的先后顺序关 系，因此并不是所有的事件序列都是顺序图允许的。本文将这个可能的事件序列 定义为预期执行轨迹，对应顺序图上的一条执行路径，从测试角度看，表示系统 的一个测试场景，我们定义为顺序图测试场景。 对于一个顺序图，一个顺序测试场景是顺序图上一个从起始事件开始到一个 终止事件结束的可能发生的事件序列 e 岛_ e 乞寸专e 。其中嵋是一个起始 事件，p 是个终止事件，= ( e t y p e ，s e n d e r ，r e c e i v e r ，m e t h o d ) 。其中e t y p e 为事 件类型，可用m e 、m e 分别表示发送消息事件、接收消息并执行方法事件，s e n d e r 、 m d a 中需求测试的一种方法 r e c e i v e r 表示该事件对应消息的发送者对象和接收者对象，m e t h o d 为该事件调用 的方法或者执行的方法p 5 1 。 用例图上描述的消息的错误实现可能导致交互中表现的行为发生偏差，从而 使顺序图与用例设计不一致，偏离软件规约规定的功能。可能造成顺序图中消息 名的编码错误、错误的参数、不正确的参数值、不正确的或缺少输出以及非预期 的运行时绑定导致的错误方法调用：消息前驱约束实现错误导致发送者对象发送 违反接受者对象前提条件的消息或者发送者对象发送违反接受者对象的顺序约束 的消息；消息的发送者或接受者对象错误导致错误的对象和消息的绑定。所以用 例描述中的信息未按设计正确转换会导致最终的顺序图与用例描述不一致，如果 用例图中存在错误，肯定是用例图的至少一条测试路径未被正确转换，要定位该 错误，在未知该错误在哪条测试路径上时，只能通过从用例描述中选择所有可能 的测试路径，并导出能够跟踪这些路径的测试用例，并将它们代入相应的事件序 列，比较该测试用例的预期输出和实际执行输出就可以确定实际行为与预期行为 的一致性，从而可以验证用例与顺序图的一致性。 对于一个顺序图，我们可以通过遍历顺序图中所有事件的所有可能的发生顺 序来得到顺序图的所有事件序列，这些事件序列都可以表示为消息发送或消息接 受序列，而本文研究的消息都是方法调用。所以预期的行为可以理解为是一个对 象向另一个对象发送方法调用请求，以及消息接受者对象接收消息事件表示为该 对象执行请求的方法，这样一来，这个事件序列就可以演化成一个方法调用和方 法执行的序列。而面向对象软件系统在运行时正表现为一个对象向另一对象发送 方法调用请求，并将控制权转给消息接受者对象，后者接管控制权