（计算机应用技术专业论文）面向对象的软件测试方法研究.pdf

摘要 随着面向对象软件开发方法的广泛应用，面向对象软件测试方法也得到了人 们的广泛重视。由于面向对象自身的特征，传统的测试方法已不再适用于面向对 象的软件测试，因此，必须找出一种适合于面向对象软件的测试方法，这便给测 试增加了难度。本文以面向对象软件的特点为依据，讨论了面向对象软件测试层 次划分和测试方法等问题，并提出了一种测试用例生成的具体解决方法。 软件测试是保障软件质量的有效手段，面向对象软件测试是面向对象软件开 发的不可缺少的一环，是保证软件质量、提高软件可靠性的关键。面向对象软件 测试的整体目标和传统软件测试的目标是一致的，即以最小的工作量发现尽可能 多的错误。但由于面向对象程序本身所具有的封装性、继承性、多态性、动态绑 定等特性，使得面向对象软件测试的策略和内容有很大不同。 本文将u m l 与统一软件开发过程有效结合起来，针对面向对象软件测试的各 个阶段特点，在软件开发迭代的基础上，采用不同的u m l 图来讨论测试各个阶段 中测试用例的生成方法。其中重点讨论了类簇级测试阶段的测试用例生成方法， 该方法以分析、设计阶段的顺序图为基础：然后结合j 顿序图中交互的类的状态图 合并成组合状态图；最后对组合状态图进行优化，在优化后的状态图的基础上生 成测试用例。 关键词：面向对象；软件测试；类簇级；顺序图；状态图 a b s t r a c t w i t ht h ew i d e l yu s e do ft h e o b j e c t - o r i e n t e dd e v e l o p i n gm e t h o d ，t h e o b j e c t o r i e n t e ds o f t w a r et e s t i n gi sg e t t i n gm o r ea n dm o r ea t t e n t i o l lb ym a n i nv i r t u e o fo b j e c t o r i e n t e ds o f t w a r e sf e a t u r e s ，t h et r a d i t i o n a ls o f t w a r et e s t i n gm e t h o d sa r e n o ta d a p tt ot h eo b j e c t - o r i e n t e dt e s t i n g , m a k et h es o f t w a r et e s t i n gm o r ed i f f i c u l t ， b a s e do nt h ec h a r a c t e r i s t i c so fo b j e c t - o r i e n t e ds o f t w a r e ，t h ea r t i c l ed i s c u s s e st h e t e s t i n gl a y e r sa n dm e t h o d sf o ro b j e c t o r i e n t e ds o f t w a r et e s t i n ga n dg e n e r a t e st h e s p e c i f i cs o l u t i o n sf o rt e s tc a s e s o f t w a r et e s t i n gi se f f e c t i v eo ns o f t w a r eq u a l i t y o b j e c t - o r i e n t e ds o f t w a r et e s t i n g i si n d i s p e n s a b l et ot h ed e v e l o p m e n to fo b j e c to r i e n t e ds o f t w a r e ，a n di ti st h ek e yt o s o f t w a r eq u a l i t ya n dr e l i a b i l i t y t h em a i nt a r g e to fo b j e c t - o r i e n t e ds o t t w a r et e s t i n gi s t h es a m eo ft h et r a d i t i o n a ls o r w a r et e s t i n g ，n a m e l y , t of i n dt h ep o s s i b l en u m b e ro f e r r o r si nt h es m a l l e s tw o r k l o a d b u tb e c a u s eo ft h eo b j e c t - o r i e n t e dc h a r a c t e r s ，s u c h a se n c a p s u l a t i o n ，i n h e r i t a n c e ，p o l y m o r p h i s ma n dd y n a m i cb i n d i n ge r e ，m a k et h e o b j e c t o r i e n t e ds o f t w a r et e s t i n gs t r a t e g i e sa n dc o n t e n tq u i t ed i f f e r e n t t h i sp 印e rw i l le f f e c t i v e l yc o m b i n et h eu m la n dr a t i o n a lu n i f i e dp r o c e s s ( r u p ) ，i np u p o nt h eb a s i so fi t e r a t i v e ，i n t r o d u c ed i f f e r e mu m ld i a g r a m sa i ma tt h e o b j e c t - o r i e n t e df e a t u r e so ft h ev a r i o u sp h a s e so fs o f t w a r et e s t i n ga n dd i s c u s st h e m e t h o d so f t h ed i f f e r e n ts t a g e so f t h et e s tc a s eg e n e r a t i o n t h e r ei n t o ，t h ee m p h a s i so f r e s e a r c hi sc l u s t e r st e s t i n g t h em e t h o do nt h eb a s eo ft h ea n a l y s i s ，t h ed e s i g np h a s e s e q u e n c ed i a g r a m ；t h e n , c o m b i n ec l a s s ss t a t ed i a g r a mi nt h es e q u e n c ei n t e r a c t i v e d i a g r a mt o c o m b i n e ds t a t e d i a g r a m ；f i n a l l y , w i t ht h e c o m b i n e ds t a t ed i a g r a m o p t i m i z i n g ，a n dt h et e s tc a s eg e n e r a t i o no nt h eb a s i so f i t k e yw o r d s ：o b j e c t o r i e n t e d ；s o f t w a r et e s t i n g ；c l u s t e r ；s e q u e n c ed i a g r a m ；s t a t e d i a g r a m 独创性声明 本人声明所呈交的学位论文是本人在导师指导下进行的研究 工作及取得的研究成果。据我所知，除了文中特别加以标注和致谢 的地方外，论文中不包含其他入已经发表或撰写过的研究成果，也 不包含为获得东北师范大学或其他教育机构的学位或证书而使用 过的材孝斗。与我一同工作的同志对本研究所做的任何贡献均已在论 文中作了明确的说明并表示谢意。 学位论文作者签名：叠：茎! 垒日期：丝| z ! 三：! 兰 学位论文版权使用授权书 本学位论文作者完全了解东北师范大学有关保留、使用学位论 文的规定，即：东北师范大学有权保留并向国家有关部门或机构送 交学位论文的复印件和磁盘，允许论文被查阅和借阅。本人授权东 北师范大学可以将学位论文的全部或部分内容编入有关数据库进 行检索，可以采用影印、缩印或其它复制手段保存、汇编学位论文。 ( 保密的学位论文在解密后适用本授权书) 学位论文作者毕业后去向： 工作单位： 通讯地址： 电话： 邮编： 第一章软件测试概述和现状分析 1 1 软件测试概述 信息技术的飞速发展，使软件产品应用到社会的各个领域。且规模越来越庞 大，软件产品的质量自然成为人们共同关注的焦点。原先以手工作坊式方法开发 出来的许多软件产品，由于缺乏科学的软件质量管理，因此几乎无法维护，造成 大量人力、物力浪费。如何提高软件质量，保证软件安全性是一个涉及面广、难 度很大的课题。软件测试炸为软件质量保证中的关键技术，正受到人们越来越多 的关注。 软件测试是伴随着软件的产生而产生的。早期的软件开发过程中，测试的含 义比较狭窄，将测试等同于“调试”，目的是纠正软件中已经知道的故障，常常 由开发人员自己完成这部分的工作。对测试的投入极少，测试介入也晚，常常是 等到形成代码，产品己经基本完成时才进行测试。 直到1 9 5 7 年，软件测试才开始与调试区别开来，作为一种发现软件缺陷的 活动。但由于一直存在着“只有产品开始工作了，才能对其进行测试”的思想， 测试仍然是后于开发的活动。潜意识里，我们的目的就是使自己确信产品能够工 作。2 0 世纪7 0 年代，尽管对“软件工程”的真正含义还缺乏共识，但这一词条 已经频繁出现。1 9 7 2 年，在美国北卡罗来纳大学举行了首届软件测试正式会议。 1 9 7 9 年，g l e n _ f o r dm y e r s 的软件测试艺术( t h ea r to f s o f t w a r et e s t i n g ) 中 做出了当时最好的软件测试定义：“测试是为发现错误而执行的一个程序或者系 统的过程。”i t j 直到2 0 世纪8 0 年代，美国等发达国家的软件业进入以过程为中心的工业化 时代，软件的全面质量管理才开始被人们理解和重视。软件测试定义发生了改变， 测试不单纯是一个发现错误的过程。而且包含软件质量评价的内容。软件开发人 员和测试人员开始坐在一起探讨软件工程和测试问题。制定了各类标准，包括 i e e e ( i n s t i t u t eo f e l e e t r i c a la n de l e c t r o n i ce n g i n e e r s ) 标准、美国a n s i ( a m e r i c a n n a t i o n a ls t a n d a r di n s t i t u t e ) 标准以及1 5 0 ( i n t e r n a t i o n a ls t a n d a r do r g a n i z a t i o n ) 国 际标准。1 9 8 3 年，b i l lh e t z e l 在软件测试完全指南( c o m p l e t eg u i d eo f s o f t w a r e t e s t i n g ) 一书中指出：“测试是以评价一个程序或者系统属性为目标的任何一种 活动。测试是对软件质量的度量。”m y e r s 和h e t z e l 的定义至今仍被引用口j 。 到了2 0 0 2 年，瞄c kd c r a i g 和s t e f a np j a s k i e l 在系统的软件测试 ( s y s t e m a t i cs o f t w a r e t e s t i n g ) 中对软件测试做了进一步定义：“测试是为了度量 和提高被测软件的质量，对测试件进行工程设计、实施和维护的整个生命周期过 程。”这些经典论著对软件测试研究的理论化和体系化产生了巨大的影响【i “。 近2 0 年来，随着计算机和软件技术的飞速发展，软件测试技术研究也取得 了很大的突破。测试专家总结了很好的测试模型，比如著名的v 模型、w 模型 等，在测试过程改进方面提出了t m m ( t e s t i n gm a t u r i t ym o d e l ) 的概念，在单元 测试、系统测试、负载压力测试以及测试管理等方面涌现了大量优秀的软件测试 工具。 1 2 我国软件测试现状 我国在软件测试方面起步较晚，并且由于测试技术和工具的缺乏，主要在项 目组内部进行传统手工测试，效率低、效果差、测试人员感到测试工作繁杂枯 燥近几年虽然逐步引起重视，但如何进行有效的软件测试，是项目管理层 和软件测试人员急需了解的内容。 1 2 1 传统手工测试方法 早期的软件开发中，通常的测试方法就是运行被测程序，通过手工操作指定 输入然后来观察输出。现在还有很多软件的测试继续着这种方式，它有一个关键 的优点：非常容易学习和理解。只要拥有键盘和鼠标，并且会操作图形界面，就 可以测试任何桌面应用：如果装载了w e b 浏览器，还可以测试w e b 应用。 这种方式的测试过程其实与最终用户操作系统的过程完全相同，几乎不需要什么 技巧，所有的开发人员甚至普通用户都能做到，并且也能够发现程序的很多问题， 但这并不是真正的优点，因为其它的测试方法也能做到。而手工测试的缺点就实 在太多了： 1 手工测试需要反复迸行 每一次修改程序，不管是增加新特征，改变己有行为，还是修改b u g ，测试 入员都必须重新测试被影响的部分，才能保证本次增删改的代码不会造成破坏。 2 手工测试可能带来错误 人类不适合作重复性的工作，尤其当这项工作本身就相当繁复的话。人们经 常忽略细节，这会导致代码被破坏。更可能造成的问题是：修改一个地方，可能 会影响到另一些地方代码的行为，尽管它们之间的关系并不是很明显。因此，即 使测试人员作了非常认真负责的测试，那也只限于他认为修改可能影响到的部 分，但还是有可能会在其它地方漏掉些b u g 或被破坏的功能，不是因为测试 得不够仔细，而是因为软件开发是一项综合性的工作，软件的各个部分都密切相 关，在现今的软件项目中，任何人都不可能详细了解某段代码所有的依赖与被依 赖关系。 3 手工测试无法对不可视组件进行单独测试 软件是复杂的，为了定位和解决错误的或被破坏的代码，大量形态各异的b u g 需要通过“抽丝剥茧”式的测试去定位分析每一个组件的行为。对于服务器端软 件尤为如此。服务器端程序中，几乎所有的重要代码都在逻辑层，如基于w e b 的程序。通过表示层测试只能间接地测试业务逻辑，可能忽略某些细节。你当然 希望逻辑层和表示层都能很好地工作，而逻辑层正常工作是整个应用能正常运行 的基础。 4 无法验证测试的结果 项目组的其他人员( 例如项目经理、开发人员或者甚至是最终用户) 只能接 受测试人员的承诺：测试完成，各方面都满足需求。除t n 试人员的书面或口头 声明保证己经作过测试，程序满足所有可视的检查外，其他人没办法进行验证， 除非这些人自己再辛苦地重复一遍测试，但这个工作可能并不适合所有人，因为 不是所有人都熟悉程序的边界条件和逻辑 h 1 。 1 2 2 面临的挑战 近几年随着我国信息产业的飞速壮大，软件产品的规模及其开发过程都有了 很大的发展。然而相比之下我们的软件测试技术却没有得到相应提高，上述缺点 自然更加突显出来，面临很大的挑战。 1 复杂软件系统测试中手工方法面临的挑战 现代大规模软件系统开发中，多层次分布式结构因其可伸缩性好、可管理性 强、安全性高、软件重用性好以及节省开发时间等诸多优点而得到广泛应用。各 层次部件，如操作系统、虚拟机、数据库、应用服务器、不同的硬件平台等等， 还包括它们之间的交互接口，都需要进行严密的测试，使测试复杂性大大增加。 一些系统级的软件产品，如数据库、w e b 服务器等等，其系统端和客户端都 需要支持跨软硬件平台工作。不同软硬件平台的组合和针对每个组合的强调性测 试都不可避免地使测试的工作量变得非常惊人。 在系统的性能测试过程中，为了取得完整的性能数据，测试要求在不同的参 数配置下反复运行、分析和调试：在同一组参数配置下，往往还要重复运行多次 以收集到更可靠的数据；同时，为了模拟系统真实的工作情形或者取得系统的极 限状态，必须进行强压力测试，即大批量，长时间地向系统麓加负荷。对应用程 序进行压力测试最简单的方法是手工改变输入( 客户机数量、需求大小、请求的 频率、请求的混合程度，等等) 并描绘性能的变化。对于一些应用程序，测试所 要做的就是这些，但是如果有许多输入，或者需要大幅度改变输入，那么就可能 需要借助工具。另外，在手工测试中，如果想在进行了一些改变后重新验证应用 程序，可能很难精确地重复前一组测试：如果是让多个用户同时进行测试，想要 一致性地同步所有人的手工运行几乎是不可能的；由于测试人员和测试机器等资 源都是有限的，要任意扩大测试压力也是非常困难的【9 l 。 2 短测试周期中手工方法面临的挑战 当前软件开发过程中，迭代式的开发过程己经显示出了与瀑布式开发相比 巨大的好处，芳己逐渐取代传统的瀑布式开发成为目前最流行的软件开发过程。 迭代开发中强调在较短的时间间隔中产生多个可执行、可测试的软件版本，这就 意味着i 受0 试人员也必须对每个迭代产生的软件系统进行测试。测试工作的周期被 缩短了，测试的频率被增加了。在这种情况下，传统的手工测试己经严重地满足 不了软件开发的需求。 当第一个可测试的版本产生后，测试人员开始对这个版本的系统进行测试， 很快第二个版本在第一个版本的基础上产生了，测试人员需要在第二次测试时重 复上次的测试工作，还要对新增加的功能进行测试，每经过一个迭代，测试的工 作量都会逐步累加。随着软件开发过程的进展，测试工作变得越来越繁重，如果 使用手工测试的方法，将很难保证测试工作的进度和质量。 同时，目前的g u i 等开发技术已经非常先进了，它提供给开发人员快捷开 发的能力。这就意味着开发人员能够非常快速地改变程序，并将新的版本交给测 试人员进行测试。实际上，很多公司每天都会有多个软件版本产生。如果还是使 用传统的手工测试方法，根本不可能符合软件快速开发的要求。 1 2 3 软件测试方法的改进 软件产品的发展趋势是规模越来越大，功能越来越多，结构越来越复杂 那么作为保证软件质量关键的软件测试必然需要更多的关注与投入。然而对于以 追求经济利益为基本目标的企业来说，仅靠增加人力物力投入来保证其产品测试 效果是不现实的，也是不科学的。最实际和最科学的解决方案就是对现有的软件 测试方法进行改进，利用最少的资源创造最佳的测试效果。那么接下来的问题就 是：如何对传统软件测试方法进行改进呢? 要改进传统软件测试方法，关键是要找到合适的工具来替代完成原本需要测 试人员手工完成的测试活动。 众所周知，计算机能够自动高速而又精确地处理各类信息和数据，且永远不 会感到厌烦和疲倦。随着计算机软硬件性能不断提高，价格不断下降，目前，越 来越多行业的人们把工作交给计算机完成，实现生产过程的自动化、流水化。其 4 优点无庸置疑：节省人员、成本，提高生产效率，提高准确性、标准性作为 掌握着最前沿信息技术的软件企业，如果仍然延用传统的手工测试方式，终日被 大量重复而繁杂的测试工作所烦累，却还是无法保证其产品质量，无疑是一件十 分滑稽的事情。因此，实现测试的自动化也是改进软件测试方法的最佳方案，并 且成为整个软件测试行业的发展趋势。 软件是让计算机帮助人们完成特定任务的工具，那么要让计算机帮助我们实 现自动测试任务，创造和应用良好的自动测试软件( 即自动测试工具) 势在必行。 采用自动测试工具，测试人员只要根据测试需求设计测试过程中所需的行为，自 动测试工具将自动执行这些行为，这个过程可以保存、反复、或进行简单修改后 将其用于今后其它相同功能的测试中，因而不必手工地重复己经测试过的功能部 分。 2 1 背景 第二章面向对象的软件测试 面向对象程序的结构不再是传统的功能模块结构，作为一个整体，原有集成 测试所要求的逐步将开发的模块搭建在一起进行测试的方法已成为不可能。而 且，面向对象软件抛弃了传统的开发模式，对每个开发阶段都有不同以往的要求 和结果，已经不可能用功能细化的观点来检测面向对象分析和设计的结果。因此， 传统的测试模型对面向对象软件已经不再适用，面向对象的软件需要通过面向对 象的软件测试来确保其正确性。 2 2 面向对象软件测试与传统软件测试技术的区别 就测试而言，面向对象软件开发中测试的目的与以往传统的测试目标是完全 相同的，都是为了确保软件能够正确地执行预定的功能。测试过程都包括了测试 计划、测试用例的设计、测试运行，测试结果分析。 传统的单元测试的对象是软件设计的最小单位一模块。单元测试的依据是详 细设计描述，单元测试应对模块内所有重要的控制路径设计测试用例，以便发现 模块内部的错误。单元测试多采用白盒测试技术，系统内多个模块可以并行地进 行测试。当考虑面向对象软件时，单元的概念发生了变化。封装驱动了类和对象， 这意味着每个类和类的实例( 对象) 包装了属性( 数据) 和操纵这些数据的操作，而 不是个体的模块。最小的可测试单位是封装的类或对象，类包含一组不同的操作， 并且某特殊操作可能作为一组不同类的一部分存在。因此，单元测试的意义发生 了较大变化。我们不再孤立地测试单个操作，而是将操作作为类的一部分。 传统的集成测试，有两种方式通过集成完成的功能模块进行测试。一是自项 向下集成，自顶向下集成是构造程序结构的一种增量式方式，它从主控模块开始， 按照软件的控制层次结构，以深度优先或广度优先的策略，逐步把各个模块集成 在一起。二是自底向上集成，自底向上测试是从“原子”模块( 即软件结构最低 层的模块) 开始组装测试。因为面向对象软件没有层次的控制结构，传统的自项 向下和自底向上集成策略就没有意义，此外，一次集成一个操作到类中( 传统的 增量集成方法) 经常是不可能的，这是由于“构成类的成分的直接和间接的交互”。 对o o 软件的集成测试一般有两种不同策略，第一种称为基于线程的测试，集成 6 对回应系统的一个输入或事件所需的一组类，每个线程被集成并分别测试，应用 回归测试以保证没有产生副作用；第二种称为基于使用的测试，通过测试那些几 乎不使用服务器类的类( 称为独立类) 而开始构造系统，在独立类测试完成后， 下一层的使用独立类的类，称为依赖类。被测试。这个依赖类层次的测试序列一 直持续到构造完整个系统。 传统的测试计算机软件的策略是从“小型测试”开始，逐步走向“大型测试”。 即从单元测试开始，然后逐步进入集成测试，最后是有效性和系统测试。而面向 对象程序的结构不再是传统的功能模块结构，作为一个整体，原有集成测试所要 求的逐步将开发的模块搭建在一起进行测试的方法己成为不可能。而且，面向对 象软件抛弃了传统的开发模式，对每个开发阶段都有不同以往的要求和结果，己 经不可能用功能细化的观点来检测面向对象分析和设计的结果。因此，传统的测 试模型对面向对象软件已经不再适用。 2 3 面向对象测试模型 面向对象的开发模型突破了传统的瀑布模型，将开发分为面向对象分析 ( o o a ) ，面向对象设计( o o d ) ，和面向对象编程( o o p ) 三个阶段【6 】。针对 这种开发模型，结合传统的测试步骤的划分，把面向对象的软件测试分为：面向 对象分析的测试，面向对象设计的测试，面向对象编程的测试，面向对象单元测 试，面向对象集成测试，面向对象系统测试六个环节是比较合理的。 0 0s y s t e mt e s t 0 0i n t e g r a t et e s t 0 0 u n i t t e s t 0 0 1 1 0 0 d0 0 p t e s t r e = t t e s t 0 0 ad o o p 图2 1 面向对象测试模型 l 、面向对象分析的测试 面向对象分析( o o a ) 强调“把e - r 图和语义网络模型，即信息造型中的概 念，与面向对象程序设计语言中的重要概念结合在一起而形成的分析方法”。 o o a 直接映射问题空间，将问题空间中的实例抽象为对象，用对象的结构反映 7 问题空间的复杂实例和复杂关系，用属性和操作表示实例的特性和行为。对一个 系统而言，行为是相对稳定的，结构是相对不稳定的，这更充分反映了现实的特 性。 2 、面向对象设计的测试 面向对象设计( o o d ) 采用“造型的观点”，以o o a 为基础归纳出类，并建 立类结构或进一步构造成类库，实现分析结果对问题空间的抽象。由此可见， o o d 不是在o o a 上的另一思维方式的大动干戈，而是o o a 的进一步细化和更 高层的抽象。o o d 确定类和类结构不仅是满足当前需求分析的要求，更重要的 是通过重新组合或加以适当的补充，能方便实现功能的重用和扩增，以不断适应 用户的要求。 3 、面向对象编程的测试 典型的面向对象程序具有继承、封装和多态的新特性，这使得传统的测试策 略必须有所改变。封装是对数据的隐藏，外界只能通过被提供的操作来访问或修 改数据，这样降低了数据被任意修改和读写的可能性，降低了传统程序中对数据 非法操作的测试。继承是面向对象程序的重要特点，继承使得代码的重用率提高， 同时也使错误传播的概率提高。多态使得面向对象程序对外呈现出强大的处理能 力，但同时却使得程序内“同一”函数的行为复杂化，测试时不得不考虑不同类 型具体执行的代码和产生的行为。 4 、面向对象的单元测试 传统的单元测试的对象是软件设计的最小单位模块。单元测试的依据是 详细设描述，单元测试应对模块内所有重要的控制路径设计测试用例，以便发现 模块内部的错误。单元测试多采用白盒测试技术，系统内多个模块可以并行地进 行测试。 当考虑面向对象软件时，单元的概念发生了变化。封装驱动了类和对象的定 义，这意味着每个类和类的实例( 对象) 包装了属性( 数据) 和操纵这些数据的操作。 而不是个体的模块。最小的可测试单位是封装的类或对象，类包含一组不同的操 作，并且某特殊操作可能作为一组不同类的一部分存在，因此，单元测试的意义 发生了较大变化。我们不再孤立地测试单个操作，而是将操作作为类的一部分。 5 、面向对象的集成测试 面向对象软件没有层次的控制结构，传统的自顶向下和自底向上集成策略就 没有意义，此外，一次集成一个操作到类中( 传统的增量集成方法) 经常是不可 能的，这是由于“构成类的成分的直接和问接的交互”。对o o 软件的集成测试 有两种不同策略，第一种称为基于线程的测试，集成对回应系统的一个输入或事 件所需的一组类，每个线程被集成并分别测试，应用回归测试以保证没有产生副 作用。第二种称为基于使用的测试，通过测试那些几乎不使用服务器类的类( 称 为独立类) 而开始构造系统，在独立类测试完成后，下一层的使用独立类的类， 称为依赖类。这个依赖类层次的测试序列一直持续到构造完整个系统。 6 、面向对象的系统测试 通过单元测试和集成测试，仅能保证软件开发的功能得以实现。但不能确认 在实际运行时，它是否满足用户的需要。为此，对完成开发的软件必须经过规范 的系统测试。系统测试应该尽量搭建与用户实际使用环境相同的测试平台，应该 保证被测系统的完整性，对临时没有的系统设备部件，也应有相应的模拟手段。 系统测试时，应该参考o o a 分析的结果，对应描述的对象、属性和各种服务， 检测软件是否能够完全“再现”问题空间。系统测试不仅是检测软件的整体行为表 现，从另一个侧面看，也是对软件开发设计的再确认。 面向对象测试的整体目标以最小的工作量发现最多的错误和传统 软件测试的目标是一致的，但是o o 测试的策略和战术有很大不同。测试的视角 扩大到包括复审分析和设计模型，此外，测试的焦点从过程构件( 模块) 移向了 类。 7 、面向对象的覆盖率 由于传统的结构化度量都没有考虑面向对象的一些特性，如多态、继承和封 装等。传统的结构化覆盖必须被加强，以满足面向对象的特性，上下文覆盖就是 一种针对面向对象特性雨增强的覆盖。 上下文覆盖可以应用到面向对象领域处理诸如多态、继承和封装的特性，同 时该方法也可以被扩展用于多线程应用。通过使用这些面向对象的上下文覆盖， 结合传统的结构化覆盖的方法就可以保证代码的结构被完整地执行，同时提高我 们对被测软件质量的信心。 有3 个面向对象上下文覆盖的定义，分别是： ( i ) 继承上下文覆盖( i n h e r i t a n c ec o n t e x tc o v e r a g e ) ，该覆盖率用于度量在系统 中多态调用被测试的程度。 ( 2 ) 基于状态的上下文覆盖( s t a t e b a s e dc o n t e x tc o v e r a g e ) ，该覆盖率用于改 进对带有状态依赖行为的类的测试。 ( 3 ) 已定义用户上下文覆盖( u s e r - d e f i n e dc o n t e x tc o v e r a g e ) ，该度量允许上下 文覆盖的方法被应用到传统结构化覆盖率无法使用的地方，如多线程应用。 2 4 类的功能性测试和结构性测试 对面向对象软件的类测试相当于传统软件的单元测试。传统软件的单元测试 往往关注模块的算法细节和模块接口问流动的数据，而面向对象软件的类测试是 由封装在类中的操作和类的状态行为所驱动。由于属性和操作的被封装，对类之 9 外操作的测试通常是无用的。封装是对对象的状态快照难于获得，继承也给测试 带来了难度，即使类是彻底复用的，对每个新的使用语境也需要重新测试。多重 继承则更增加了需要测试的语境的数量，使测试进一步复杂化。如果从超类导出 的测试用例被用于相同的问题域，有可能对超类导出的测试用例集可以用于子类 的测试，然而，如果子类被用于完全不同的语境则超类的测试用例将没有多大 的用途，必须设计新的测试用例集。 在类的生命周期中，类测试只是一个初始的测试阶段。类作为独立的成分可 以多次在不同的应用系统中重复使用，这些成分的用户可要求每个类是可靠的， 并无须了解其实现细节。这样的类要尽可能多地进行测试，因为关心的是类单元 本身，如类库中的l i s t 、s t a c k 等基本类。 类的测试用例可以先根据其中的方法设计，然后扩展到方法之间的调用关 系。若类中的方法都已定义了前置后置条件，则可以此作为开发对各方法进行 测试所用的测试用例的参考。一般情况下，根据方法的前雹、后置条件以及关于 类的约束条件，利用传统的测试方法，也能设计出较完善的测试用例。类测试一 般也采用传统的两种测试方式：功能性测试和结构性测试，即黑盒测试和白盒测 试。功能性测试以类的规格说明为基础，它主要检查类是否符合其规格说明的要 求。例如，对于s t a c k 类，即检查它的操作是否满足l i f o 规则；结构性测试则 从程序出发，需要考虑其中的代码是否正确，同样是s t a c k 类，就要检查其中代 码是否动作正确，并且至少执行一次。 l 功能性测试 功能性测试包括两个层次：类的规格说明和方法的规格说明。 ( 1 ) 类的规格说明 类的规格说明是各方法规格说明的组合及对类所表示概念的广义描述。例 如，在s t a c k 类的规格说明中包括了方法p u s h 和p o p 的规格说明，但p u s h 和p o p 都没有说明这两个操作在一个类中同时工作的情况，即p u s h 的规格说明只要求 把其参数值加到栈顶上，但对删除不加任何说明，而p o p 也同样不对被删除项的 加入作任何描述。仅在类这一层的规格描述中才表达l i f o 的要求限制。对于数 据类型的形式化描述也可用来对类进行定义，但类比类型的含义更广泛，具有更 确切的语义，尤其是类之间的继承关系也被表示出来了。 一个c + + 类的规格说明具有多层性，但对它的用户来说，它只包括了在类定 义公共区中方法的说明，子类所能见到的父类是其p u b l i c 和p r o t e c t e d 区域中的 内容，一个类中所定义的方法可以分为三个存取层次：p u b l i c 、p r o t e c t e d 和p r i v a t e 。 这些方法可各自分开独立考虑，一个类是所有这些的综合。 ( 2 ) 方法的规格说明 每个独立的方法的规格说明可以通过其前置后置条件描述。根据前置条件选 i o 择相应的测试用例，就可以检查其产生的输出是否满足后置条件而完成对独立方 法的测试，对独立方法的测试与对独立过程的测试方法类似。 2 结构性测试 结构性测试对类中的方法进行测试，它把类作为一个单元来进行测试，测试 分为两个层次： 第一层，考虑类中各独立方法的代码： 第二层，考虑方法之间的相互作用。 每个方法的测试要求能针对其所有的输入情况，但这样还不够，只有对这些 方法之间的界面也做同样测试，才能认为测试是完整的。对于一个类的测试要保 证类在其状态的代表集上能够正确工作，构造函数的参数选择以及消息序列的选 择都要满足这一准则【8 】。因此，在这两个不同的测试层次上应该分别做到： ( 1 ) 方法的单独测试 结构性测试的第一层是考虑各独立的方法，这可以与过程的测试采用同样的 方法，两者之间最大的差别在于方法改变了它所在实例的状态，这就要取得隐藏 的状态信息来估算测试的结果，传给其他对象的消息被忽略，而以桩代替，并根 据所传的消息返回相应的值，测试数据要求能完全覆盖类中代码，可以用传统的 测试技术来获取。 ( 2 ) 方法的综合测试 第二层要考虑一个方法调用本对象类中的其他方法和从一个类向其他类发 送信息的情况。单独测试一个方法时，只考虑其本身执行的情况。而没有考虑动 作的顺序问题，测试用例中加入了激发这些调用的信息，以检查它们是否正确运 行了。对于同一类中方法之间的调用，一般只需要极少甚至不用附加数据，因为 方法都是对类进行存取，因此这一类测试的准则是要求遍历类的所有主要状态。 2 5 状态转移图的面向对象软件测试 2 5 1 状态转移图 状态转移图是通过对类对象的生存周期建立模型来描述对象随时间的动态 行为。每一个对象都被看作是通过对事件进行探测并做出回应来与外界其他部分 通信的独立的实体。事件表示对象可以探测到的事物的一种运动变化如接受 到从一个对象到另一个对象的调用或信号、某些值的改变或一个时间段的终结。 任何影响对象的事物都可以是事件，真实世界所发生的事物的模型通过从外部世 界到系统信号来建立的。 状态是给定的对象的一组属性值，这组属性值对所发生的事件具有相同性质 的反映。换言之，处于相同状态的对象对同一事件具有同样方式的反映，所以当 给定状态下的多个对象接受到相同事件时会执行相同的动作，然而处于不同状态 下的对象会通过不同的动作对同一事件做出不同的反映。 1 、事件 事件是发生在时间和空间上的一点的值得注意的事情。它在时间上的一点发 生，没有持续时间。如果某一事情的发生造成了影响，那么在状态转移图模型中 它是一个事件 t 8 j 。当我们使用事件这个词时，通常是指一个事件的描述符号， 即对所有具有相同形式的独立发生事件的描述。事件可以分成明确或隐含的几 种：信号事件、调用事件，变动事件、时间事件。信号事件是接受一个对象间外 在的、命令的、异步的通信；调用事件是接受等待应答的对象的明确形式的同步 请求；变动事件是对布尔表达式值的修改；时间事件是绝对时间的到达或一个相 对时间段的终结。 2 、状态 状态描述了一个类对象生命周期中的一个时间段。它可以用三种附加方式说 明：在某些方面性质相似的一组对象值；一个对象等待一些事件发生时的一段时 间；对象持续活动时的一段时间。在状态图中，一组状态有转移相连接。虽然转 移连接着两个状态，但转移只有转移出发的状态处理。当对象处于某种状态时， 它对触发状态转移的触发器事件很敏感。 3 、转移 从状态出发的转移定义了处于此状态的对象对外界发生的事件所做出的反 映。通常，定义一个转移要有引起转移的触发器事件、监护( g u a r d ) 事件、转移 的动作和转移的目标状态。表2 1 列出了几种转移和由转移所引起的隐含动作。 表2 1 状态转移 转移的种类 描述 入口动作进入某一状态时执行的动作 出口动作离开某一状态时执行的动作 外部转移引起状态改变的转移或自身转移，同时执行一个具体的动作，包 括引起入口动作和出口动作被执行的转移 内部转移引起一个动作的执行但不改变状态或不引起入口动作或出口动作 的执行 2 5 2 状态国的测试 面向对象的分析方法通常采用状态转移图建立对象的动态行为模型。状态转 移图用于刻画对象响应各种事件时状态发生转移的情况，图中结点表示对象的某 个可能状态，结点之间的有向边通常用“事件动作”标出。如图中的示例，表 示当对象处于状态a 时，若接收到事件e 则执行相应的操作a ，且转移到状态b 。 因此，对象的状态随各种外来事件发生怎样的变化行为，是考察对象行为的一个 重要方面。 a 丝b 基于状态的测试是通过检查对象的状态在执行某个方法后是否会转移到其 余状态的一种测试技术。使用该技术能够检验类中的方法是否能正确地交互，即 类中的方法是否能通过对象的状态正确地通信。因为对象的状态是通过对象的数 据成员的值反映出来，所以检查对象的状态实际上就是跟踪监视对象数据成员的 值的变化。如果某个方法执行后对象的状态未能按预期的方式改变，则说明该方 法含有错误。 状态转移图中的结点代表对象的逻辑状态，雨非所有可能的实际状态。理论 上讲，对象的状态空间是对象所有数据成员定义域的笛卡尔乘积。当对象含有多 个数据成员时，要把对象的所有可能状态进行测试是不现实的，这就需要对对象 的状态空间进行简化，同时又不失去对数据成员取值的“覆盖面”。简化对象状 态空问的基本思想类似于黑盒测试中常用的等分区间的方法。依据软件设计规范 或分析程序源代码，可以从对象数据成员的取值域中找到一些特殊值和一般性的 区间。特殊值是设计规范里说明有特殊意义，在程序源代码里逻辑上需特殊处理 的取值。位于一般性区间中的值不需要区别各个值的差别，在逻辑上以同样方式 处理。例如下面的类的定义： e l a s sa c c o u n t c h a r n a m e ； i n ta c c n u m ； h a tb a l a n c e ； ； 依据常识可知，特殊值情况：n a m e = n u l l ，a c c n u m = 0 ，b a l a n c e = 0 ：一般区 间内：n a m e ! = n u l l ，a c c n u m 0 ，b a l a n c e 0 。 进行基于状态的测试时，首先要对被测试的类进行扩充定义，即增加一些用 于设置和检查对象状态的方法。通常是对每一个数据成员设置一个改变其取值的 方法。另项重要工作是编写作为主控的测试驱动程序，如果被测试的对象在执 行某个方法时还要调用其它对象的方法，则需编写桩程序代替其他对象的方法。 测试过程为：首先生成对象，接着向对象发送消息把对象状态设置到测试实例指 定的状态，再发送消息调用对象的方法，最后检查对象的状态是否按预期的方式 发生变化。 下面给出基于状态测试的主要步骤： ( 1 ) 依据设计文档，或者通过分析对象数据成员的取值情况空间，得到被测试 类的状态转移图； ( 2 ) 给被测试的类加入用于设置和检查对象状态的新方法，导出对象的逻辑状 态； ( 3 ) 对于状态转移图中的每个状态，确定该状态是哪些方法的合法起始状态， 即在该状态时，对象允许执行哪些操作： ( 4 ) 在每个状态，从类中方法的调用关系图最下层开始，逐一测试类中的方法： 测试每个方法时，根据对象当前状态确定出对方法的执行路径有特殊影响的参数 值，将各种可能组合作为参数进行测试。 第三章类簇级测试方法 本章以顺序图为基础结合状态图生成类簇级测试用例，一方面由于u m l 顺 序图是一种广泛的并且是易于理解的类图，而且它也被许多c a s e 工具如 r a t i o n a lr o s e 等支持，因此用u m l 顺序图作为测试基础是一种很好的选择；另 一方面则是由于这些依赖于顺序图的测试方法具有相对较低的复杂性，而且顺序 图给人非常直观的视觉，便于分析和理解。另外，r u p 被描述为用例驱动的， 在需求分析阶段，它使用用例获得系统的关键信息，而在分析和设计阶段，用一 个或多个交互图来描述( 例如顺序图和状态图) 用例实例化的关键部分，这些图 被用来分析哪个对象来实现这个用例的功能，以及对象问是如何进行交互的。i l 2 】 所以分析、设计阶段的顺序图和状态图保持了需求规约里的信息，也是最终代码 实现的依据，是编写类簇级测试用例的重要依据。 3 1 研究假定和要做的工作 为了能从顺序图和状态图中共同生成类簇级测试用例，本文有如下假定： ( 1 ) 假定顺序图描述的与用例图描述的规约是一致的 ( 2 ) 假定顺序图描述的交互信息和类的状态转换图是系统设计和分析阶段的 信息 ( 3 ) 假定状态图描述的类即是顺序图中交互的类的一部分 主要做的工作有： ( 1 ) 定义状态图中发生转化的语法描述 ( 2 ) 从顺序图中识别出参加交互的类，从而确定其状态图，然后将状态图转化 为直观的状态表 ( 3 ) 将类的状态图合并生成组合状态图，然后对组合状态图进行优化，得到极 小状态图。 ( 4 ) 根据优化后的极小状态图设计测试用例生成算法，生成类簇测试用例。 下面给出类簇测试用例生成的流程图： 3 2 问题的提出 图3 1 测试用例生成流程 基于面向对象软件的测试数据自动生成方法的研究己经取得了很大成果，而 基于交互图( 包括顺序图和协作图) 和状态图的测试数据生成一直是其中研究的 热点，并且取得了很大的成果。文献【2 9 】提出了一种将u m l 时序图合成有限状态 机，然后基于该有限状态机，使用数据流分析和控制流分析两种方法生成用于测 试所描述的行为的集成测试用例。该