计算机毕业论文

软件测试的概述及方法Meteor指导教师姓名 职称 专 业 名 称 计 算 机 网 络 专 业 论文提交日期 论文答辩日期 2012年 4月 30 日软件测试的概述及方法MeteorXX大学,重庆 400715摘要：从软件产业的发展初期到目前的大型软件开发过程，软件测试已成为其中一个不可分割的部分。随着软件规模的日益增大，软件测试问题也日益突出，现代社会对软件的依赖越来越强,高可信软件测试有着广泛的需求，基于缺陷模式的软件测试技术作为高可信软件的重要保证,可以大大降低软件的缺陷密度,提高软件的可信性。本文从测试的基本概念入手,深入剖析软件测试相关理论。关键字：软件测试、白盒测试、黑盒测试、类测试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、迪士尼的狮子王 （19941995）软件在少数系统中能正常工作, 但在大众使用的常见系统中不行。后来证实,迪士尼公司没有对市场上投入实用的各种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可能采用的 测试数据组： 232232 264 n如果测试一组数据需要1毫秒, 一年工作365 24小时, 完成所有测试需5亿年。5.2.1 黑盒测试的测试用例设计如手机的开机测试案例下表所示开机（Power UP）测试项目测试ID操作描述预期结果实际结果(OK/NG/NA)备注1 LED灯PU-1-1关机状态下长按挂机键LED灯闪烁，颜色变换符合设计2 开机动画PU-2-1关机状态下长按挂机键开机动画演示正常3 开机音乐PU-3-1关机状态下长按挂机键开机音乐播放正常4 开机欢迎界面PU-4-1关机状态下长按挂机键开机欢迎辞显示正常5 SIM卡检查5.1 SIM卡损坏或没有SIM卡插入PU-5.1-1关机状态下长按挂机键开机动画、开机音乐之后，显示并停留在“请插入SIM卡”版面PU-5.1-2关机状态下长按挂机键,在“请插入SIM卡”版面,按SOS软键进入“紧急呼叫”5.2 启动了PIN检验PU-5.2-1关机状态下长按挂机键开机动画、开机音乐后出现“请输入PIN码”版面PU-5.2-2“请输入PIN码”版面，直接按确定软键提示“最小长度是4”，并返回“请输入PIN码”版面PU-5.2-3“请输入PIN码”版面，按数字键可以进行输入，并显示*PU-5.2-4“请输入PIN码”版面，输入13位数字，按确定软键提示“最小长度是4”，并返回“请输入PIN码”版面PU-5.2-5“请输入PIN码”版面,输入8位数字后继续输入提示“最大长度是8”，并返回“请输入PIN码”版面PU-5.2-6“请输入PIN码”版面，输入48个数字的错误PIN码，按确定提示“错误PIN码”，然后返回“请输入PIN码”画面PU-5.2-7“请输入PIN码”版面，输入正确PIN码，按确定继续开机流程5.3 SIM卡PIN1被锁PU-5.3-1关机状态下长按挂机键开机动画、开机音乐之后，提示“PIN1被锁住”并最终显示在“请输入PUK”版面PU-5.3-2在“请输入PUK”版面，直接按确定软键提示“最小长度是4”，并返回“请输入PUK码”版面PU-5.3-3在“请输入PUK”版面，按数字键可以进行输入，并显示*PU-5.3-4在“请输入PUK”版面，输入17位数字，按确定软键提示“最小长度是8”，并返回“请输入PUK码”版面PU-5.3-5在“请输入PUK”版面，输入8位数字的错误PUK码，按确定软键要求输入两次新PIN码后，提示“PIN1被锁住”，并返回“请输入PUK码”版面PU-5.3-6在“请输入PUK”版面，输入8位数字，继续输入提示“最大长度是8”，并返回“请输入PUK码”版面PU-5.3-7在“请输入PUK”版面，输入8位数字的正确PUK码，按确定软键要求输入两次新PIN码，并成功解锁，继续开机流程6 手机密码检查PU-6-1关机状态下长按挂机键开机动画、开机音乐、PIN检验之后，出现“输入手机密码”版面PU-6-2“输入手机密码”版面，直接按确定软键提示“最小长度是4”，并返回“输入手机密码”版面PU-6-3“输入手机密码”版面，按数字键可以进行输入，并显示*PU-6-4在“输入手机密码”版面，输入13位数字，按确定软键提示“最小长度是4”，并返回“输入手机密码”版面PU-6-5在“输入手机密码”版面，输入4位错误手机密码，按确定软键提示“手机密码错误”，并返回“输入手机密码”版面PU-6-6在“输入手机密码”版面，输入8位数字，继续输入输入无效PU-6-7在“输入手机密码”版面，输入4位正确手机密码，按确定软键手机解锁，继续开机流程7 搜网PU-7-1关机状态下长按挂机键开机动画、音乐完毕；PIN检验、手机密码检验完毕，出现搜网画面“正在搜网”，直到找到网络注：其它语言下以上各功能运行正常测试说明：在测试中，必须对每个界面都要进行触屏的操作，因此测试次数为2次，即使用按键操作1次，使用触屏操作1次，检查功能是否正常.(如有侧翻，合盖操作界面也做以上相应操作）5.2.2 等价划分法等价类划分是一种典型的黑盒测试方法，用这一方法设计测试用例完全不考虑程序的内部结构，只根据对程序的要求和说明，即需求规格说明书。我们必须仔细分析和推敲说明书的各项需求，特别是功能需求。把说明书中对输入的要求和输出的要求区别开来并加以分解。由于穷举测试工作量太大，以至于无法实际完成，促使我们在大量的可能数据中选取其中的一部分作为测试用例。例如，在不了解等价分配计数的前提下，我们做计算器程序的加法测试时，测试了1+1，1+2，1+3和1+4之后，还有必要测试1+5和1+6吗，能否放心地认为它们是正确的？我们感觉1+5和1+6，与前面的1+1，1+2都是很类似的简单加法。等价类划分的方法是把程序的输入域划分成若干部分，然后从每个部分中选取少数代表性数据作为测试用例。每一类的代表性数据在测试中的作用等价于这一类中的其他值，也就是说，如果某一类中的一个例子发现了错误，这一等价类中的其他例子也能发现同样的错误；反之，如果某一类中的一个例子没有发现错误，则这一类中的其他例子也不会查出错误(除非等价类中的某些例子属于另一等价类，因为几个等价类是可能相交的)。使用这一方法设计测试用例，首先必须在分析需求规格说明的基础上划分等价类，列出等价类表。5.2.2.1 划分等价类和列出等价类表等价类是指某个输入域的子集合。在该子集合中，各个输入数据对于发现程序中的错误都是等效的。并合理地假定：测试某个等价类的代表值就等于对这一类其他值的测试。因此，可以把全部输入数据合理地划分为若干等价类，在每一个等价类中取一个数据作为测试输入条件，就可以用少量代表性的测试数据取得较好的测试结果。等价类划分有两种不同的情况：有效等价类和无效等价类。有效等价类：指对于程序的规格说明来说是合理的、有意义的输入数据构成的集合。利用有效等价类可以检验程序是否实现了规格说明中所规定的功能和性能。无效等价类：与有效等价类的定义相反。设计测试用例时，要同时考虑这两种等价类。因为软件不仅要能接收合理的数据，也要能经受意外的考验。这样的测试才能确保软件具有更好的可靠性。下面给出6条确定等价类的原则：在输入条件规定了取值范围或值的个数的情况下，可以确立一个有效等价类和两个无效等价类。在输入条件规定了输入值的集合或者规定了“必须如何”的条件的情况下，可以确立一个有效等价类和一个无效等价类。在输入条件是一个布尔量的情况下，可确定一个有效等价类和一个无效等价类。在规定了输入数据的一组值(假定n个)，并且程序要对每一个输入值分别处理的情况下，可确立n个有效等价类和一个无效等价类。在规定了输入数据必须遵守的规则的情况下，可确立一个有效等价类(符合规则)和若干个无效等价类(从不同角度违反规则)。在确知已划分的等价类中，各元素在程序处理中的方式不同的情况下，则应再将该等价类进一步划分为更小的等价类。在确立了等价类之后，建立等价类表，列出所有划分出的等价类。5.2.2.2 确定测试用例根据已列出的等价类表，按以下步骤确定测试用例：为每个等价类规定一个唯一的编号。设计一个新的测试用例，使其尽可能多地覆盖尚未覆盖的有效等价类。重复这一步，最后使得所有有效等价类均被测试用例所覆盖。设计一个新的测试用例，使其只覆盖一个无效等价类。重复这一步使所有无效等价类均被覆盖。在寻找等价区间时，设法把软件的相似输入、输出、操作分成组，这些组就是等价区间。等价类的重要问题是它们构成的集合的划分，其中，划分是指互不相交的一组子集，这些子集的并是整个集合。这对于测试有两点非常重要的意义：表示整个集合这个事实提供了一种形式的完备性，而互不相交可保证一种形式的无冗余性。由于子集是由等价关系决定的，因此子集的元素都有一些共同点。等价类测试的思想是通过每个等价类中的一个元素标识测试用例。如果广泛选择等价类，则这样可以大大减低测试用例之间的冗余。为了便于理解，以下讨论涉及有两个变量X1和X2的函数F。如果函数F实现为一个程序，则输入变量X1和X2将拥有以下边界，以及边界内的区间：aX1d，区间为a，b)，b，c)，c，d eX2g，区间为e，f)，f，g其中方括号和圆括号分别表示闭区间和开区间的端点。X1，X2的无效值是X1d，X2g。以此作为例子，我们将进一步讨论等价类划分法。5.2.2.3 弱一般等价类测试采用上面给出的标记，弱一般等价类测试通过一个测试用例中的每个等价类(区间)的一个变量实现(请注意单边假设作用)。对于前面给出的例子，可得到如下图所示的弱等价类测试用例。由函数的定义可知，带阴影的矩形中的任何点都是函数F的有效输入。这三个测试用例使用每个等价类中的一个值。我们以对称方式标识这些测试用例，于是得到外在的模式。事实上，永远都有等量的弱等价类测试用例，因为划分中的类对应最大子集数。5.2.2.4 强一般等价类测试强一般等价类测试基于多缺陷假设，因此需要等价类笛卡尔积的每个元素对应的测试用例，如下图所示：请注意，这些测试用例的模式与命题逻辑中的真值表构造具有相似性。笛卡尔积可以保证两种意义上的“完备性”：一是覆盖所有的等价类，二是有可能的输入组合中的一个。事实上，“好的”等价类测试的关键是等价关系的选择。注意被“相同处理”的输入。在大多数情况下，等价类测试定义输入定义域的类。没有理由不能根据被测程序函数的输出值域定义等价关系，我们可以看到，这对于三角形问题是最简单的方法。5.2.2.5 弱健壮等价类测试这种测试的名称显然与直觉矛盾，且自相矛盾。怎么能够既弱又健壮呢？说它健壮，是因为这种测试考虑了无效值；说它弱，是因为有单缺陷假设。1、对于有效输入，使用每个有效类的一个值。(就像我们在所谓弱一般等价类测试中所做的一样。请注意，这些测试用例中的所有输入都是有效的。)2、对于无效输入，测试用例将拥有一个无效值，并保持其余的值都是等效的。(因此，“单缺陷”会造成测试用例失败。)按照这种策略产生的测试用例如下图所示：健壮等价类测试有两个问题。第一个问题是，规格说明常常并没有定义无效测试用例所预期的输出是什么。(我们可以把这看作是规格说明的不足，但是这并不能解决问题。)因此，测试人员需要花费大量时间定义这些测试用例的输出。第二个问题是，强类型语言没有必要考虑无效输入。传统等价类测试是诸如FORTRAN和COBOL这样的语言占统治地位的年代的产物，因此那时这种错误很常见。事实上，正是由于经常出现这种错误，才促使人们实现强类型语言。对于第二个问题，应该是指对于纯编程语言而言的。在实际的项目中，由于人的因素(人总会犯错误，即使编程语言本身再怎么完美，诸如Java、Python、C+这样的强类型语言，也无法避免)，以及业务的具体要求，无效输入往往要考虑业务因素，所以任何时刻都必须考虑无效输入。5.2.2.6 强健壮等价类测试至少这种测试的名称既不与直觉矛盾，也不自相矛盾，只是有些冗余。像以前的定义一样，健壮是指要考虑无效值，强是指多缺陷假设。我们从所有的等价类笛卡尔积的每个元素中获得测试用例，如下图所示：下面我们将结合三角形问题，来实际应用等价类划分的方法。三角形问题是这样的经典，以至于虽然大家都知道它是经典问题，面试和笔试中还是会遇到。例题：根据下面给出的规格说明，利用等价类划分的方法，给出足够的测试用例。“一个程序读入3个整数，把这3个数值看作一个三角形的3条边的长度值。这个程序要打印信息，说明这个三角形是不等边的、是等腰的、是等边的，或者不能构成三角形”。在描述问题时，我们提到有四种可能出现的输出：非三角形、不等边三角形、等腰三角形和等边三角形。可以使用这些输出标识如下所示的输出(值域)等价类：R1=：有三条边a、b和c的等边三角形R2=：有三条边a、b和c的等腰三角形R3=：有三条边a、b和c的不等边三角形R4=：三条边a、b和c的不构成三角形四个弱一般等价类测试用例是：弱一般等价类测试用例测试用例abc预期输出WN1555等边三角形WN2223等腰三角形WN3345不等边三角形WN4412非三角形由于a、b和c没有有效区间，则强一般等价类测试用例与弱一般等价类测试用例相同。考虑a、b和c的无效值产生的以下额外弱健壮等价类测试用例：额外弱健壮等价类测试用例测试用例abc预期输出WR1-155a取值不在所允许的取值值域内WR25-15b取值不在所允许的取值值域内WR355-1c取值不在所允许的取值值域内WR420155a取值不在所允许的取值值域内WR552015b取值不在所允许的取值值域内WR655201c取值不在所允许的取值值域内以下是额外强健壮等价类测试用例三维立方的一个“角”：额外强健壮等价类测试用例测试用例abc预期输出SR1-155a取值不在所允许的取值值域内SR25-15b取值不在所允许的取值值域内SR355-1c取值不在所允许的取值值域内SR4-1-15a、b取值不在所允许的取值值域内SR55-1-1b、c取值不在所允许的取值值域内SR6-15-1a、c取值不在所允许的取值值域内SR7-1-1-1a、b、c取值不在所允许的取值值域内请注意，预期输出如何完备地描述无效输入值。等价类测试显然对用来定义类的等价关系很敏感。如果在输入定义域上定义等价类，则可以得到更丰富的测试用例集合。三个整数a、b和c有些什么可能的取值呢？这些整数可以相等，有一对整数相等(有三种相等方式)，或都不相等。D1=：a=b=c，D2=：a=b，ac，D3=：a=c，abD4=：b=c，ab，D5=：ab，ac，bc作为一个单独的问题，我们可以通过三角形的性质来判断三条边是否构成一个三角形。(例如，三元组有一对相等的边，但是这些边不构成一个三角形。)D6=：ab+c，D7=：ba+c，D8=：ca+b如果我们要彻底一些，可以将“大于或等于”分解为两种不同的情况，这样D6就变成D6=：a=b+c，D6=：ab+c，同样对于D7和D8也有类似的情况。列出等价类表，如下所示：等价类表输入条件有效等价类无效等价类是否三角形的3边（A0） (1)(A0) （7）(B0) (2)(B0) (8)(C0) (3)(C0) (9)(A+BC) (4)(A+BC) (10)(B+CA) (5)(B+CA) (11)(A+CB) (6)(A+CB) (12)是否等腰三角形（A=B） (13)（AB）and(BC)and (AC) （16）(B=C) (14)(A=C) (15)是否等边三角形（A=B）and(B=C)and (A=C) （17）（AB） (18)(BC) (19)(AC) (20)设计测试用例：输入顺序是A，B，C，如下表所示：设计测试用例表序号A，B，C覆盖等价类输出13,4,5(1),(2),(3),(4),(5),(6)不能构成三角形20,1,2(7)31,0,2(8)41,2,0(9)51,2,3(10)61,3,2(11)73,1,2(12)83,3,4(1),(2),(3),(4),(5),(6),(13)等腰三角形93,4,4(1),(2),(3),(4),(5),(6),(14)103,4,3(1),(2),(3),(4),(5),(6),(15)113,4,5(1),(2),(3),(4),(5),(6),(16)非等腰三角形123,3,3(1),(2),(3),(4),(5),(6),(17)等边三角形133,4,4(1),(2),(3),(4),(5),(6),(14),(18)非等边三角形143,4,3(1),(2),(3),(4),(5),(6),(15),(19)153,3,4(1),(2),(3),(4),(5),(6),(13),(20)等价分配的目标是把可能的测试用例组合缩减到仍然足以满足软件测试需求为止。因为，了选择不完全测试，就要冒一定的风险，所以必须仔细选择分类。5.3 白盒测试白盒测试指的是把盒子盖打开, 去研究里面的源代码和程序结构。白盒测试也称结构测试或逻辑驱动测试, 它是知道产品内部工作过程, 可通过测试来检测产品内部动作是否按照规格说明书的规定正常进行, 按照程序内部的结构测试程序, 检验程序中的每条通路是否都有能按预定要求正确工作, 而不顾它的功能。 使用被测单元内部如何工作的信息, 允许测试人员对程序内部逻辑结构及有关信息来设计和选择测试用例, 对程序的逻辑路径进行测试。基于一个应用代码的内部逻辑知识, 测试是基于覆盖全部代码、分支、路径、条件。 白盒测试的主要方法： 逻辑驱动测试 基本路径测试 主要用于软件验证。 使用程序设计的控制结构导出测试用例。 逻辑驱动测试：主要是测试覆盖率, 以程序内在逻辑结构为基础的测试。包括以下6种类型： 语句覆盖 判断覆盖 条件覆盖 判定-条件覆盖 条件组合覆盖 路径覆盖 白盒测试的主要目的 保证一个模块中的所有独立路径至少被执行一次； 对所有的逻辑值均需要测试真、假两个分支； 在上下边界及可操作范围内运行所有循环；检查内部数据结构以确保其有效性 白盒测试的实施方案 在开发阶段要保证产品的质量, 产品的生产过程应该遵循一定的行业标准。软件产品也是同样, 没有标准可依自然谈不上质量的好坏。所有关心软件开发质量的组织、单位, 都要定义或了解软件的质量标准、模型。其好处是保证公司实践的均匀性, 产品的可维护性、可靠性以及可移植性等。 在测试阶段与软件产品的开发过程一样, 测试过程也需要有一定的准则, 来指导、度量、评价软件测试过程的质量。定义测试准则为控制测试的有效性以及完成程度, 必须定义准则和策略, 以判断何时结束测试阶段。准则必须是客观的, 可量化的元素, 而不能是经验或感觉。 根据应用的准则和项目相关的约束, 项目领导可以定义使用的度量方法和需要达到的覆盖率, 度量测试的有效性、完整性对每个测试的测试覆盖信息和累计信息, 用图形方式显示覆盖比率, 并根据测试运行情况实时更新, 随时显示新的测试所反映的测试覆盖情况。允许所有的测试运行依据其有效性进行管理, 用户可以减少不适用于非回归测试的测试的过程。 概念：1.语句覆盖：语句覆盖就是设计若干个测试用例, 运行被测试程序, 使得每一条可执行语句至少执行一次； 2.判定覆盖（也称为分支覆盖）：设计若干个测试用例, 运行所测程序, 使程序中每个判断的取真分支和取假分支至少执行一次；3.条件覆盖：设计足够多的测试用例, 运行所测程序, 使程序中每个判断的每个条件的每个可能取值至少执行一次； 4.判定-条件覆盖：设计足够多的测试用例, 运行所测程序, 使程序中每个判断的每个条件的所有可能取值至少执行一次, 并且每个可能的判断结果也至少执行一次, 换句话说, 即是要求各个判断的所有可能的条件取值组合至少执行一次； 5.条件组合测试：设计足够多的测试用例, 运行所测程序, 使程序中每个判断的所有可能的条件取值组合至少执行一次； 6.路径测试：设计足够多的测试用例, 运行所测程序, 要覆盖程序中所有可能的路径。5.4 静态测试是指不实际运行被测软件, 而只是静态的检查程序代码、界面或文档中可能存在的错误的过程。其中包括代码测试、界面测试和文档测试3个方面。对于代码测试, 主要测试代码是否符合相应的标准和规范。对于界面测试, 主要测试软件的实际界面与需求中的说明是否相符。对于文档测试, 主要测试用户手册和需求说明是否符合用户的实际要求。5.5 动态测试是指实际运行被测程序, 输入相应的测试数据, 检查实际输出结果和预期结果是否相符的过程。所以, 我们判断一个测试属于动态还是静态测试 , 唯一的标准就是看是否运行程序。6 软件测试中的类测试面向对象软件从宏观上来看是各个类之间的相互作用。在面向对象系统中,系统的基本构造模块是封装了的数据和方法的类和对象,而不再是一个个能完成特定功能的功能模块。每个对象有自己的生存周期,有自己的状态。消息是对象之间相互请求或协作的途径,是外界使用对象方法及获取对象状态的唯一方式。对象的功能是在消息的触发下,由对象所属类中定义的方法与相关对象的合作共同完成,且在不同状态下对消息的响应可能完全不同。对象中的数据和方法是一个有机的整体,测试过程中不能仅仅检查输入数据产生的输出结果是否与预期的吻合,还要考虑对象的状态。模块测试的概念已不适用于对象的测试“类测试将是整个测试过程的一个重要步骤。6.1 类测试技术6.2.1 基于服务的类测试技术基于服务的类测试主要考察封装在类中的一个方法对数据进行的操作，它可以采用传统的白盒测试方法。为克服软件测试的盲目性和局限性,保证测试的质量,提高软件的可靠性,下面我们是一种类测试模型及相应的测试策略。BBD通常有两种获取途径。一是采用逆向工程的方法根据源程序画出流程图,然后构造出BBD。但这毕竟是在缺少软件开发前期的分析、设计文档或文档不齐全的情况下退而求其次的办法。当源程序不正确时构造出来的BBD就是错误的。另一种途径就是追根溯源,在软件的分析、设计阶段就根据测试的需要构造出相应的BBD。这样就能从根本上解决问题,正确地指导类的服务的测试。6.2.2 基于层次增量的类测试 层次增量测试的基本思想是:首先分别测试父类的各个成员函数,再测试成员函数间的相互作用,把测试用例和执行信息保存在/测试历史中,在测试子类时,根据父类的测试历史修改部分的定义以及实现语言的继承映射来决定子类中的哪些特征应当重测试以及父类的哪些测试用例可以复用。这种根据类间继承关系的层次特性对类进行增量测试的技术是由M. Harrold等人提出的,其特点是复用父类的测试信息来指导子类的测试。参考文献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 麦格雷戈.面向对象的软件测试机械工业出版社 24致谢非常感谢老师在我大学的最后学习阶段毕业设计阶段给自己的指导，从最初的定题，到资料收集，到写作、修改，到论文定稿，你们给了我耐心的指导和无私的帮助。为了指导我们的毕业论文，放弃了自己的休息时间，这种无私奉献的敬业精神令人钦佩，在此我向你们表示我诚挚的谢意。同时，感谢所有任课老师和所有同学在这几年来给自己的指导和帮助，是他们教会了我专业知识，教会了我如何学习，教会了我如何做人。正是由于他们，我才能在各方面取得显著的进步，在此向他们表示我由衷的谢意，并祝所有的老师培养出越来越多的优秀人才，桃李满天下！通过这一阶段的努力，我的毕业论文软件测试的概述及方法终于完成了，这意味着大学生活即将结束。在大学阶段，我在学习上和思想上都受益非浅，这除了自身的努力外，与各位老师、同学和朋友的关心、支持和鼓励是分不开的。写作毕业论文是一次再系统学习的过程，毕业论文的完成，同样也意味着新的学习生活的开始。感谢各位专家的批评指导。