文档库

最新最全的文档下载
当前位置:文档库 > 软件测试毕业论文

软件测试毕业论文

软件测试毕业论文

毕业论文

姓名:陈鑫

专业:.Net软件开发年级:计软1302

学号:201317140212指导教师:王梅

软件测试的概述及方法

、、

完成时间:2012年3月

摘要:从软件产业的发展初期到目前的大型软件开发过程,软件测试已成为其中一个不可分割的部分。随着软件规模的日益增大,软件测试问题也日益突出,现代社会对软件的依赖越来越强,高可信软件测试有着广泛的需求,基于缺陷模式的软件测试技术作为高可信软件的重要保证,可以大大降低软件的缺陷密度,提高软件的可信性。本文从测试的基本概念入手,深入剖析软件测试相关理论

关键字:软件测试、白盒测试、黑盒测试、类测试

目录

1 软件测试的发展史 (4)

2软件测试的相关背景 (5)

3 软件测试概述 (6)

3.1软件测试的定义 (6)

3.2软件测试的描述 (6)

3.3软件测试的目的 (7)

3.4软件测试的原则 (8)

4 软件测试的内容 (9)

4.1验证(verification) (9)

4.2确认(validation) (9)

5 软件测试的分类 (10)

5.1 常用分类 (10)

错误!未定义书签。

5.2 黑盒测试 (10)

5.3白盒测试 (11)

5.4 静态测试 (14)

5.5动态测试 (15)

6 软件测试中的类测试 (15)

6.1面向对象软件的类测试概念 (15)

6.2.类测试技术 (16)

7 参考文献 (17)

8 致谢 (18)

1软件测试的发展史

软件测试的发展历史:20世纪60年代(软件工程建立前),为表明程序正确而进行测试。. 1972年在北卡罗来纳大学举行了首届软件测试正式会议。. 1975年John Good Enough和Susan Gerhart在IEEE 上发表了《测试数据选择的原理》的文章,软件测试被确定为一种研究方向。. 1979年,Glenford Myers的《软件测试艺术》,对测试做了定义:测试是为发现错误而执行的一个程序或者系统的过程。. 20世纪80年代早期,“质量”的号角开始吹响。软件测试定义发生了改变,测试不单纯是一个发现错误的过程,而且包含软件质量评价的内容。制定了各类标准。. 1983年,Bill Hetzel在《软件测试完全指南》中指出:测试是以评价一个程序或者系统属性为目标的任何一种活动,测试是对软件质量的度量。. 20世纪90年代,测试工具盛行起来。. 1996年提出的测试能力成熟度TCMM(Testing Capability Maturity Model)、测试支持度TSM(Testability Support Model)、测试成熟度TMM(Testing Maturity Model)。. 到了2002年,Rick 和Stefan在《系统的软件测试》一书中对软件测试做了进一步定义:测试是为了度量和提高被测软件的质量,对测试软件进行工程设计、实施和维护的整个生命过程。

2软件测试的相关背景

相关背景:前段时间, 就是在我没有认真了解测试行业之前, 可能由于测试在中国的重视程度的问题, 我也一直认为测试应该是不重要的, 甚至认为有必要有专门的测试职业吗?认为软件主要是开发人员的事, 软件的成果也是由开发人员决定的, 当我在参加工作后, 真正从学校的学习环境中走上实际运用开发的时候, 事实上真的不是那么一回事哦。软件无处不在, 软而, 软件是人编的——所以不完美。臭名昭著的软件测试案例:

1、迪士尼的狮子王(1994~1995)软件在少数系统中能正常工作, 但在大众使用的常见系统中不行。后来证实, 迪士尼公司没有对市场上投入实用的各种pc机型进行正确的测试。

2、英特尔奔腾浮点除法软件缺陷(1994)英特尔为自己处理软件缺陷拿出4亿美元支付更换坏芯片的费用。导致付出如此昂贵的代价, 其主要原因是发现了软件缺陷没有正确的处理。

3、美国航天局火星极地登陆(1999)该项目使用前有经过测试, 两个测试小组双方独立工作都很好, 但从未走在一起。

4、爱国者导弹防御系统(1991)一枚导弹在多哈击毙28名美国士兵, 症结在于一个软件缺陷:一个很小的系统时钟错误累积起来就可能拖延14小时, 造成跟踪系统失去准确度。在多哈袭击战中系统被拖延100小时。

5、千年虫(大约1974)估计世界各地更换或升级该系统程序解决原有2000年错误的费用已经超过数亿美元。

3软件测试的概述

3.1软件测试的定义

软件测试使用人工或者自动手段来运行或测试某个系统的过程,其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别。它是帮助识别开发完成(中间或最终的版本)的计算机软件(整体或部分)的正确度(correctness) 完全度(completeness)和质量(quality)的软件过程;是SQA(software quality assurance)的重要子域。

(1)测试并不仅仅是为了找出错误.通过分析错误产生的原因和错误的发生趋势,可以帮助项目管理者发现当前软件开发过程中的缺陷,以便及时改进;

(2)这种分析也能帮助测试人员设计出有针对性的测试方法,改善测试的效率和有效性;

(3)没有发现错误的测试也是有价值的,完整的测试是评定软件质量的一种方法。

3.2软件测试的描述

测试是软件开发过程的重要组成部分, 是用来确认一个程序的品质或性能是否符合开发之前所提出的一些要求。软件测试的目的, 第一是确认软件的质量, 其一方面是确认软件做了你所期望的事情(Do the right thing), 另一方面是确认软件以正确的方式来做了

这个事件(Do it right);第二是提供信息, 比如提供给开发人员或程序经理的反馈信息, 为风险评估所准备的信息;第三软件测试不仅是在测试软件产品的本身, 而且还包括软件开发的过程。如果一个软件产品开发完成之后发现了很多问题, 这说明此软件开发过程很可能是有缺陷的。

3.3软件测试的目的

如果测试的目的是为了尽可能多地找出错误,那么测试就应该直接针对软件比较复杂的部分或是以前出错比较多的位置。如果测试目的是为了给最终用户提供具有一定可信度的质量评价,那么测试就应该直接针对在实际应用中会经常用到的商业假设。在谈到软件测试时,引用Grenford J. Myers在《The Art of Software Testing》一书中的观点: (1)软件测试是为了发现错误而执行程序的过程; (2)测试是为了证明程序有错,而不是证明程序无错误; (3)一个好的测试用例是在于它能发现至今未发现的错误; (4)一个成功的测试是发现了至今未发现的错误的测试。这种观点可以提醒人们测试要以查找错误为中心,而不是为了演示软件的正确功能。但是仅凭字面意思理解这一观点可能会产生误导,认为发现错误是软件测试的唯一目,查找不出错误的测试就是没有价值的,事实并非如此。首先,测试并不仅仅是为了要找出错误。通过分析错误产生的原因和错误的分布特征,可以帮助项目管理者发现当前所采用的软件过程的缺陷,以便改进。同时,这种分析也能帮助我们设计出有针对性地检测方法,改

善测试的有效性。其次,没有发现错误的测试也是有价值的,完整的测试是评定测试质量的一种方法。

3.4软件测试的原则

1.应当把"尽早和不断的测试"作为开发者的座右铭。

2.程序员应该避免检查自己的程序, 测试工作应该由独立的专业的软件测试机构来完成。

3.设计测试用例时应该考虑到合法的输入和不合法的输入以及各种边界条件, 特殊情况下要制造极端状态和意外状态, 比如网络异常中断、电源断电等情况。

4.一定要注意测试中的错误集中发生现象, 这和程序员的编程水平和习惯有很大的关系。

5.对测试错误结果一定要有一个确认的过程, 一般有A测试出来的错误, 一定要有一个B来确认, 严重的错误可以召开评审会进行讨论和分析。

6.制定严格的测试计划, 并把测试时间安排的尽量宽松, 不要希望在极短的时间内完成一个高水平的测试。

7.回归测试的关联性一定要引起充分的注意, 修改一个错误而引起更多的错误出现的现象并不少见。

8.妥善保存一切测试过程文档, 意义是不言而喻的, 测试的重现性往往要靠测试文档

4软件测试的内容

4.1验证(verification)

验证(verification)是保证软件正确地实现了一些特定功能的一系列活动, 即保证软件做了你所期望的事情。(Do the right thing)

1.确定软件生存周期中的一个给定阶段的产品是否达到前阶段确立的需求的过程;

2.程序正确性的形式证明, 即采用形式理论证明程序符号设计规约规定的过程;

3.评市、审查、测试、检查、审计等各类活动, 或对某些项处理、服务或文件等是否和规定的需求相一致进行判断和提出报告。

4.2确认(validation)

确认(validation)是一系列的活动和过程, 目的是想证实在一个给定的外部环境中软件的逻辑正确性。即保证软件以正确的方式来做了这个事件(Do it right)

1.静态确认, 不在计算机上实际执行程序, 通过人工或程序分析来证明软件的正确性;

2.动态确认, 通过执行程序做分析, 测试程序的动态行为, 以证实软件是否存在问题。

软件测试的对象不仅仅是程序测试, 软件测试应该包括整个软件开发期问各个阶段所产生的文档, 如需求规格说明、概要设计文

档、详细设计文档, 当然软件测试的主要对象还是源程序。

5软件测试的分类

5.1常用分类

从是否需要执行被测软件的角度, 可分为:

—静态测试和动态测试

从测试是否针对系统的内部结构和具体实现算法的角度来看, 可分为:

-白盒测试和黑盒测试

5.2黑盒测试

黑盒测试

指的是把被测软件看作是一个黑盒子, 我们不去关心盒子里面的结构是什么样子, 只关心软件的输入数据和输出结果。

黑盒测试方法是在程序接口上进行测试, 主要是为了发现以下错误:

?是否有不正确或遗漏了的功能?

?在接口上, 输入能否正确地接受? 能否输出正确的结果?

?是否有数据结构错误或外部信息(例如数据文件)访问错误?

?性能上是否能够满足要求?

?是否有初始化或终止性错误?

用黑盒测试发现程序中的错误, 必须在所有可能的输入条件和输出条件中确定测试数据, 来检查程序是否都能产生正确的输出。但这是不可能的。

n假设一个程序P有输入量X和Y及输出量Z。在字长为32位的计算机上运行。若X、Y取整数, 按黑盒方法进行穷举测试:n可能采用的测试数据组: 232×232 =264 n如果测试一组数据需要1毫秒, 一年工作365× 24小时, 完成所有测试需5亿年。

黑盒测试的测试用例设计

?等价划分法

?边界值法

?错误推测法

?因果图法

5.3白盒测试

白盒测试指的是把盒子盖打开, 去研究里面的源代码和程序结构。

白盒测试也称结构测试或逻辑驱动测试, 它是知道产品内部工作过程, 可通过测试来检测产品内部动作是否按照规格说明书的规定正常进行, 按照程序内部的结构测试程序, 检验程序中的每条通路是否都有能按预定要求正确工作, 而不顾它的功能。使用被测单

元内部如何工作的信息, 允许测试人员对程序内部逻辑结构及有关信息来设计和选择测试用例, 对程序的逻辑路径进行测试。基于一个应用代码的内部逻辑知识, 测试是基于覆盖全部代码、分支、路径、条件。

白盒测试的主要方法:

?逻辑驱动测试

?基本路径测试

主要用于软件验证。

使用程序设计的控制结构导出测试用例。

逻辑驱动测试:

主要是测试覆盖率, 以程序内在逻辑结构为基础的测试。包括以下6种类型:

?语句覆盖

?判断覆盖

?条件覆盖

?判定-条件覆盖

?条件组合覆盖

?路径覆盖

白盒测试的主要目的

?保证一个模块中的所有独立路径至少被执行一次;

?对所有的逻辑值均需要测试真、假两个分支;

?在上下边界及可操作范围内运行所有循环;

?检查内部数据结构以确保其有效性

白盒测试的实施方案

在开发阶段

要保证产品的质量, 产品的生产过程应该遵循一定的行业标准。软件产品也是同样, 没有标准可依自然谈不上质量的好坏。所有关心软件开发质量的组织、单位, 都要定义或了解软件的质量标准、模型。其好处是保证公司实践的均匀性, 产品的可维护性、可靠性以及可移植性等。

在测试阶段

与软件产品的开发过程一样, 测试过程也需要有一定的准则, 来指导、度量、评价软件测试过程的质量。

定义测试准则

为控制测试的有效性以及完成程度, 必须定义准则和策略, 以判断何时结束测试阶段。准则必须是客观的, 可量化的元素, 而不能是经验或感觉。

根据应用的准则和项目相关的约束, 项目领导可以定义使用的度量方法, 和要达到的覆盖率。度量测试的有效性、完整性

对每个测试的测试覆盖信息和累计信息, 用图形方式显示覆盖比率, 并根据测试运行情况实时更新, 随时显示新的测试所反映的测试覆盖情况。

允许所有的测试运行依据其有效性进行管理, 用户可以减少不适用于非回归测试的测试的过程。

概念:

1.语句覆盖:语句覆盖就是设计若干个测试用例, 运行被测试程序, 使得每一条可执行语句至少执行一次;

2.判定覆盖(也称为分支覆盖):设计若干个测试用例, 运行所测程序, 使程序中每个判断的取真分支和取假分支至少执行一次;

3.条件覆盖:设计足够多的测试用例, 运行所测程序, 使程序中每个判断的每个条件的每个可能取值至少执行一次;

4.判定-条件覆盖:设计足够多的测试用例, 运行所测程序, 使程序中每个判断的每个条件的所有可能取值至少执行一次, 并且每个可能的判断结果也至少执行一次, 换句话说, 即是要求各个判断的所有可能的条件取值组合至少执行一次;

5.条件组合测试:设计足够多的测试用例, 运行所测程序, 使程序中每个判断的所有可能的条件取值组合至少执行一次;

6.路径测试:设计足够多的测试用例, 运行所测程序, 要覆盖程序中所有可能的路径。

5.4静态测试

是指不实际运行被测软件, 而只是静态的检查程序代码、界面或文档中可能存在的错误的过程。

其中包括代码测试、界面测试和文档测试3个方面。对于代码测试, 主要测试代码是否符合相应的标准和规范。对于界面测试, 主要

测试软件的实际界面与需求中的说明是否相符。对于文档测试, 主要测试用户手册和需求说明是否符合用户的实际要求。

5.5动态测试

是指实际运行被测程序, 输入相应的测试数据, 检查实际输出结果和预期结果是否相符的过程。所以, 我们判断一个测试属于动态还是静态测试 , 唯一的标准就是看是否运行程序。

6软件测试中的类测试

6.1面向对象软件从宏观上来看是各个类之间的相互作用。在面向对象系统中,系统的基本构造模块是封装了的数据和方法的类和对象,而不再是一个个能完成特定功能的功能模块。每个对象有自己的生存周期,有自己的状态。消息是对象之间相互请求或协作的途径,是外界使用对象方法及获取对象状态的唯一方式。对象的功能是在消息的触发下,由对象所属类中定义的方法与相关对象的合作共同完成,且在不同状态下对消息的响应可能完全不同。对象中的数据和方法是一个有机的整体,测试过程中不能仅仅检查输入数据产生的输出结果是否与预期的吻合,还要考虑对象的状态。模块测试的概念已不适用于对象的测试“类测试将是整个测试过程的一个重要步骤。

6.2类测试技术

6.2.1基于服务的类测试技术

基于服务的类测试主要考察封装在类中的一个方法对数据进行的操作,它可以采用传统的白盒测试方法。为克服软件测试的盲目性和局限性,保证测试的质量,提高软件的可靠性,下面我们介绍一种类的服务的测试模型及相应的测试策略。

BBD通常有两种获取途径。一是采用逆向工程的方法根据源程序画出流程图,然后构造出BBD。但这毕竟是在缺少软件开发前期的分析、设计文档或文档不齐全的情况下退而求其次的办法。当源程序不正确时构造出来的BBD就是错误的。另一种途径就是追根溯源,在软件的分析、设计阶段就根据测试的需要构造出相应的BBD。这样就能从根本上解决问题,正确地指导类的服务的测试。

6.2.2基于层次增量的类测试

层次增量测试的基本思想是:首先分别测试父类的各个成员函数,再测试成员函数间的相互作用,把测试用例和执行信息保存在/测试历史中,在测试子类时,根据父类的测试历史修改部分的定义以及实现语言的继承映射来决定子类中的哪些特征应当重测试以及父类的哪些测试用例可以复用。

这种根据类间继承关系的层次特性对类进行增量测试的技术是由M. Harrold等人提出的,其特点是复用父类的测试信息来指导子类的测试。

7参考文献

参考书籍:

1、Ron Patton 《软件测试》机械工业出版社

2、张克东等《软件工程与软件测试自动化教程》电子工业出版社

3、Dustin,E.《软件自动化测试:引入、管理与实施》电子工业出版社

4、James A. Whittaker 《实用软件测试指南》电子工业出版社

5、Zadrozny 《J2EE性能测试》电子工业出版社

6、Jones,C.《软件评估、基准测试与最佳实践》机械工业出版社

7、Edward Kit 《软件测试过程改进》机械工业出版社

8、Hung Q.Nguyen 《Web应用测试》电子工业出版社

9、Robert V.Binder《面向对象系统测试模型视图与工具(影印版)》

10、Rakitin,S.K.《软件验证与确认的最佳管理办法》电子工业出版社

11、麦格雷戈《面向对象的软件测试》机械工业出版社

8致谢

非常感谢陈林华老师在我大学的最后学习阶段——毕业设计阶段给自己的指导,从最初的定题,到资料收集,到写作、修改,到论文定稿,她们给了我耐心的指导和无私的帮助。为了指导我们的毕业论文,她们放弃了自己的休息时间,她们的这种无私奉献的敬业精神令人钦佩,在此我向她们表示我诚挚的谢意。同时,感谢所有任课老师和所有同学在这四年来给自己的指导和帮助,是他们教会了我专业知识,教会了我如何学习,教会了我如何做人。正是由于他们,我才能在各方面取得显著的进步,在此向他们表示我由衷的谢意,并祝所有的老师培养出越来越多的优秀人才,桃李满天下!

通过这一阶段的努力,我的毕业论文《软件测试的概述及方法》终于完成了,这意味着大学生活即将结束。在大学阶段,我在学习上和思想上都受益非浅,这除了自身的努力外,与各位老师、同学和朋友的关心、支持和鼓励是分不开的。

写作毕业论文是一次再系统学习的过程,毕业论文的完成,同样也意味着新的学习生活的开始。

感谢各位专家的批评指导。