（计算机应用技术专业论文）基于uml的集成测试方法研究.pdf

浙江大学硕士学位论文摘要 摘要 面向对象软件功能的正常运行依靠程序代码中各个类之间成功的交互。单个 类运行正常，但是当它们结合在一起时也许会出现新的问题。本论文提出了一种加 强类之间集成测试的技术，这个技术结合了u m l 合作图和状态图自动生成中间测 试模型( c s t m ) 。c s t m 测试模型用来产生正确的测试路径，同时论文中定义了对 于从c s t m 测试模型中产生测试路径的覆盖准则。为了评估这项技术，论文中实 现了一个教学辅助系统的部分模块，并且引入突变测试技术来检查该模型的错误 侦测能力。结果显示对于比较高要求的测试，能达到较好的效果。 关键词集成测试，l # 4 l ，自动化测试 浙江大学硕士学位论文 a b s t r a c t a b s t r a c t c o r r e c tf u n c t i o n i n go fo b j e c t - o r i e n t e ds o f t w a r ed e p e n d su p o nt h e s u c c e s s f u l i n t e g r a t i o no fc l a s s e s w h i l ei n d i v i d u a lc l a s s e sm a yf u n c t i o nc o r r e c t l y s e v e r a ln e w f a u l t sc a l la r i s ew h e nt h e s ec l a s s e sa r ei n t e g r a t e dt o g e t h e r i nt h i sp a p e r , w ep r e s e n ta t e c h n i q u et oe n h a n c et e s t i n go fi n t e r a c t i o n sa m o n gm o d a lc l a s s e s t h et e c h n i q u e c o m b i n e su m lc o l l a b o r a t i o nd i a g r a m sa n ds t a t e c h a r t st oa u t o m a t i c a l l yg e n e r a t ea l l i n t e r m e d i a t et c s tm o d e l c a l l e dc s t m t h ec s t mi st h e nu s e dt og e n e r a t ev a l i dt e s t p a t h s w ea l s od e f i n ev a r i o u sc o v e r a c r i t e r i at og e n e r a t et e s tp a t h sf r o mt h ec s 田讧 m o d e l i no r d e rt oa s s e s so u rt e c h n i q u e ，w eh a v ed e v e l o p e dat o o ia n da p p l i e di tt oa c a s es t u d yt oi n v e s t i g a t ei t sf a u l td e t e c t i o nc a p a b i l i t y t h er e s u l t ss h o wt h a tt h e p r o p o s e dt e c h n i q u ee f f e c t i v e l y d e t e c t sa l lt h es e e d e d i n t e g r a t i o n f a u l t sw h e n c o m p l y i n gw i t ht h em o s td e m a n d i n ga d e q u a c yc r i t e r i o na n ds t i l la c h i e v e sr e a s o n a b l y g o o dr e s u l t sf o r1 e s se x p e n s i v ea d e q u a c yc r i t e r i a k e y w o r d s i n t e g r a t i o nt e s t i n g ，u m l ，a u t o m a t e dt e s t i n g 浙江大学硕士学位论文图表目录 图表目录 图2 _ l 一个航班顾客模型 图2 - 2 一个抵押关系模型 图3 - 1a t 系统类图 图3 - 2 测试流程 图4 - 1 眦w p r o b l 酬( ) 的合作图 图4 - 2s t o p w a t c h 状态图 图4 - 3l o g 状态图 图4 - 4c u t 4 p l e x l t y r e g u l a t o r 状态图 图4 - 5d 1 s p l a y i v l a n a g e r 状态图。 图4 - 6p e r f 0 蹦a n 旺r b g i i l t 僳状态图 图4 - 7n e w p r o b l e m ( ) 的c s t m 模型 图4 - 8 类c 状态图 表4 - 1a b 的值固定 表4 - 2b c 的值固定 表5 一l 类的信息 表5 - 2 引入错误的种类和数目 2 l 2 2 2 7 3 0 3 l 3 2 。3 2 3 3 。3 3 3 4 3 7 5 0 表5 3 每个测试组检测到的突变数目 表5 43 个测试准则下的最小值平均值和最大值与全路径下数值的比值 5 0 5 5 5 7 一5 8 5 8 浙江大学硕士学位论文第1 章绪论 第1 章绪论 1 1 课题背景 面向对象的技术因为能够解决传统程序设计语言的问题，自提出后，一度成 为研究热点，事实上采用面向对象技术减少了不少错误的发生，对于提高软件质 量起到了很大的作用，但是面向对象技术本身在任何情况下都不会排除软件测试 的动机，同时面向对象语言的本质特征，如继承、封装、和多态等，也带来了薪 的故障风险，并给软件测试提出了新的挑战【1 , 2 , 9 1 。区别于传统软件的功能分解， 面向对象软件是通过合成来构造软件的，因而集成是面向对象软件开发中最重要 的工作，面向对象软件构造过程中有的不同层次的集成，包括：从方法到类的集 成，类通过继承集成，类通过容器集成，类到组件的集成，组件到应用系统的集 成。在面向对象的迭代式增量开发过程中，通过不断的集成产生系统的可执行的 版本，但每一个集成的环节都可能引入错误，导致软件中存在缺陷，为了能够发 现软件集成中的问题，面向对象软件的集成测试非常重要 4 1 。对于传统软件的集 成测试，可以根据设计阶段形成的功能分解树，采用自顶向下或自底向上逐步测 试用经过测试的单元组装成系统的过程中有无错误1 3 1 。而面向对象软件采用的是 通过组合实现系统的功能，没有一个功能分解树可用，所以传统的基于功能分解 的集成测试策略不适合面向对象软件。要检验最终实现中各种集成是否与设计的 集成一致，则需要对每一个集成层次进行测试，而这里的集成分为结构集成和行 为集成，所以面向对象软件的集成测试包含结构集成测试和行为集成测试。结构 集成测试主要测试类的继承、类的容器、类的接口、组件的接口中有无错误；行 为集成测试主要是类内方法交互、类间方法交互、组件间交互是否被错误地实现。 测试工作的核心主要是生成测试用例，在面向对象软件开发过程中系统的规约、 设计、代码是生成测试的信息来源，是软件在其生命周期不同阶段的变体，当然 规约、设计、代码在每一阶段的测试中都起相应的作用，特别地，系统规约是生 浙江大学硕士学位论文第1 章绪论 成系统测试的测试用例的基础和系统测试的检验依据，软件代码是生成单元测试 用例的基础和单元测试的检验依据，系统设计是生成集成测试用例和集成测试的 检验依据。系统的设计信息有助于理解系统功能和结构，设计模型包含规约和程 序结构的信息，同时也描述了系统的相应功能片断的行为，因此也被称为灰盒。 可以结合白盒测试和黑盒测试方法，从设计信息生成集成测试用例，测试设计模 型表示的软件系统的灰盒行为。 u m l 是面向对象系统分析、设计的标准的建模语言，自从在1 9 9 7 年成为建 模语言事实上的标准后，就得到学术界的推崇和工业界的支持，使得u m l 广为 使用，基于u m l 的方法和实用技术的研究成为将来的发展趋势。u m l 对面向对 象软件开发全生命周期的支持也使得软件开发人员优先用它来描述系统嘲。正像 集许多优点的面向对象技术不能免除软件测试一样，使用u m l 进行面向对象软 件开发，在提高软件质量的同时，仍然需要测试来确认软件分析、设计、实现的 一致性和正确性。同时基于u m l 开发的软件系统，软件开发的分析、设计阶段 工作成果多为各种模型图，系统的可用信息都在这些模型图中，给信息的提取带 来了新的问题，从而也给测试带来新的课题。对测试而言，原先的基于规约或者 是基于程序的方法都不能直接使用，对基于u m l 模型的测试，要将问题转换到 原来传统测试方法可以处理的问题空间中加以解决，转换工作主要解决信息提取 问题，然后用常规测试方法生成测试。 1 2 国内外研究概况 下面介绍面向对象软件测试技术的研究中已经取得的有价值成果： 一类测试策略： 类是面向对象程序的基本构造单元。因此类的测试就成了测试面向对象软件 的关键。分开对类中方法进行单独测试，也即孤立的检查类中方法的正确性不足 以保证类在整体上是正确的，所以测试一个类中的方法能否正确交互是测试类的 一个重要方愿。目前国际上己提出了很多类的测试方法，主要分为三大类：基于数 2 浙江大学硕七学位论文 第l 章绪论 据流和控制流的白盒测试，基于状态的测试、基于公理规范的测试。 1 基于流图的类测试： 把传统的基于流图的测试技术应用于类测试，提出了一种构造类流图的框 架，在类流图中，节点表示操作，操作a 和操作b 之间的有向边表示允许某引用类 c l i e n t 在调用操作a 之后调用操作b ，确定节点间是否可以联边的依据是该类的规 约。例如，对一个堆栈类s t a c k ，创建一个空找的操作n e w 到退栈操作p o p 就不 能联边。对一些返回真假值的控制函数可以用作传统控制流图中的条件，在从这 些控制函数引出的边上加上真或假的标志。基于流图的类测试技术把传统的 基于流图的测试技术应用于类测试，完全依赖于类的实现，系统地而不是随机地 产生测试用例，且可全部自动化。 2 基于状态的类测试： 一个对象既有它的状态，又有它的行为，行为具体表现为状态的变化。主要 的面向对象建模方法常采用状态转移图s t d ( s t a t et r a n s i t i o nd i a g r a m ) 、 s t a t e c h a r t ，0 b i e c t c h a r t 或类似模m i 3 a 1 7 划对象的行为特征。鉴于此，一些学 者提出了基于状态的类的测试方法。基于状态的测试把被测对象看作一个有 限状态机( f s m ) ，从该f s m 导出测试用例。选择测试用例时可以利用基于f s m 的 测试所取得的研究成果。基于f s m 的测试源于通信协议的一致性测试问题，对该 问题的研究已取得了较丰硕的成果。对象状态测试方法的基本思想是，检查 对象的状态在执行某个方法或方法序列后是否会转移到预期的状态：如果对象到 达的状态不是预期的状态，则说明程序中含有错误。这里的“状态”有两种 定义方式：一种是设计状态( d e s i g n s t a t e s ) ，另一种是实现状态 ( i m p l e m e n t a t i o ns t a t e s ) ，分别对应于分析设计阶段和实现阶段所用的概念。 实现状态是指在实现层次由对象的属性值确定的状态；设计状态是指建模阶段所 认定的状态，处于较高的抽象层次，而不依赖于实现时的具体表示。t u r n e r 和 r o b s o n 认为，对于面向对象软件的测试来讲，基于状态的测试与基于程序的测 试( 白盒测试) 和常规意义的功能测试( 黑盒测试) 处于同等重要的地位，它介于白 盒和黑盒方法之间，是对白盒测试和黑盒测试的补充。 3 浙江大学硕士学位论文第l 章绪论 3 基于规约的类测试 以需求和功能规约为基础的类测试技术，通过分析软件的需求和功能规约来 选择和产生测试数据，重点测试一个作用于被测类的对象的消息序列是否将该对 象置于“正确”的状态。在这方面有一定影响的工作是d o o n g 和f r a n l d 提出的方法。 该方法根据类是抽象数据类型的实现这一原理，设计了一种和面向对象语言语法 相似的代数规约语言l o b a s 。l o b a s 语言书写的规约中，运算符分为三类：构造 符、转换符和观察符。若类c 用以实现抽象数据类型t ，n t 中的每一个函数和类 c 中的一个方法相对应，向函数输入一个t 类型的值对应于向类c 的对象发一信件， 被发送信件的对象称为目标对象，而被返回的对象称为返回对象。对过程来说， 目标对象和返回对象是同一对象( 但目标对象的部分状态可能被改变) 。对函数来 说，除了显式的返回对象外，目标对象实际上也是返回对象( 若函数无副作用，目 标对象的状态不变) 。其中，类c 中的方法对参数应是无副作用的。 二集成测试策略： 组成一个面向对象程序或类库的类之间有着错综复杂的关系，以怎样的方式 和次序将这些类集成到一起，是面向对象软件集成测试需要解决的重要课题。 k u n g 等人在文献【2 6 ，2 8 】提出了一种产生测试顺序的算法。利用该文献给出的测试 顺序号分配算法有助于测试资源的重用，减少构造s t u b 的工作量。a b d u r a z i k 等人 利用合作图对源代码进行静态检查来衡量一个测试用例的充分程度，这个方法把 传统的数据流和控制流分析和合作图相结合产生集成测试用例。b a s a n i c r ia n d b e r t o l i n o 利用用户交互测试模型( u i t ) 进行集成测试，u i t 产生自用例和u m l 顺序图，文献【2 】中对这种方法进行了改进。p i l s k a l n s 等人提出了一种使用用例图 和顺序图产生测试用例的方法，他们把用例图和顺序图转化为中间模型 ( o m d a g ) ，然后由这个中间模型产生集成测试用例。另一种基于u m l 的集成 测试技术由l et r a o n 12 】和j e r o n 等人提出，这个方法使用类图产生中间模型( t d g r a p h ) ，这个图有3 种依赖关系：类之间的依赖，类和方法之间的依赖，方法之 间的依赖，这种依赖关系进一步决定了类之间的前后顺序 从目前的研究现状来看，现有的针对面向对象软件测试的方法还存在许多问 4 浙江大学硕士学位论文第1 章绪论 题，并且有待进一步研究。本文提出了一种依靠对合作图中参与交互的类的所有 可能的状态进行统计来强化类集成测试的技术。为了达到这个目标，我们利用 u m l 合作图和状态图中类的交互信息建立了c s t m 测试模型。c s t m 对由消息 触发的所有可能的对象状态进行建模。测试生成器利用c s t m 模型产生测试路 径，相应的测试用例旨在检测那些在对象交互期间由于错误的对象状态而引发的 一些错误。 1 3 论文章节安排 本文的章节安排如下：第2 章需要用到的相关技术介绍，第3 章关于c s t m 测试模型概要，第4 章利用a t 系统作为例子讲解c s t m 测试模型实现过程。第 5 章对我们构建的系统进行测试，对结果进行分析。 5 浙江大学硕士学位论文第2 章软件测试相关技术 第2 章软件测试相关技术 2 1u m l 语言 面向对象的分析与设计( o o a & d ) 方法的发展在8 0 年代末至9 0 年代中出现了 一个高潮，u m l 是这个高潮的产物。它不仅统一了b o o c h 、r u m b a u g h 和j a c o b s o n 的表示方法，而且对其作了进一步的发展，并最终统一为大众所接受的标准建模语 言。 2 1 1 标准建模语言u m l 的出现 公认的面向对象建模语言出现于7 0 年代中期。从1 9 8 9 年到1 9 9 4 年，其数量 从不到十种增加到了五十多种。在众多的建模语言中，语言的创造者努力推崇自己 的产品，并在实践中不断完善。但是，o o 方法的用户并不了解不同建模语言的优缺 点及相互之间的差异，因而很难根据应用特点选择合适的建模语言，于是爆发了一 场”方法大战”。9 0 年代中，一批新方法出现了，其中最引人注目的是b o o c h l 9 9 3 、 o o s e 和o m t - 2 等。 b o o t h 是面向对象方法最早的倡导者之一，他提出了面向对象软件工程的概 念。1 9 9 1 年，他将以前面向a d a 的工作扩展到整个面向对象设计领域。b o o c h1 9 9 3 比较适合于系统的设计和构造。r u m b a u g h 等人提出了面向对象的建模技术( o m t ) 方法，采用了面向对象的概念，并引入各种独立于语言的表示符。这种方法用对象 模型、动态模型、功能模型和用例模型，共同完成对整个系统的建模，所定义的概 念和符号可用于软件开发的分析、设计和实现的全过程，软件开发人员不必在开发 过程的不同阶段进行概念和符号的转换。o m t - 2 特别适用于分析和描述以数据为 中心的信息系统。 j a c o b s o n 于1 9 9 4 年提出了o o s e 方法，其最大特点是面向用例( u s e c a s o ，并 6 浙江大学硕士学位论文第2 章软件测试相关技术 在用例的描述中引入了外部角色的概念。用例的概念是精确描述需求的重要武器， 但用例贯穿于整个开发过程，包括对系统的测试和验证。o o s e 比较适合支持商业 工程和需求分析。此外，还有c o a d y o u r d o n 方法，即著名的o o a o o d ，它是最早的 面向对象的分析和设计方法之一。该方法简单、易学，适合于面向对象技术的初学 者使用，但由于该方法在处理能力方面的局限，目前已很少使用。 概括起来，首先，面对众多的建模语言，用户由于没有能力区别不同语言之间的 差别。因此很难找到一种比较适合其应用特点的语言；其次，众多的建模语言实际上 各有千秋；第三，虽然不同的建模语言大多类同，但仍存在某些细微的差别，极大地 妨碍了用户之间的交流。因此在客观上，极有必要在精心比较不同的建模语言优缺 点及总结面向对象技术应用实践的基础上，组织联合设计小组，根据应用需求，取其 精华，去其糟粕，求同存异，统一建模语言。 1 9 9 4 年1 0 月，g r a d yb o o e h 和j i mr u m b a u g h 开始致力于这一工作。他们首先 将b o o c h 9 3 和o m t - 2 统一起来，并于1 9 9 5 年1 0 月发布了第一个公开版本，称之为 统一方法u m0 8 ( u n i t i e dm e t h o d ) 。1 9 9 5 年秋，o o s e 的创始人i v a rj a c o b s o n 加盟 到这一工作。经过b o o e h 、r u m b a u g h 和j a c o b s o n 三人的共同努力，于1 9 9 6 年6 月和1 0 月分别发布了两个新的版本，即u m l0 9 和u m lo 9 1 ，并将u m 重新命名 为u m l ( u n i f i e dm o d e l i n gl a n g u a g e ) 。1 9 9 6 年，一些机构将u m l 作为其商业策略 已日趋明显。u m l 的开发者得到了来自公众的正面反应，并倡议成立了u m l 成员 协会，以完善、加强和促进u m l 的定义工作。当时的成员有d e c 、h p 、l - l o g i x 、 i t e l l i e o r p ，i b m ，i c o nc o m p u t i n g 、m c is y s t e m h o u s e 、m i c r o s o f t ，o r a c l e ，r a t i o n a l s o f t w a r e 、t i 以及u n i s y s 。这一机构对u m l1 0 ( 1 9 9 7 年1 月) 及u m l1 1 ( 1 9 9 7 年 1 1 月1 7 日) 的定义和发布起了重要的促进作用。 u m l 是一种定义良好、易于表达、功能强大且普遍适用的建模语言。它溶 入了软件工程领域的新思想、新方法和新技术。它的作用域不限于支持面向对象 的分析与设计，还支持从需求分析开始的软件开发的全过程。 在美国，截止1 9 9 6 年l o 月，u m l 获得了工业界、科技界和应用界的广泛支持， 已有7 0 0 多个公司表示支持采用u m l 作为建模语言。1 9 9 6 年底，u m l 已稳占面 7 浙江大学硕士学位论文第2 章软件测试相关技术 向对象技术市场的8 5 ，成为可视化建模语言事实上的工业标准。1 9 9 7 年1 1 月1 7 日o m g 采纳u m l1 1 作为基于面向对象技术的标准建模语言。u m l 代表了面 向对象方法的软件开发技术的发展方向，具有巨大的市场前景，也具有重大的经济 价值和国防价值。 2 1 2 标准建模语言u 虬的内容 首先，u m l 融合了b o o e h 、o m t 和o o s e 方法中的基本概念，而且这些基本概 念与其他面向对象技术中的基本概念大多相同，因而，u m l 必然成为这些方法以及 其他方法的使用者乐于采用的一种简单一致的建模语言；其次，u m l 不仅仅是上述 方法的简单汇合，而是在这些方法的基础上广泛征求意见，集众家之长，几经修改而 完成的，u m l 扩展了现有方法的应用范围；第三，u m l 是标准的建模语言，而不是标 准的开发过程。尽管u m l 的应用必然以系统的开发过程为背景，但由于不同的组 织和不同的应用领域，需要采取不同的开发过程。 作为一种建模语言，u m l 的定义包括u m l 语义和u m l 表示法两个部分。 ( 1 ) u m l 语义描述基于u m l 的精确元模型定义。元模型为u m l 的所有元 素在语法和语义上提供了简单、一致、通用的定义性说明，使开发者能在语义上取 得一致，消除了因人而异的最佳表达方法所造成的影响。此外u m l 还支持对元模 型的扩展定义。 ( 2 ) u m l 表示法定义u m l 符号的表示法，为开发者或开发工具使用这些图 形符号和文本语法为系统建模提供了标准。这些图形符号和文字所表达的是应用 级的模型，在语义上它是u m l 元模型的实例。 标准建模语言u m l 的重要内容可以由下列五类图( 共9 种图形) 来定义： 第一类是用例图，从用户角度描述系统功能，并指出各功能的操作者。 第二类是静态l 虱( s t a t i ed i a g r a m ) ，包括类图、对象图和包图。其中类图描述系 统中类的静态结构。不仅定义系统中的类，表示类之间的联系如关联、依赖、聚合 等，也包括类的内部结构( 类的属性和操作) 。类图描述的是一种静态关系，在系统的 8 浙江大学硕士学位论文 第2 章软件测试相关技术 整个生命周期都是有效的。对象图是类图的实例，几乎使用与类图完全相同的标 识。他们的不同点在于对象图显示类的多个对象实例，而不是实际的类。一个对象 图是类图的一个实例。由于对象存在生命周期，因此对象图只能在系统某一时间段 存在。包由包或类组成，表示包与包之间的关系。包图用于描述系统的分层结构。 第三类是行为图( b e h a v i o rd i a g r a m ) ，描述系统的动态模型和组成对象间的交 互关系。其中状态图描述类的对象所有可能的状态以及事件发生时状态的转移条 件。通常，状态图是对类图的补充。在实用上并不需要为所有的类画状态图，仅为 那些有多个状态其行为受外界环境的影响并且发生改变的类画状态图。而活动图 描述满足用例要求所要进行的活动以及活动问的约束关系，有利于识别并行活动。 第四类是交互图( i n t e r a c t i v ed i a g r a m ) ，描述对象间的交互关系。其中顺序图显 示对象之间的动态合作关系，它强调对象之间消息发送的顺序，同时显示对象之问 的交互：合作图描述对象间的协作关系，合作图跟顺序图相似，显示对象间的动态合 作关系。除显示信息交换外，合作图还显示对象以及它们之间的关系。如果强调时 间和顺序，则使用顺序图；如果强调上下级关系，则选择合作图。这两种图合称为交 互图。 第五类是实现图( i m p l e m e n t a t i o nd i a g r a m ) 。其中构件图描述代码部件的物理 结构及各部件之间的依赖关系。一个部件可能是一个资源代码部件、一个二进制 部件或一个可执行部件。它包含逻辑类或实现类的有关信息。部件图有助于分析 和理解部件之间的相互影响程度。 配置图定义系统中软硬件的物理体系结构。它可以显示实际的计算机和设备 ( 用节点表示) 以及它们之间的连接关系，也可显示连接的类型及部件之问的依赖 性。在节点内部，放置可执行部件和对象以显示节点跟可执行软件单元的对应关 系。 从应用的角度看，当采用面向对象技术设计系统时，首先是描述需求；其次根据 需求建立系统的静态模型，以构造系统的结构；第三步是描述系统的行为。其中在 第一步与第二步中所建立的模型都是静态的，包括用例图、类图( 包含包) 、对象图、 组件图和配置图等五个图形，是标准建模语言u m l 的静态建模机制。其中第三步 9 浙江大学硕士学位论文 第2 章软件测试相关技术 中所建立的模型或者可以执行，或者表示执行时的时序状态或交互关系。它包括状 态图、活动图、顺序图和合作图等四个图形，是标准建模语言u m l 的动态建模机 制。因此，标准建模语言u m l 的主要内容也可以归纳为静态建模机制和动态建模 机制两大类。 2 1 - 3 标准建模语言i j m l 的特点 标准建模语言u m l 的主要特点可以归结为三点： ( 1 ) u m l 统一了b o o e h 、o m t 和o o s e 等方法中的基本概念。 ( 2 ) u m l 还吸取了面向对象技术领域中其他流派的长处，其中也包括非0 0 方 法的影响。u m l 符号表示考虑了各种方法的图形表示，删掉了大量易引起混乱的、 多余的和极少使用的符号，也添加了一些新符号。因此，在u m l 中汇入了面向对象 领域中很多人的思想。这些思想并不是u m l 的开发者们发明的，而是开发者们依 据最优秀的0 0 方法和丰富的计算机科学实践经验综合提炼而成的。 ( 3 ) u m l 在演变过程中还提出了一些新的概念。在u m l 标准中新加了模板 ( s t e r e o t y p e s ) 、职责( r e s p o n s i b i l i t i e s ) 、扩展机s j j ( e x t e n s i b i l i t ym e c h a n i s m s ) 、线程 ( t h r e a ds ) 、过程( p r o c e s s e s ) 、分布式( d i s t r i b u t i o n ) 、并发( c o n c u r r e n c y ) 、模式 ( p a t t e r n s ) 、合作( c o l l a b o r a t i o n s ) 、活动图( a c t i v i t yd i a g r a m ) 等新概念，并清晰地区 分类型( t y p e ) 、类( c l a s s ) 和实例( i n s t a n t ) 、细化( r e f i n e m e n t ) 、接( i n t e r f a c e s ) 和组 件( c o m p o n e n t s ) 等概念。 2 1 4 标准建模语言u 虹的应用领域 u m l 的目标是以面向对象图的方式来描述任何类型的系统，具有很宽的应 用领域。其中最常用的是建立软件系统的模型，但它同样可以用于描述非软件领 域的系统，如机械系统、企业机构或业务过程，以及处理复杂数据的信息系统、 具有实时要求的工业系统或工业过程等。总之，u m l 是一个通用的标准建模语言， 1 0 浙江大学硕士学位论文第2 章软件测试相关技术 可以对任何具有静态结构和动态行为的系统进行建模。此外, u m l 适用于系统开 发过程中从需求规格描述到系统完成后测试的不同阶段。在需求分析阶段，可以用 用例来捕获用户需求。通过用例建模，描述对系统感兴趣的外部角色及其对系统 ( 用例) 的功能要求。分析阶段主要关心问题域中的主要概念( 如抽象、类和对象等) 和机制，需要识别这些类以及它们相互问的关系，并用u m l 类图来描述。 为实现用例，类之间需要协作，这可以用u m l 动态模型来描述。在分析阶段， 只对问题域的对象( 现实世界的概念) 建模，而不考虑定义软件系统中技术细节的类 ( 如处理用户接口、数据库、通讯和并行性等问题的类) 。这些技术细节将在设计 阶段引入，因此设计阶段为构造阶段提供更详细的规格说明。编程( 构造) 是一个独 立的阶段，其任务是用面向对象编程语言将来自设计阶段的类转换成实际的代码。 在用u m l 建立分析和设计模型时，应尽量避免考虑把模型转换成某种特定的编程 语言。因为在早期阶段，模型仅仅是理解和分析系统结构的工具，过早考虑编码问 题十分不利于建立简单正确的模型。 u m l 模型还可作为测试阶段的依据。系统通常需要经过单元测试、集成测 试、系统测试和验收测试。不同的测试小组使用不同的u m l 图作为测试依据：单 元测试使用类图和类规格说明；集成测试使用部件图和合作图；系统测试使用用 例图来验证系统的行为，验收测试由用户进行，以验证系统测试的结果是否满足 在分析阶段确定的需求。 总之，标准建模语言u m l 适用于以面向对象技术来描述任何类型的系统， 而且适用于系统开发的不同阶段，从需求规格描述直至系统完成后的测试和维 护。 2 2 测试用例和测试覆盖 2 2 1 测试用例 随着中国软件业的日益壮大和逐步走向成熟，软件测试也在不断发展。从最 浙江大学硕士学位论文 第2 章软件测试相关技术 初的由软件编程人员兼职测试到软件公司组建独立专职测试部门。测试工作也从 简单测试演变为包括：编制测试计划、编写测试用例、准备测试数据、编写测试 脚本、实施测试、测试评估等多项内容的正规测试。测试方式则由单纯手工测试 发展为手工、自动兼之，并有向第三方专业测试公司发展的趋势。 一、测试用例是软件测试的核心 软件测试的重要性是毋庸置疑的。但如何以最少的人力、资源投入，在最短 的时间内完成测试，发现软件系统的缺陷，保证软件的优良品质，则是软件公司 探索和追求的目标。每个软件产品或软件开发项目都需要有一套优秀的测试方案 和测试方法。 影响软件测试的因素很多，例如软件本身的复杂程度、开发人员( 包括分析、 设计、编程和测试的人员) 的素质、测试方法和技术的运用等等。因为有些因素 是客观存在的，无法避免。有些因素则是波动的、不稳定的，例如开发队伍是流 动的，有经验的走了，新人不断补充进来；一个具体的人工作也受情绪等影响， 等等。如何保障软件测试质量的稳定? 有了测试用例，无论是谁来测试，参照测 试用例实施，都能保障测试的质量。可以把人为因素的影响减少到最小。即便最 初的测试用例考虑不周全，随着测试的进行和软件版本更新，也将日趋完善。 因此测试用例的设计和编制是软件测试活动中最重要的。测试用例是测试工 作的指导，是软件测试的必须遵守的准则。更是软件测试质量稳定的根本保障。 二、什么叫测试用例 测试用例( t e s tc a s e ) 目前没有经典的定义。比较通常的说法是：指对一 项特定的软件产品进行测试任务的描述，体现测试方案、方法、技术和策略。内 容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等，并 形成文档。 不同类别的软件，测试用例是不同的。不同于诸如系统、工具、控制，游戏 软件，管理软件的用户需求更加不统一，变化更大、更快。笔者主要从事企业管 理软件的测试。因此我们的做法是把测试数据和测试脚本从测试用例中划分出 浙江大学硕士学位论文第2 章软件测试相关技术 来。测试用例更趋于是针对软件产品的功能、业务规则和业务处理所设计的测试 方案。对软件的每个特定功能或运行操作路径的测试构成了一个个测试用例。 三、编制测试用例 着重介绍一些编制测试用例的具体做法。 1 、测试用例文档 编写测试用例文档应有文档模板，须符合内部的规范要求。测试用例文档将 受制于测试用例管理软件的约束。软件产品或软件开发项目的测试用例一般以该 产品的软件模块或子系统为单位，形成一个测试用例文档，但并不是绝对的。 测试用例文档由简介和测试用例两部分组成。简介部分编制了测试目的、测 试范围、定义术语、参考文档、概述等。测试用例部分逐一列示各测试用例。每 个具体测试用例都将包括下列详细信息：用例编号、用例名称、测试等级、入口 准则、验证步骤、期望结果( 含判断标准) 、出口准则、注释等。以上内容涵盖 了测试用例的基本元素：测试索引，测试环境，测试输入，测试操作，预期结果， 评价标准。 2 、测试用例的设置 我们早期的测试用例是按功能设置用例。后来引进了路径分析法，按路径设 置用例。目前演变为按功能、路径混合模式设置用例。按功能测试是最简捷的， 按用例规约遍历测试每一功能。对于复杂操作的程序模块，其各功能的实施是相 互影响、紧密相关、环环相扣的，可以演变出数量繁多的变化。没有严密的逻辑 分析，产生遗漏是在所难免。路径分析是一个很好的方法，其最大的优点是在于 可以避免漏测试。 但路径分析法也有局限性。在一个非常简单字典维护模块就存在十余条路 径。一个复杂的模块会有几十到上百条路径是不足为奇的。笔者以为这是路径分 析比较合适的使用规模。若一个子系统有十余个或更多的模块，这些模块相互有 关联。再采用路径分析法，其路径数量成几何级增长，达5 位数或更多，就无法 使用了。那么子系统模块间的测试路径或测试用例还是要靠传统方法来解决。这 是按功能、路径混合模式设置用例的由来。 浙江大学硕士学位论文 第2 章软件捌试相关技术 3 、设计测试用例 测试用例可以分为基本事件、备选事件和异常事件。设计基本事件的用例， 应该参照用例规约( 或设计规格说明书) ，根据关联的功能、操作按路径分析法 设计测试用例。而对孤立的功能则直接按功能设计测试用例。基本事件的测试用 例应包含所有需要实现的需求功能，覆盖率达1 0 0 0 , 6 。 设计备选事件和异常事件的用例，则要复杂和困难得多。例如，字典的代码 是唯一的，不允许重复。测试需要验证：字典新增程序中已存在有关字典代码的 约束，若出现代码重复必须报错，并且报错文字正确。往往在设计编码阶段形成 的文档对备选事件和异常事件分析描述不够详尽。而测试本身则要求验证全部非 基本事件，并同时尽量发现其中的软件缺陷。 可以采用软件测试常用的基本方法：等价类划分法、边界值分析法、错误推 测法、因果图法、逻辑覆盖法等设计测试用例。视软件的不同性质采用不同的方 法。如何灵活运用各种基本方法来设计完整的测试用例，并最终实现暴露隐藏的 缺陷，全凭测试设计人员的丰富经验和精心设计。 四、测试用例在软件测试中的作用 1 、指导测试的实施 测试用例主要适用于集成测试、系统测试和回归测试。在实施测试时测试用 例作为测试的标准，测试人员一定要按照测试用例严格按用例项目和测试步骤逐 一实旄测试。并对测试情况记录在测试用例管理软件中，以便自动生成测试结果 文档。 根据测试用例的测试等级，集成测试应测试那些用例，系统测试和回归测试 又该测试那些用例，在设计测试用例时都已作明确规定，实施测试时测试人员不 能随意作变动。 2 、规划测试数据的准备 在我们的实践中测试数据是与测试用例分离的。按照测试用例配套准备一组 或若干组测试原始数据，以及标准测试结果。尤其象测试报表之类数据集的正确 1 4 浙江大学硕士学位论文第2 章软件测试相关技术 性，按照测试用例规划准备测试数据是十分必须的。除正常数据之外，还必须根 据测试用例设计大量边缘数据和错误数据。 3 、编写测试脚本的”设计规格说明书” 为提高测试效率，软件测试已大力发展自动测试。自动测试的中心任务是编 写测试脚本。如果说软件工程中软件编程必须有设计规格说明书，那么测试脚本 的设计规格说明书就是测试用例。 4 、评估测试结果的度量基准 完成测试实施后需要对测试结果进行评估，并且编制测试报告。判断软件测 试是否完成、衡量测试质量需要一些量化的结果。例：测试覆盖率是多少、测试 合格率是多少、重要测试合格率是多少，等等。以前统计基准是软件模块或功能 点，显得过于粗糙。采用测试用例作度量基准更加准确、有效。 5 、分析缺陷的标准 通过收集缺陷，对比测试用例和缺陷数据库，分析确证是漏测还是缺陷复现。 漏测反映了测试用例的不完善，应立即补充相应测试用例，最终达到逐步完善软 件质量。而已有相应测试用例，则反映实施测试或变更处理存在问题。 五、相关问题 1 、测试用例的评审 测试用例是软件测试的准则，但它并不是一经编制完成就成为准则。测试用 例在设计编制过程中要组织同级互查。完成编制后应组织专家评审，需获得通过 才可以使用。评审委员会可由项目负责人、测试、编程、分析设计等有关人员组 成，也可邀请客户代表参加。 2 、测试用例的修改更新 测试用例在形成文档后也还需要不断完善。主要来自三方面的缘故：第一、 在测试过程中发现设计测试用例时考虑不周，需要完善；第二、在软件交付使用 后反馈的软件缺陷，而缺陷又是因测试用例存在漏洞造成；第三、软件自身的新 增功能以及软件版本的更新，测试用例也必须配套修改更新。 1 5 浙江大学硕士学位论文 第2 章软件测试相关技术 一般小的修改完善可在原测试用例文档上修改，但文档要有更改记录。软件 的版本升级更新，测试用例一般也应随之编制升级更新版本。 3 、测试用例的管理软件 运用测试用例还需配备测试用例管理软件。它的主要功能有三个：第一、能 将测试用例文档的关键内容，如编号、名称等等自动导入管理数据库，形成与测 试用例文档完全对应的记录；第二、可供测试实施时及时输入测试情况；第三、 最终实现自动生成测试结果文档，包含各测试度量值，测试覆盖表和测试通过或 不通过的测试用例清单列表。 有了管理软件，测试人员无论是编写每日的测试工作e t 志、还是出软件测试 报告，都会变得轻而易举。 2 2 2 测试覆盖 测试覆盖是对测试完全程度的评测， 执行代码的覆盖表示的。通过覆盖指标， 问题。 是由测试需求和测试用例子的覆盖或已 就可以回答”测试的完全程度如何”这一 现阶段，随着软件开发过程的规范化，越来越多的软件公司加强了对软件测 试的重视，希望通过测试，能够使发布的系统更安全、更稳定、更符合用户的需 求。然而大家都知道，从理论上讲测试是永无止境的，只要不断测试就一定能不 断发现问题。那究竟如何度量测试的进度，如何判断测试可以完结，这些，可以 依靠测试覆盖率的分析来实现。 软件测试覆盖包括分支覆盖，语句覆盖以及条件覆盖，这是白盒测试中一个 很基本的测试概念。 一、最常用的覆盖评测 目前最常用的覆盖评测是基于需求的测试覆盖和基于代码的测试覆盖。简单 的说，测试覆盖是就需求( 基于需求的) 或代码的设计实施标准( 基于代码的) 而言的完全程度的任意评测，如已设定测试用例的核实( 基于需求的) 或所有代 码行的执行( 基于代码的) 。 1 、基于需求的测试覆盖 1 6 浙江大学硕士学位论文第2 章软件测试相关技术 如果需求已经完全分类，则基于需求的覆盖策略可能足以生成测试完全程度 的可计量评测。例如，如果已经确定了所有性能测试需求，则可以引用测试结果 来得到评测，如已经核实了7 5 的性能测试需求。基于需求的测试覆盖在测试 生命周期中要评测多次，并在测试生命周期的里程碑处提供测试覆盖的标识( 如 已计划的、已实施的、已执行的和成功的测试覆盖) 。 测试覆盖通过以下公式计算： 测试覆盖= t ( p ，x ，x ) r f r 其中： t 是用测试过程或测试用例表示的测试( t e s t ) 数( 己计划的、已实施的或成功 的) 。 r f r 是测试需求( r e q u i r e m e n t f o r t e s t ) 的总数。 在制订测试计划活动中，将计算测试覆盖以决定已计划的测试覆盖，其计算 方法如下： 测试覆盖( 已计划的) = t p r f r 其中： t p 是用测试过程或测试用例表示的已计划测试( t e s t ) 数。 r f r 是测试需求( r e q u i r e m e n t f o r t e s t ) 的总数。 在实施测试活动中，由于测试过程正在实施中( 按照测试脚本) ，在计算测 试覆盖时使用以下公式： 测试覆盖( 己执行的) = t i r 仃 其中： t i 是用测试过程或测试用例表示的已执行的测试( t e s t ) 数。 r f r 是测试需求( r e q u i r e m e n t f o r t e s t ) 的总数。 在执行测试活动中，使用两个测试覆盖评测，一个确定通过执行测试获得的 测试覆盖，另一个确定成功的测试覆盖( 即执行时未出现失败的测试，如没有出 现缺陷或意外结果的测试) 。 这些覆盖评测通过以下公式计算： 1 7 浙江大学硕士学位论文第2 章软件测试相关技术 测试覆盖( 已执行的) = t x r 丌 其中： t 是用测试过程或测试用例表示的已执行的测试( t e s t ) 数。 r f r 是测试需求( r e q u i r