0740陈冬连最终稿.docx

上传人:b****4 文档编号:5464594 上传时间:2022-12-16 格式:DOCX 页数:29 大小:369.06KB
下载 相关 举报
0740陈冬连最终稿.docx_第1页
第1页 / 共29页
0740陈冬连最终稿.docx_第2页
第2页 / 共29页
0740陈冬连最终稿.docx_第3页
第3页 / 共29页
0740陈冬连最终稿.docx_第4页
第4页 / 共29页
0740陈冬连最终稿.docx_第5页
第5页 / 共29页
点击查看更多>>
下载资源
资源描述

0740陈冬连最终稿.docx

《0740陈冬连最终稿.docx》由会员分享,可在线阅读,更多相关《0740陈冬连最终稿.docx(29页珍藏版)》请在冰豆网上搜索。

0740陈冬连最终稿.docx

0740陈冬连最终稿

学科分类号:

____520.3050

湖南人文科技学院

本科生毕业论文

 

论文题目:

白盒测试和黑盒测试在

动态软件测试中的应用

(英文):

TheApplicationofWhiteBoxTestingandBlackBox

TestinginDynamicSoftwareTesting

学生姓名:

陈冬连

学号

07420140

系部:

计算机科学技术系

专业年级:

网络工程2007级

指导教师:

谢东

职称:

副教授

湖南人文科技学院教务处制

湖南人文科技学院本科毕业论文诚信声明

 

本人郑重声明:

所呈交的本科毕业论文,是本人在指导老师的指导下,独立进行研究工作所取得的成果,成果不存在知识产权争议,除文中已经注明引用的内容外,本论文不含任何其他个人或集体已经发表或撰写过的作品成果。

对本文的研究做出重要贡献的个人和集体均已在文中以明确方式标明。

本人完全意识到本声明的法律结果由本人承担。

 

作者签名:

二○年月日

目录

摘要1

关键词1

Abstract1

KeyWords2

第一章绪论3

1.1软件测试概述3

1.2研究的目的与意义4

1.3国内外研究现状4

1.4本文的主要研究内容与方法7

1.5论文的组织结构7

1.6论文的技术要求8

第二章动态测试基础8

2.1软件测试方法8

2.1.1白盒测试和黑盒测试的定义8

2.1.2白盒测试和黑盒测试的区别9

2.2软件测试技术9

2.2.1白盒测试的常用技术9

2.2.2黑盒测试的常用技术10

2.2.3白盒测试和黑盒测试的常用技术的应用场景10

2.3动态测试的关键问题11

第三章动态测试在银行业务软件中的应用11

3.1程序次模块设计12

3.2次模块测试设计18

3.3次模块测试执行21

第四章总结与展望23

致谢25

 

白盒测试和黑盒测试在动态软件测试中的应用

摘要:

软件测试是高质量、高可靠性软件的重要保证。

在软件系统的开发中,软件测试不仅是软件生命周期中的一个独立的阶段,在需求分析、软件设计和编码阶段,都需要对这些阶段的软件产品,包括需求规格说明书、软件架构、概要设计和详细设计说明书进行测试。

软件测试已经形成了完整的、系统的测试方法,并且有众多的手工和自动化测试工具支持这些方法。

通过评审文档、阅读代码等方式测试软件称为静态测试,通过运行程序测试软件称为动态测试。

在动态测试中,通常使用白盒测试和黑盒测试从不同的角度设计测试用例,查找软件代码中的错误。

白盒测试和黑盒测试是软件测试中的常用方法。

文章首先介绍了白盒测试和黑盒测试以及两者的应用场合,然后通过一个实例说明在动态软件测试中如何使用这两种方法从不同的角度设计测试用例,确保以最少的测试用例发现尽可能多的错误和缺陷。

银行业务软件以其高复杂性、高安全性、高准确性、高效率性给软件测试带来了一系列难度。

银行业务软件通常由一系列功能相对独立的程序组成,每一个程序完成一个特定的功能(称之为交易)。

而这些特定功能实际由一个或者多个子功能组成,这些子功能彼此之间存在顺序执行或者嵌套执行的关系,这就为程序内部的次模块(次模块是单元测试的最小单元定义,是组成模块的部分,包含若干行源代码,不能被单独执行或者被其他模块调用,逻辑复杂度远低于模块)划分提供了可能。

本文就是以银行业务中处理较简单的活期储蓄存折取款交易为例来说明白盒测试和黑盒测试在动态软件测试中的应用。

先对取款模块的需求进行分析,划出取款模块的程序流程图以及相关的参数说明和数据关系图。

为了以最少的测试用例发现尽可能的错误和缺陷。

主要采用黑盒测试中的等价类划分法、因果图法和判定表法以及白盒测试中逻辑覆盖法,对次模块F(手续费的计算进行分析)。

关键词:

白盒测试;黑盒测试;测试用例

TheApplicationofWhiteBoxTestingandBlackBoxTestinginDynamicSoftwareTesting

Abstract:

Softwaretestingisofhighquality,reliability,thesoftwareto.insoftwaresystemsdevelopment,thesoftwaretestingisnotonlysoftwarelifecycleofanindependent,analysis,theneedsofsoftwaredesignandcoding,theneedforthestageofthesoftwarerequirements,specifications,includingthesoftwarearchitectureanddesignanddetaileddesignspecificationsasummaryoftest.softwaretestinghavedevelopedacomplete,systematictestmethod.Andtherearenumeroushandtoolsandautomatedteststosupportthesemethods.throughthedocuments,readthecodestatically,tosoftwaretestingisthetest,byrunningprogramstosoftwaretestingiscalledactivetest.inthedynamictestsusuallyusecartonoftestandwhiteblackboxfromtheperspectiveofthedifferentdesignfortestingforexample,thesoftwarecode.

Whiteboxtestingandblackboxtestingarefrequentlyusedinsoftwaretesting.Thispaperintroducesthetwomethods.Thenitdemonstrateshowtousethemtodesigntestingcasefromdifferentpointofviewindynamicsoftwaretesting,sothatmoreerrorsorbugscanbefoundwithlesstestingcase.

Bankingsoftwaretotheirhighercomplexityandhighsecurityandhigheraccuracy,efficienttosoftwaretestingofaseriesofdifficulty.theordinarysoftwaretestprocedureandmethodisverydifficulttoalltheclaim.bankingsoftwareusuallybyaseriesoffunctionalrelativelyindependentprogram,eachapplicationtoperformaspecificfunction(callthedeal.buttheseparticularfeatures)actualbyoneormorefunctional,andthesefunctionsarecarriedoutbetweentheorderoranestingrelationship,Forapplicationwithinthefirstmodules(moduleistheunittestingofthesmallestunitsofthemoduledefinition,ispartofthesourcecode,containingseverallines,notbyindividualexecutiveorothermodulescalledalogicalcomplexthan)intomodulesprovides.

Thisisthebankaddressedinasimplecurrentsavingspassbookorwithdrawmoneyforthattransactionasanexampleoftestandblackboxoftestinginthedynamicsoftwaretestapplicationforwithdrawal.thefirstmodulesdemand,andpulloutawithdrawalofthemodulesprogramflowchartandtherelatedparametersinstructionsanddatadiagram.inordertothetestusedasexamplesfoundanddefects.Mainlyusedblacktesttheclassdividedintotheequivalent,andthemethodanddeterminethemethodoftestingandwhiteoverthelogic,tofoftheservicemodules(analysis).

KeyWords:

whiteboxtesting;blackboxtesting;testingcase

 

第一章绪论

从计算机诞生至今,计算机无疑成为当代发展最为迅猛的科学技术。

今天,计算机己渗透到人们生活的各个方面。

纵观计算机技术的发展历程,特别是近20年来,由于微电子技术的进步,计算机硬件技术飞速发展,其性能价格比显著提高,质量稳步增长,为计算机的广泛应用创造了良好的条件。

作为计算机的灵魂,软件起着举足轻重的作用,但软件技术在产品质量、生产力、成本及性能等众多方面都滞后于硬件技术的发展。

随着软件系统规模和复杂性的增加,其开发成本以及由于软件故障而造成的经济损失也正在增加,软件质量问题已成为制约计算机发展的关键因素之一。

软件测试是对软件功能、设计和实现的最终审定,是发现软件故障,保证软件质量,提高软件可靠性的主要手段。

因此,软件测试在软件开发中起着不可替代的作用。

但是,软件测试费用相当昂贵,通常占到整个软件开发成本的50%左右。

近年来,虽然软件测试技术与实践有了很大的进展,但远未成熟,测试理论、测试方法都无法满足当前软件开发的实际需要。

为此,改进已有的软件测试方法,开发一些实用的测试数据自动生成工具,提高软件测试效率,是软件测试工程师目前乃至今后面临的紧迫而且意义重大的任务。

1.1软件测试概述

信息技术的飞速发展,使软件产品应用到社会的各个领域,且规模越来越庞大,软件产品的质量自然成为人们共同关注的焦点。

原先以手工作坊式方法开发出来的许多软件产品,由于缺乏科学的软件质量管理,因此几乎无法维护,造成大量人力、物力浪费。

如何提高软件质量,保证软件安全性是一个涉及面广、难度很大的课题。

软件测试作为软件质量保证中的关键技术,正受到人们越来越多的关注。

软件测试是伴随着软件的产生而产生的。

早期的软件开发过程中,测试的含义比较狭窄,将测试等同于“调试”,目的是纠正软件中己经知道的故障,常常由开发人员自己完成这部分的工作。

对测试的投入极少,测试介入也晚,常常是等到形成代码,产品己经基本完成时才进行测试。

直到1957年,软件测试才开始与调试区别开来,作为一种发现软件缺陷的活动。

但由于一直存在着“只有产品开始工作了,才能对其进行测试”的思想,测试仍然是后于开发的活动。

潜意识里,我们的目的就是使自己确信产品能够工作。

20世纪70年代,尽管对“软件工程”的真正含义还缺乏共识,但这一词条己经频繁出现。

1972年,在美国北卡罗来纳大学举行了首届软件测试正式会议。

1979年,GlenfordMyers的((软件测试艺术》(TheArtofsoftwareTesting)中做出了当时最好的软件测试定义:

“测试是为发现错误而执行的一个程序或者系统的过程。

直到20世纪80年代,美国等发达国家的软件业进入以过程为中心的工业化时代,软件的全面质量管理才开始被人们理解和重视。

软件测试定义发生了改变,测试不单纯是一个发现错误的过程,而且包含软件质量评价的内容。

软件开发人员和测试人员开始坐在一起探讨软件工程和测试问题。

制定了各类标准,包括IEEE(InstituteofElectricaland

ElectronicEngineers)标准、美国ANSI(AmericanNationalStandardInstitute)标准以及150(InternationalStandardOrganization)国际标准。

1983年,BillHetzel在《软件测试完全掼》(CompleteGuideofsoftwareTesting)一书中指出:

“测试是以评价一个程序或者系统属性为目标的任何一种活动。

测试是对软件质量的度量。

”MyerS和HetZel的定义至今仍被引用。

到了2002年,RickD.Craig和stefanP.Jaskiel在《系统的软作测试》(Systematic

SoftwareTesting)中对软件测试做了进一步定义:

“测试是为了度量和提高被测软件的质量,对测试件进行工程设计、实施和维护的整个生命周期过程。

”这些经典论著对软件测试研究的理论化和体系化产生了巨大的影。

近20年来,随着计算机和软件技术的飞速发展,软件测试技术研究也取得了很大的突破。

测试专家总结了很好的测试模型,比如著名的V模型、W模型等,在测试过程改进方面提出了TMM(TestingMaturityModel)的概念,在单元测试、系统测试、负载压力测试以及测试管理等方面涌现了大量优秀的软件测试工具。

1.2研究的目的与意义

软件测试是高质量、高可靠性软件的重要保证。

在软件系统的开发中,软件测试不仅是软件生命周期中的一个独立的阶段,在需求分析、软件设计和编码阶段,都需要对这些阶段的软件产品,包括需求规格说明书、软件架构、概要设计和详细设计说明书进行测试。

软件测试已经形成了完整的、系统的测试方法,并且有众多的手工和自动化测试工具支持这些方法。

通过评审文档、阅读代码等方式测试软件称为静态测试,通过运行程序测试软件称为动态测试。

在动态测试中,通常使用白盒测试和黑盒测试从不同的角度设计测试用例,查找软件代码中的错误。

因此要想软件高质量,用怎样的方法设计测试用例是关键。

其中白盒测试和黑盒测试是设计测试用例最常用的方法,尤其在动态软件测试中,通过这两种方法从不同的角度设计测试用例,确保以最少的测试用例发现尽可能多的缺陷和错误。

1.3国内外研究现状

软件测试相关的理论及方法从产生到现在己近四十年了,国内外对于软件测试的研究主要分为测试理论、测试技术、测试评价等方面。

测试理论的研究主要分为测试管理、测试模型等方面。

测试管理实际上属于软件工程的一部分,并被纳入软件质量体系中。

(l)质量体系

质量体系是软件管理工程的三个部分。

软件过程改善是当前软件管理工程的核心问题,50多年来计算机的发展使人们认识到要高效率、高质量和低成本地开发软件,必须改善软件生产过程。

基于模型的过程改进是指用能力模型来指导组织的过程改进,仗过程能力稳定的进行改善,该组织也能变得更加成熟。

美国卡丙基梅隆大学软件工程学院于1987年研究成功的SW/-CMM(CapabilityMaturityModelforsoftware)的目的就在于帮助软件组织改善软件生产流程,以探索一个保证软件质量、缩短开发周期、提高工作效率的软件工程模式与标准规范。

1997年10月SEI(SoftwareEngineeringInstitute)停止对CMM的研究,改而致力于CMMI(CapabilityMaturityModelIntegration),以解决使用多个过程改进模型的问题。

SEI同时宣布CMMI将取代CMM,与2000年8月11日颁布了CMMI-SE/SW1.0版本,2001年12月颁布了1.1版本,这次发布标志着CMMI的正式启用。

根据CMMI的软件生命周期,测试被分为三个阶段:

单元测试;集成测试;系统测试。

这三个阶段的测试在软件生命周期的其他主要阶段分别具有不同的活动性。

而且CMMI充分考虑这三个阶段的测试的不同之处,分别制定不同的操作规范。

CMMI主要从以下三个方面扩充传统的软件测试技术:

第一方面,从单纯的对软件的测试活动,扩展为软件的测试和开发过程的度量。

这一方面主要体现在过程度量对软件测试的依赖和应用。

对开发过程进行度量,需要利用软件及中间成果的测试结果,从而建立对软件缺陷和开发过程的跟踪。

从这一点来说,对开发过程的度量,实际上也就是对软件测试活动的扩展,与传统的软件测试的不同之处就在于关注对软件测试结果数据的分析和利用,将测试数据有效转换为能够标识过程缺陷的统计数据。

第二方面,软件测试由原来的事后测试行为发展为全过程测试和分析,成为一种缺陷预防的有效方式。

传统的软件测试,只针对软件而开展,找到缺陷之后再加以改正和修补,这是一种“亡羊补牢”的质量管理方式;而针对开发全过程所开展的软件测试和过程度量,则注重根据对测试数据的统计分析结果,来判断软件的未来质量趋势,并提前予以控制和预防,属于一种“防患于未然”的质量管理方式。

与传统的软件测试相比,全过程测试不仅可以有效降低软件的质量风险,而且还可以提前对软件缺陷进行规避,这不仅缩短了对缺陷的反馈周期和整个项目的开发周期,而且大大降低了软件的维护费用,对于软件的整个生命周期都有很重大的意义。

第三方面,软件测试与开发过程的其他阶段不再是串行工作方式,而是与整个开发过程并行进行。

与瀑布模型相比,CMMI模型中所描述的软件测试和过程度量工作与整个开发过程是并行进行的。

软件测试活动存在于软件生命周期的各个阶段,其基本特点是以质量保证和客户要求为核心开展对软件和开发过程的测试和度量,力争将缺陷控制在软件开发过程的每一个阶段,从而有效缩短开发周期,降低质量风险,并且及时吸取经验教训,提供对过程改进的支持。

(2)测试模型

测试模型除了传统的瀑布模型外,还有V模型、W模型、H模型等。

V模型最早是由PaulRook在20世纪80年代后期提出的,旨在改进软件开发的效率和效果。

V模型反映出了测试活动与分析设计活动的关系。

V模型指出,单元和集成测试应检测程序的执行是否满足软件设计的要求;系统测试应检测系统功能、性能的质量特性是否达到系统要求的指标;验收测试确定软件的实现是否满足用户需要或合同的要求。

V模型把测试作为编码之后的一个阶段,是针对程序进行的寻找错误的活动,而忽视了测试活动对需求分析、系统设计等活动的验证和确认的功能。

W模型由Evolutif公司提出。

相对于V模型,W模型增加了软件各开发阶段中应同步进行的验证和确认活动。

W模型强调:

测试伴随着整个软件开发周期,而且测试的对象不仅仅是程序,需求、设计等同样需要测试,测试与开发是同步进行的。

W模型有利于尽早地全面地发现问题。

在W模型中,需求、设计、编码等活动被视为串行的,同时测试和开发活动也保持着一种线性的前后关系,上一阶段完全结束,才可正式开始下一个阶段工作。

这样就无法支持迭代的开发模型。

对于当前软件开发复杂多变的情况,W模型并不能完全解除测试管理所面临的困惑。

V模型和W模型均把软件的开发视为需求、设计、编码等一系列串行的活动,而事实上,这些活动在大部分时间内是可以交叉进行的,所以,相应的测试之间也不存在严格的次序关系。

同时,各层次的测试(单元测试、集成测试、系统测试等)也存在反复触发、迭代的关系。

为了解决以上问题,产生了H模型,它将测试活动完全独立出来,形成了一个完全独立的流程,将测试准备活动和测试执行活动清晰地体现出来。

H模型揭示了一个原理:

软件测试是一个独立的流程,贯穿产品整个生命周期,与其他流程并发地进行。

H模型指出软件测试要尽早准备,尽早执行。

不同的测试活动可以是按照某个次序先后进行的,但也可能是反复的,只要某个测试达到准备就绪点,测试执行活动就可以开展。

除上述几种常见模型外,业界还流传着其他几种模型,如X模型、前置测试模型等。

X模型提出针对单独的程序片段进行相互分离的编码和测试,此后通过频繁的交接,通过集成最终合成为可执行的程序。

前置测试模型体现了开发与测试的结合,要求对每一个交付内容进行测试。

这些模型都针对其他模型的缺点提出了一些修正意见,但本身也存在一些不周到的地方。

测试技术的研究除了对于已有的测试方法,如白盒测试、黑盒测试等进行改进外,目前比较突出的方向有自动测试、面向对象测试等等。

(3)自动测试

软件测试一般分为手工测试和自动测试。

软件规模的扩大给测试工作带来很多问题,手工测试的速度慢,效率低。

自动测试可以高效的完成一些重复性测试;降低人为因素对测试过程的干扰;排除测试的随机性和盲目性;降低冗余,减少遗漏等。

软件自动测试就是执行某种程序设计语言编制的自动测试程序,控制被测软件的执行,模拟手动测试步骤,完成全自动或半自动测试。

其目的在于缩短测试周期,增强对软件性能等方面的测试能力。

自动测试也存在其局限性:

第一,自动测试工具本身也是软件,其自身也需要测试,一旦自身品质存在问题,将对整个测试的有效性和正确性带来严重影响;第二,对于银行业务软件这种复杂的软件系统,自动测试工具很难满足要求。

所以在银行业务软件开发中,自动测试的使用一直受到很大限制,主要用于压力测试等对于执行结果准确性要求不高的测试中,而对于准确性要求很高的功能测试,仍然主要依靠人工完成。

随着软件的规模和复杂度的提高,软件的质量好坏已经不可能简单通过测试所发现的缺陷的多少来判断了,这便把测试评价的研究推上了日程。

另外为了更有效地进行测试,在软件可靠性评价和可测性评价方面也有所发展。

测试评价严格意义上来讲,不只是对测试的评价,应该是对软件的品质及整个测试过程的评价。

在实际应用中,软件企业虽然十分重视测试的进行,往往投入40%的成本进行测试,但是在对测试的评价方面却仍然停留在比较初级的阶段,主要使用的有缺陷走趋图、缺陷严重程度分布图和一些简单的统计数据分析等方法,而且基本依靠个人经验判断和简单的趋势分析。

比如,通过缺陷走势图和缺陷严重程度分布图可以很清楚看出软件缺陷的走向和分布情况,对于测试评价有一定帮助。

但是存在指标量化不足,评价指标过于单一的缺点,重复操作性低,在实际使用中对进行测试评价的人员要求很高。

(4)软件可靠性评价

软件的可靠性是指软件系统在特定的环境下,在给定的时间内,不发生故障地工作的概率。

软件可靠性是评价软件质量的一个重要指标。

软件可靠性评价主要通过建立软件可靠性模型来实现。

软件可靠性模型是随机过程的一种表示,通过这一表

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 党团工作 > 党团建设

copyright@ 2008-2022 冰豆网网站版权所有

经营许可证编号:鄂ICP备2022015515号-1