面向对象的软件测试毕业论文.docx
《面向对象的软件测试毕业论文.docx》由会员分享，可在线阅读，更多相关《面向对象的软件测试毕业论文.docx（16页珍藏版）》请在冰点文库上搜索。
面向对象的软件测试毕业论文
面向对象的软件测试
【文章摘要】
面向对象的软件测试摘要:
如今，面向对象开发技术正大力地的推动着软件产业的快速发展。
在保证软件产品质量的手段中，最有效、最重要的技术要数软件测试技术。
然而，传统的测试技术和方法，对面向对象技术开发的的软件多少显得有些力不从心。
鉴于此，提出了面向对象的测试技术！
在此，本文通过翻阅大量的文献，总结出着实有效的面向对象的软件测试技术。
首先，阐明面向对象软件测试的基本概念；然后，分别讨论分析和设计……
【文章正文】
面向对象的软件测试
摘要:
如今，面向对象开发技术正大力地的推动着软件产业的快速发展。
在保证软件产品质量的手段中，最有效、最重要的技术要数软件测试技术。
然而，传统的测试技术和方法，对面向对象技术开发的的软件多少显得有些力不从心。
鉴于此，提出了面向对象的测试技术！
在此，本文通过翻阅大量的文献，总结出着实有效的面向对象的软件测试技术。
首先，阐明面向对象软件测试的基本概念；然后，分别讨论分析和设计模型测试技术、类测试技术、对象交互测试技术、类层次结构测试技术、面向对象系统测试技术；最后，对面向对象软件测试的实施进行小结。
关键词：
面向对象；软件测试；类测试；对象交互；测试用例
Object-OrientedSoftwareTest
Abstract：
Now,Object-Orienteddevelopmenttechniqueisstronglypushingthefastdevelopmentofthesoftwareindustry．Inthemeansoftheassurancesoftwareproductquality,mostvalid，themostimportanttechniquewantsthefewsoftwaretesttechnique．However,thetraditionaltesttechniqueandmethod,theoppositedevelopstowardtheobjecttechniqueofsoftwarehowmuchseemtobesometolacktheabilitytodo．Owingtothis,putforwardtotheObject-Orientedtesttechnology!
Here,thistextpassestobrowseagreatdealofculturalheritage,tallyinguptoreallyeffectivelyObject-Orientedsoftwaretesttechnique。
First,clarifythebasicconceptofObject-Orientedsoftwaretest；then,discussrespectivelytheClasstesttechnique；atesttechnique，objecthandsovertowitheachothertestthetechnique，alayerstructuretesttechnique,thedistributetypeobjecttesttechniqueandfacetotheobjectsystemtesttechnique;finally，theimplementthatteststowardtheobjectsoftwareinfrontcarriesonthesub-footing.
Key Words：
Object-Oriented；Softwaretest；Classtest；Objectinteract；Testcase
目 录
引 言...1
1.面向对象的软件测试的基本概念...2
2.分析和设计模型测试技术...3
2.1.分析和设计模型测试的内容...3
2.2.分析和设计模型测试的方法...3
3.类测试技术...4
3.1.类测试的内容...5
3.2.类测试的时间...5
3.3.类测试的测试人员...5
3.4.类测试的方法...6
3.5.测试程度...6
3.6.构建类测试用例...6
4.类层次结构测试技术...9
4.1.分层、增量测试...10
4.2抽象类测试...11
5．对象交互测试技术...12
5.1．汇集类测试...12
5.2．协作类的测试...13
6．面向对象系统测试技术...13
总 结...15
参考文献...16
致 谢...17
引 言
软件测试的发展历程软件测试是伴随着计算机软件的产生而产生的。
在早期软件开发的过程中，软件就是由程序员写的简单计算机程序代码。
因而，软件测试的含义比较狭窄----测试等同于“调试”。
软件测试的目的就是为寻找和纠正软件中的故障，这部分的工作常常由开发人员自己完成。
直到上世纪80年代早期，“质量”的号角才开始吹响。
软件测试定义发生了改变，测试不单纯是一个发现错误的过程，而且包含软件质量评价的内容。
软件开发人员和测试人员开始坐在一起探讨软件工程和测试问题。
制定了各类标准，包括IEEE（InstituteofElectricalandElectronicEngineers）标准、美国ANSI（AmericannationalStandardInstitute）标准以及ISO（InternationalStandardOrganization）国际标准。
1983年，BillWetzel在《软件测试完全指南》（CompleteGuideofSoftwareTesting）一书中指出：
“测试是以评价一个程序或者系统属性为目标的任何一种活动。
测试是对软件质量的度。
”Myers和Wetzel的定义至今仍被引用。
到了2002年，Rick和Stefan在《系统的软件测试》（SystematicSoftwareTesting）中对软件测试做了进一步定义：
“测试是为了度量和提高被测软件的质量，对测试件进行工程设计、实施和维护的整个生命周期过程。
”这些经典论著对软件测试研究的理论化和体系化产生了巨大的影响。
近20年来，随着计算机和软件技术的飞速发展，软件测试技术研究也取得了很大的突破。
测试专家总结了很好的测试模型，比如著名的V模型、W模型等，在测试过程改进方面提出了TMM（TestingMaturityModel）的概念，在单元测试、自动化测试、负载压力测试以及测试管理等方面涌现了大量优秀的软件测试工具。
虽然软件测试技术的发展很快，但是其发展速度仍落后于软件开发技术的发展速度，使得软件测试在今天面临着很大的挑战。
软件规模越来越大，功能越来越复杂，如何进行充分而有效的测试成为难题。
尤其是面向对象的开发技术越来越普及，但是面向对象的测试技术却刚刚起步。
面向对象软件开发过程及其特点 面向对象的开发方法（简称OO）的基本思想认为，客观世界是由各种各样的对象组成的，每种对象都有各自的内部状态和运动规律，不同的对象之间的相互作用和联系就构成了各种不同的系统。
故面向对象软件开发的工作过程为：
1. 调查、分析系统需求，建立一个全面、合理、统一的模型。
2. 在繁杂的问题域中抽象地识别出对象以及其行为、结构、属性、方法
3. 对象设计——即对分析的结果作进一步地抽象、归类、整理，并最终以范式的形式将它们确定下来。
4. 程序实现——即用面向对象的程序设计语言将上一步整理的范式直接映射（直接用程序语言来取代）为应用程序软件。
面向对象开发的特点是遵循一下三项原则：
1. 抽象原则（abstraction）——指为了某一分析目的而集中精力研究对象的某一性质，它可以忽略其它与此目的无关的部分
2. 封装原则（encapsulation）即信息隐藏——指在确定系统的某一部分内容时，应考虑到其它部分的信息及联系都在这一部分的内部进行,外部各部分之间的信息联系应尽可能的少。
3. 继承原则（inheritance）——指能直接获得已有的性质和特征而不必重复定义它们
1.面向对象的软件测试的基本概念
面向软件测试技术是新兴的软件测试技术，是专门针对使用面向对象技术开发的软件而提出的一种测试技术。
其目的是为了解决传统的软件测试技术，面对面向对象技术开发的软件多少显得有些力不从心的现象。
面向对象开发技术和传统的开发技术相比，新增了多态、继承、封装等特点。
这些新特点使得开发出来的程序，具有更好的结构更规范的编程风格,极大地优化了数据使用的安全性,提高了代码的重用率。
由此可见，它们是面向对象开发技术产生巨大吸引力的重要因素。
然而，另一方面也影响了软件测试的方法和内容；增加了软件测试的难度；带来了传统软件设计技术所不存在的错误；或者使得传统软件测试中的重点不再显得突出；或者使原来测试经验认为和实践证明的次要方面成为了主要问题。
面向对象软件测试是根据面向对象的软件开发过程结合面向对象的特点提出的。
它包括分析与设计模型测试技术、类测试技术、对象交互测试技术、类层次结构测试技术、面向对象系统测试技术五大部分。
下面分别围绕这五部分展开讨论。
2.分析和设计模型测试技术
面向对象软件开发的起始步骤是开发分析和设计模型。
UML（统一建模语言）能在面向对象技术开发中广泛应用，也是因为构建模型能帮助开发者理解正在解决的问题；构建模型能帮助管理正在开发的系统的复杂性；分析和设计阶段建构的模型最后将对具体地实现起指导作用。
如果模型的质量很高对项目来说就很有价值；但是如果模型有错误，那么它对项目的危害就无可估量。
2.1.分析和设计模型测试的内容
分析和设计模型测试的重点是测试模型的完整性和一致性,其主要内容有：
1. 对确定的对象的测试；
2. 对确定的结构的测试；
3. 对确定的主题的测试；
4. 对定义的属性和实例关联的测试；
5. 对定义的服务和消息关联的测试。
2.2.分析和设计模型测试的方法
分析与设计模型的测试主要是对分析与设计模型进行测试，找出模型中的错误，其采用的方法是指导性审查（guidedinspection）。
指导性审查技术通过使用明确的测试用例为查找工作成果中的缺陷提供了客观的、系统的方法。
是一种增强了的专为检验模型的检测技巧，也可用来验证模型是否能符合项目的需求。
其基本步骤如下：
1. 定义测试位置。
2. 使用特定的策略从测试位置选择测试值。
3. 将测试值应用到被测试的产品中。
4. 对测试结果以及对模型的测试覆盖率（基于某中标准）进行评估。
这些步骤经过具体化后形成下列详细步骤：
1. 制订检查的范围和深度：
范围将通过描述材料的实体或一系列详细的用例来定义。
对小的项目来说，范围可以是整个模型。
深度将通过指定须要测试的模型（MUT）的某种UML图的集合层次中的级别来定义。
2. 确定MUT产生的基础：
除原始模型之外，所有的UMT的基础是前一开发阶段创建的一系列模型：
比如，应用分析模型就是以域分析模型和用例模型为基础。
起初模型则是基于所选择的一组人头脑里的知识。
3. 为每一个评价标准开发测试用例，标准在应用时使用基本模型的内容作为输入。
这种从用户用例模型出发的方式对许多模型的测试用例来说是一个很好的出发点。
4. 为测量测试的覆盖率建立标准。
比如对一个类图来说，如果图中每一个类都被测试到了，那么覆盖率就算不错了。
5. 使用合适的检查列表进行静态分析。
将MUT与基本的模型相比较可以确定2个图型之间的连贯性。
6. “执行”测试用例。
7. 使用测试用例覆盖率衡量法对测试的效率进行评价，计算覆率率百分比。
比如，测试用例“涉及”到了包含18个类的类图中的12个类，那么测试的覆盖率就是75%。
鉴于分析和设计模型的测试如此高级，以至于要达到好的结果，必须有100%的覆盖率。
8. 如果覆盖率不充分，就要对测试进行扩充并应用额外的测试用例。
否则终止正在进行的测试。
通常无法在检查片断的过程中写下附加的测试用例。
测试者确定哪些地方没有覆盖到并与开发者一起确定将触及未覆盖的模型组件的潜在的测试用例。
然后，测试者创建整个的测试用例并且进行另一次检查。
采用指导性审查技术对分析和设计产生的文本进行正确性验证,是软件开发前期的关键性测试。
3.类测试技术
面向对象软件产品的基本组成单位是类，从宏观上来看，面向对象软件是各个类之间的相互作用。
在面向对象系统中,系统的基本构造模块是封装了的数据和方法的类和对象,而不再是一个个能完成特定功能的功能模块。
每个对象有自己的生存周期,有自己的状态。
消息是对象之间相互请求或协作的途径,是外界使用对象方法及获取对象状态的惟一方式。
对象的功能是在消息的触发下,由对象所属类中定义的方法与相关对象的合作共同完成。
且在不同状态下对消息的响应可能完全不同。
工作过程中对象的状态可能被改变,产生新的状态。
对象中的数据和方法是一个有机的整体,测试过程中不能仅仅检查输入数据产生的输出结果是否与预期的吻合,还要考虑对象的状态，且在不同状态下对消息的响应可能完全不同。
工作过程中对象的状态可能被改变,产生新的状态。
对象中的数据和方法是一个有机的整体,测试过程中不能仅仅检查输入数据产生的输出结果是否与预期的吻合,还要考虑对象的状态。
类测试是由那些与验证类的实现是否和该类的说明完全一致的相关联的活动组成的。
该类测试的对象主要是指能独立完成一定功能的原始类。
如果类的实现正确，那么类的每一个实例的行为也应该是正确的。
3.1.类测试的内容
类测试的目的主要是确保一个类的代码能够完全满足类的说明所描述的要求．对一个类进行测试以确保他只做规定的事情，对此给与关注的多少，取决于提供额外的行为的类相关联的风险．在运行了各种类的测试后，如果代码的覆盖率不完整，这可能意味着该类包含了额外的文档支持的行为．需要增加更多的测试用例来进行测试。
3.2.类测试的时间
类测试的开始时间一般在完全说明这个类，并且准备对其编码后不久，就开发一个测试计划——至少是确定测试用例的某种形式。
如果开发人员还负责该类的测试，那么尤其应该如此。
因为确定早期测试用例有利于开发人员理解类说明，也有助于获得独立代码检查的反馈。
类测试可以在开发过程中的不同位置进行。
在递增的反复开发过程中，一个类的说明和实现在一个工程的进程中可能会发生变化，所以因该在软件的其它部分使用该类之前执行类的测试。
每当一个类的实现发生变化时，就应该执行回归测试。
如果变化是因发现代码中的缺陷（bug）而引起的，那么就必须执行测试计划的检查，而且必须增加或改变测试用例以测试在未来的测试期间可能出现的那些缺陷。
3.3.类测试的测试人员
类测试通常由他的开发人员测试，让开发人员起到测试人员的作用，就可使得必须理解类说明的人员数量减至最少。
而且方便使用基于执行的测试方法，因为他们对代码极其的熟悉。
由同一个开发者来测试，也有一定的缺点：
开发人员对类说明的任何错误理解，都会影响到测试。
因此，最好要求另一个类的开发人员编写测试计划，并且允许对代码进行对立检查。
这样就可以避免这些潜在的问题了。
3.4.类测试的方法
类测试的方法有代码检查和执行测试用例。
在某些情况下，用代码检查代替基于执行的测试方法是可行的，但是，和基于执行的测试相比，代码检查有以下两个不利之处：
1． 代码检查易受人为因素影响。
2． 代码检查在回归测试方面明显需要更多的工作量，常常和原始测试差不多。
尽管基于执行的测试方法克服了以上的缺点，但是确定测试用例和开发测试驱动程序也需要很大的工作量。
在某些情况下，构造一个测试驱动程序的工作量比开发这个类的还多，此时就应该评估在使用了这个类的系统之外测试测试这个类所花的代价和带来的收益。
一旦确定了一个类的可执行测试用例，就必须执行测试驱动程序来运行每一个测试用例，并给出每一个测试用例的结果。
3.5.测试程度
可以根据已经测试了多少类实现和多少类说明来衡量测试的充分性。
对于类的测试，通常需要将这两者都考虑到，希望测试到操作和状态转换的各种组合情况。
一个对象能维持自己的状态，而状态一般来说也会影响操作的含义。
但要穷举所有组合式不可能的，而且是没必要的。
因此，就因该结合风险分析进行选择配对系列的组合，以致达到使用最重要的测试用例并抽取部分不太重要的测试用例。
3.6.构建类测试用例
要对类进行测试，就必须先确定和构建类的测试用例。
类的描述方法有OCL,自然语言，和状态图等方法，可以根据类说明的描述方法构件类的测试用例。
因而，构建类的测试用例的方法有：
根据类说明（用OCL表示）确定测试用例和根据类的状态转换图来构建类的测试用例。
根据类的说明确定测试用例 用OCL表示的类的说明中描述了类的每一个限定条件条件。
在OCL条件下分析每个逻辑关系，从而得到由这个条件的结构所对应的测试用例。
这种确定类的测试用例的方法叫做根据前置条件和后置条件构建测试用例。
其总体思想是：
为所有可能出现的组合情况确定测试用例需求。
在这些可能出现的组合情况下，可满足前置条件，也能够到达后置条件。
根据这些需求，创建测试用例；创建拥有特定输入值（常见值和特殊值）的测试用例；确定它们的正确输出——预期输出值。
根据前置条件和后置条件创建测试用例的基本步骤如下：
1． 确定在表1中与前置条件形成相匹配的各个项目所指定的一系列前置条件的影响。
2． 确定在表2中与后置条件形成相匹配的各个项目所指定的一系列前置条件的影响。
3． 根据影响到列表中各个项目的所有可能的组合情况从而构造测试用例需求。
一种简单的方法就是：
用第一个列表中的每一个输入约束来代替第二个列表中每一个前置条件。
4． 排除表中生成的所有无意义的条件。
表1 前置条件对测试系列的影响
前置条件
影响
True
（true、post）
A
（A、post）
（notA、exception）*
NotA
（notA、post）
（A、exception）*
AandB
（AandB、post）
（notAandB、exception）*
（AandnotB、exception）*
（notAandnotB、exception）*
AorB
（A、post）
（B、post）
（AandB、post）
（notAandnotB、post）
AxorB
（notAandB、post）
（AandnotB、post）
（AandB、exception）*
（notAandnotB、exception）*
AimpliesB
（notA、post）
（B、post）
（notAandB、post）
（AandnotB、exception）*
ifAthenB
elseCendif
（AandB、post）
（notAandC、post）
（AandnotB、exception）*
（notAandnotC、exception）*
注：
①．A、B、C代表用OCL表示的组件。
②．假如类说明中的保护性设计方法是隐式的，那么也必须对那些标记有*的测试用例进行阐述。
如果保护性设计方法在类的说明中是显式出现的，那么测试用例也就确定了。
表2 后置条件对测试系列的影响
后置条件
影响
A
（pre；A）
AandB
（pre；AandB）
AorB
（pre；A）
（pre；B）
（pre；AorB）
AxorB
（pre；notAorB）
（pre；AornotB）
AimpliesB
（pre；notAorB）
ifAthenB
elseCendif
（preand*；B）
（preandnot*；C）
注：
①．A、B、C代表用OCL表示的组件。
②．对于“ifAthenBelseCendif”这个后置条件，假如测试用例不会对表达式A产生影响那么在用这个后置条件时，*=Aelse*就是使得A为真的一个条件
根据状态转换图构建测试用例 状态转换图以图例的形式说明了与一个类的实例相关联的行为。
状态转换图可用来补充编写的类说明或者构成完整的类说明。
状态图中的每一个转换都描述了一个或多个测试用例需求。
因而，可以用过在转换的每一端选择有代表性的值和边界来满足这些需求。
如果转换是受保护的，那么也应该为这些保护条件选择边界。
状态的边界值取决于状态相关属性值的范围，可以根据属性值来定义每一个状态。
由此可见，和根据前置条件和后置条件创建类的测试用例相比，根据状态转换图创建类的测试用例有非常大的优势。
在类的状态图中，类相关联的行为非常的明显和直观，测试用例的需求直接来自于状态转换，因而很容易确定测试用例的需求。
不过基于状态图的方法也有其不利的方面。
如要完全理解怎样根据属性值来定义状态；事件是如何在一个给定的状态内影响特定值等。
这都很难仅从简单的状态图中确定。
因此，在使用基于状态转换图进行测试时，务必在生成的测试用例时检查每个状态转换的边界值和预期值。
4.类层次结构测试技术
继承作为代码复用的一种机制，可能是面向对象软件开发产生巨大吸引力的一个重要因素。
继承由扩展、覆盖和特例化三种基本机制实现的。
其中，扩展是子类自动包含父类的特征；覆盖是子类中的方法与父类中的方法有相同的名字和消息参数以及相同的接口，但方法的实现不同；特例化是子类中特有的方法和实例变量。
好的面向对象程序设计要求通过非常规范的方式使用继承——即代码替代原则。
在这种规则下，为一个类确定的测试用例集对该类的子类也是有效的。
因此，额外的测试用例通常应用于子类。
通过仔细分析根据父类定义的子类的增量变化，有时候，子类中的某些部分可以不做执行测试。
因为应用于父类中的测试用例所测试的代码被子类原封不动的继承，是同样的代码。
类的层次结构测试就是用来测试类的继承关系的技术，主要是用来测试层次关系的一系列类（包括父类和子类）。
其测试的方法有用于测试子类的分层增量测试和用于测试父类的抽象类测试。
4.1.分层、增量测试
C
D
Voidop1（）;
Voidop2（）;
Voidop2（）;
Voidopen（）;
Newvartype;
说 明
子类D添加了一个新的实例变量（NewVar）和一个新的操作（newop（））。
D重载了C中定义的方法op2（），因为该操作在D中有新的规范或操作的实现
图1 类的派生及增量变化
分层增量测试（hierarchicalincrementaltesting（HIT））指通过分析来确定子类的哪些测试用例需要添加，哪些继承的测试用例需要运行，以及哪些继承的测试
升级会员 