软件测试方法技术的研究毕业论文Word下载.docx
《软件测试方法技术的研究毕业论文Word下载.docx》由会员分享，可在线阅读，更多相关《软件测试方法技术的研究毕业论文Word下载.docx（47页珍藏版）》请在冰豆网上搜索。
正确选择和有效地运用各种测试方法、技术和工具，对提高软件工程的应用水平和提高软件产品的质量与可靠性至关重要。
而在软件测试中使用优秀的测试管理工具不但可以大大减少测试过程中出现错误的可能性，还可以极大的提高测试的效率，加快测试进程。
1.2论文的主要研究工作及成果
论文主要对软件测试、测试技术（工具、方法）、自动化测试以及测试管理技术（工具、方法）进行理论阐述和综合论述；
然后进行综合分析、比较、总结。
通过查阅文献资料和对主流工具软件和相关技术的深入学习可完成软件测试技术方法的比较与分析研究内容。
在这个论文研究过程中，可以学会正确选择和有效地运用各种测试方法、技术和工具。
1.3论文的组织结构
论文的组织结构如图1.1所示：
图1.1论文的组织结构
2.软件测试技术的概论
2.1软件测试的定义与目的
软件测试就是使用人工或者自动的手段来运行或测定某个软件产品系统的过程，其目的是在于检验软件产品是否满足规定的需求[2]。
简单地说，软件测试过程就是制造条件，促使错误发生的过程。
软件测试的目的是[3]：
（1）测试的最终目的是为了避免错误的发生，确保应用程序能够正常高效的运行；
（2）好的测试用例在于发现至今未发现的错误；
（3）成功的测试是发现了至今未发现的错误的测试；
（4）好的测试工程师应该做到不仅发现问题，还能够帮助开发人员分析问题。
2.2软件测试的过程
软件测试是一个贯穿整个软件生命周期的活动，那种等待整个系统开发完毕，再对其进行测试的想法是错误的，把测试放到软件开发的最后是很危险的，因为它很容易导致整个软件系统无法集成。
另外，对软件的测试并不仅限于软件程序的本身，因为错误并不一定是代码引起的。
很有可能是软件需求、软件系统的详细设计等阶段引起的。
错误在初期也许只是范围很小的隐藏问题，但由于软件开发的各阶段的连续性，会使错误逐步扩展，如果早期的开发中出现的错误不能排除，将带到设计、编码、测试等各阶段，影响逐步扩大。
所以对软件的测试还应该包括与软件有关的所有的文档。
一个典型的软件测试过程如下图：
图2.1典型的软件测试过程
一个软件的测试过程是一个不断回归的过程。
旧的错误的修改可能会引起新的错误的出现，所以每修改一个新的错误，都要针对系统再作一次测试，直到没有新的错误出现为止，这是一个很繁琐的过程。
2.3软件测试的分类及主要方法
针对不同规模、不同类型的软件，以及软件开发的不同阶段，所用的测试方法各异，下面我们就主要针对上面的几种情况对软件测试做一个简单的分类。
2.3.1按测试过程划分
我们知道对于软件开发商来说，比较大的软件系统都是由许多人协作开发的，一般都是把一个大的软件系统分割成不同的功能模块，然后再将这些模块分给开发团中的每个人去完成，在开发的过程中针对每个模块的完成情况，边开发、边测试、边集成，然后各个模块集成的完整的系统还要进行测试，当系统交付用户使用后，还要对系统进行维护、升级，这里面也伴随着测试。
根据上面的过程，我们按软件开发过程的可以将软件测试划分为下面五个步骤，它们的关系如图2.2：
图2.2软件测试步骤
单元测试是对软件中的基本组成单位进行的测试，如一个模块、一个过程等等。
它是软件动态测试的最基本的部分，也是最重要的部分之一，其目的是检验软件基本组成单位的正确性。
一个软件单元的正确性是相对于该单元的规约而言的。
因此，单元测试以被测试单位的规约为基准。
单元测试的主要方法有控制流测试、数据流测试、排错测试、分域测试等等[3-5]。
集成测试是在软件系统集成过程中所进行的测试，其主要目的是检查软件单位之间的接口是否正确。
它根据集成测试计划，一边将模块或其他软件单位组合成越来越大的系统，一边运行该系统，以分析所组成的系统是否正确，各组成部分是否合拍。
集成测试的策略主要有自顶向下和自底向上两种[3-5]。
系统测试是对已经集成好的软件系统进行彻底的测试，以验证软件系统的正确性和性能等满足其规约所指定的要求，检查软件的行为和输出是否正确并非一项简单的任务，它被称为测试的“先知者问题”。
因此，系统测试应该按照测试计划进行，其输入、输出和其他动态运行行为应该与软件规约进行对比。
软件系统测试方法很多，主要有功能测试、性能测试、随机测试等等[3-5]。
验收测试旨在向软件的购买者展示该软件系统满足其用户的需求。
它的测试数据通常是系统测试的测试数据的子集。
所不同的是，验收测试常常有软件系统的购买者代表在现场，甚至是在软件安装使用的现场。
这是软件在投入使用之前的最后测试。
回归测试是在软件维护阶段对软件进行修改之后进行的测试。
其目的是检验对软件进行的修改是否正确。
这里修改的正确性有两重含义：
一是所作的修改达到了预定目的，如错误得到改正，能够适应新的运行环境等等；
二是不影响软件的其他功能的正确性[1]。
2.3.2按工作状态划分
软件测试是一个对测试经验、测试计划、测试环境和测试工具依赖性非常强的工作，按工作状态分为静态测试和动态测试两个阶段[6]。
静态测试主要是针对所有文档资料、编程规范、数据定义、控制和数据使用、代码与需求的一致性、代码与设计的一致性等方面的分析，其对测试经验和测试计划的依赖性极强。
静态测试是在不需运行软件系统的情况下，对系统进行的测试。
其采用的方法主要有[6]：
（1）文档资料浏览，达到正确的理解，并对任何改变具有统一的认知；
（2）讨论决定，对文档资料进行讨论，并作出决定，如：
做什么、不做什么、如何做等；
（3）检查，根据规范和定义，找出可能存在的问题，如：
市场和商业策略、系统需求和系统设计、程序代码、测试计划、测试设计、测试案例、测试结果、用户手册、培训教材等；
（4）利用工具对程序代码进行静态分析，如：
程序复杂度、系统结构、控制流程、数据流程等。
动态测试是被测系统在运行当中，根据其动态的行为进行的测试。
根据测试规模，可分为：
单元测试、集成测试、系统测试及应用测试等几个阶段。
2.3.3按测试用例设计方法划分
软件测试的方法和技术是多种多样的，按测试用例设计方法，可分为黑盒测试和白盒测试，并且黑盒测试和白盒测试还是目前通用的测试技术[2，7-8]。
黑盒测试着眼于程序外部结构、不考虑内部逻辑结构、针对软件界面和软件功能进行的测试。
黑盒测试也称功能测试、数据驱动测试或基于规格说明的测试，它在已知产品应具有的功能的条件下，通过测试来检测每个功能是否都能正常使用。
在测试时，把程序看作一个不能打开的黑盒子，在完全不考虑程序内部结构和内部特性的情况下，测试者在程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数据而产生正确的输出信息，并且保持外部信息（如数据库或文件）的完整性。
黑盒测试是以用户的观点，从输入数据与输出数据的对应关系出发进行测试的，它不涉及到程序的内部结构。
黑盒测试注重于测试软件的功能需求，主要试图发现软件中的功能错误、界面错误、数据结构或外部数据库访问错误、性能错误、初始化和终止错误等。
白盒测试是基于代码的测试，测试人员通过阅读程序代码或者通过使用开发工具中的单步调试来判断软件的质量。
白盒测试也称结构测试、逻辑驱动测试或基于程序本身的测试，它是知道产品内部工作过程，可通过测试来检测产品内部动作是否按照规格说明书的规定正常进行，按照程序内部的结构测试程序，检验程序中的每条通路是否都有能按预定要求正确工作，而不涉及它的功能，白盒测试的主要方法有逻辑驱动、基路测试等，主要用于软件验证。
白盒测试需要全面了解程序内部逻辑结构、对所有逻辑路径进行测试。
白盒测试是穷举路径测试，在使用这一方案时，测试者必须检查程序的内部结构，从检查程序的逻辑着手，得出测试数据。
黑盒测试与白盒测试的比较如下表2.1。
表2.1黑盒测试与白盒测试的比较
黑盒测试
白盒测试
测试
依据
用户能看到的规格说明，针对功能进行测试
程序的内部结构
优点
能站在用户立场上进行测试
能够对程序内部的特定部位进行覆盖测试
缺点
不能测试程序内部特定部位。
如果规格说明有误，则无法发现
无法检验程序的外特性，无法对未实现规格说明的程序内部欠缺部分进行测试
来源
基于程序所有功能得到说明的基础之上
基于所有的需求得到实现的基础之上
举例
等价类划分
边值分析
因果图
语句覆盖，分支覆盖
条件覆盖，判定/条件覆盖，
路径覆盖
2.3.4按测试目的划分
对于一个软件系统，衡量它的好坏有两个最重要的指标，一是它的功能是否符合要求，二是它的性能是否符合要求。
那么针对这两个指标，我们可以将软件测试分为：
功能测试和性能测试两个部分[2]。
功能测试：
针对软件的功能测试，目的是为了验证软件的功能是否符合软件需求规格说明的要求，找出软件不符合用户需求的地方。
功能测试要尽量测试到软件的每一个功能单元，找出软件中的缺陷，确保软件的每一个部分都能正常、正确的工作。
性能测试：
就是用来测试软件在系统中的运行性能的。
性能测试可以发生在各个测试阶段中，即使是在单元层，一个单独模块的性能也可以使用白盒测试来进行评估，然而，只有当整个系统的所有成分都集成到一起之后，才能检查一个系统的真正性能。
性能测试经常和压力测试一起进行，而且常常需要硬件和软件测试设备，这就是说，常常有必要的在一种苛刻的环境中衡量资源的使用（比如，处理器周期）。
外部的测试设备可以监测测试执行，当出现情况（如中断）时记录下来。
通过对系统的检测，测试者可以发现导致效率降低和系统故障的原因。
3．自动化测试技术基础
3.1自动化测试概念
随着软件系统的规模越来越大，整个系统的复杂性也越来越大，那么单纯的手工测试已经不适合这种大系统的测试了。
首先手工测试的效率低下，其次有些测试是手工测试所无法完成的。
为了解决手工测试效率低下和手工测试不能解决的一些测试等问题，自动化测试就应运而生了。
软件自动化测试就是执行某种程序设计语言编制的自动测试程序，控制被测软件的执行，模拟手动测试步骤，完成全自动或半自动测试。
其目的在于缩短测试周期，增强对软件性能方面的测试能力等，从而达到保证软件质量并使软件能够提前上线[9]。
3.1.1自动化测试
自动化测试就是希望能够通过自动化测试工具或其他手段，按照测试工程师的预定计划进行自动的测试，目的是减轻手工测试的劳动量，从而达到提高软件质量的目的。
自动化测试的目的在于发现老缺陷；
而手工测试的目的在于发现新缺陷。
测试自动化涉及到测试流程、测试体系、自动化化编译、持续集成、自动发布测试系统以及自动化测试等方面整合。
也就是说要让测试能够自动化，不仅是技术、工具的问题，更是一个公司和组织的文化问题。
首先公司从资金、管理上支持您，其次要有专门的测试团队去建立适合自动化测试的测试流程、测试体系；
其次就是把原代码从受控库中取出、编译、集成、发布可运行系统、进行自动化的单元测试和自动化的功能测试的过程[9]。
3.1.2自动化测试的优点
当正确实施软件自动化测试并严格遵守制定的测试过程时，自动化测试可带来若干好处。
假定对于给定的企业需求，测试工程师必须评估潜在的好处是否符合所要求的改进标准，在项目实施自动化测试是否仍然是合适的[10-11]。
（1）提高测试效率
一般来说，软件产品的发布周期很短，而在测试期间是每天都可能要发布一个版本供测试人员测试，一个系统的功能点有几千个上万个，手工测试是一个劳动密集型的工作，并且容易出错。
引入自动化测试能够用更有效、可重复的自动化测试环境代替繁琐的手工测试活动，而且能在更少的时间内完成更多的测试工作，从而提高了测试工程师的工作效率。
（2）令软件新版本进行回归测试的开销最小
产品发现错误以后的改动，代码变了，但要求的功能并没有变，所以测试用例也不必改变，自动化测试就可以很方便地进行回归测试，另外，对于产品型的软件，每次发布一个新的版本，其中大部分功能和界面都和上一个版本相似或完全相同，这部分功能特别适合于自动化测试，从而可以让测试达到测试每个特征的需求。
（3）可以完成一些手工测试不能或难以完成的测试
对于一些非功能性方面的测试，如：
压力测试、并发测试、大数据量测试、崩溃性测试等，这些测试用手工测试是很难，甚至是不可能完成的。
但自动化测试则能方便地执行这些测试，比如并发测试，使用自动化测试工具就可以模拟来自多方的并发操作了。
（4）具有一致性和可重复性
由于每次自动化测试运行的脚本是相同的，所以可以进行重复的测试，使得每次执行的测试具有一致性，手工测试则很难做到这点。
（5）更好地利用资源
将繁琐的测试任务自动化，可以使测试人员解脱出来，将精力更多地投入到测试案例的设计和必要的手工测试当中。
并且，理想的自动化测试能够按计划完全自动地运行，使得完全可以利用周末和晚上的时间执行自动测试。
（6）解决测试与开发之间的矛盾
通常在开发的末期，进入集成测试阶段，由于每发布一个版本的初期，测试系统的错误比较少，这时开发人员有等待测试人员测出错误的时间。
事实上在迭代周期很短的开发模式中，存在更多的矛盾，但自动化测试可以解决其中的主要矛盾。
（7）增加软件信任度
每一个测试人员都有自己特殊的经历和技术背景，有自己的一些操作习惯和先入为主的观念，这就导致不是所有的测试都是可信的，而且有时测试会把一些新的错误带入软件产品之中。
自动化测试则会在很大程度上避免这些问题。
一旦得知软件通过强有力的自动测试后，软件发布时对其的信任度也高（假设已做过很好的测试）。
总而言之，测试自动化的优点在于通过较少的开销就可以获得更彻底的测试能力，以及提高产品的质量。
3.1.3自动化测试的局限性
当然，软件自动化测试也并非万能，人们对软件自动化测试的理解也存在许多误区，认为自动化测试能完成一切工作，从测试计划到测试执行，都不需要人工干预。
其实软件自动化测试所完成的测试功能也是有限的。
以下几点是自动化测试的不足所在[10-11]：
（1）不能完全取代手工测试。
软件自动化测试不可能也没必要取代手工测试来完成所有的测试任务。
因为有些测试使用手工测试比自动化测试要简单，这时将测试自动化的开销就比较大了。
如以下一些情况：
①测试很少运行。
对于很少运行的测试任务，例如一年只需测试一次，对测试自动化则是一种浪费。
②软件不稳定。
如果在某段时间内软件的界面和功能更新频繁，那么修改相应的自动化测试点开销较大，因此只有当软件达到相对的稳定，没有界面性严重错误和中断错误才适合开始自动化测试。
③涉及感观方面的测试。
例如界面的美观、声音的体验、易用性的测试等，这类测试很容易通过人来验证，自动化测试反而难以执行。
④涉及物理交互的测试。
自动化测试很难完成与物理设备的交互，比如刷卡的测试等。
（2）手工测试比软件自动化测试发现的缺陷更多
自动化测试的最大特点在于适合重复测试。
一般情况下，以前运行过的测试再次用来检查软件的新版本往往暴露的缺陷要少得多。
测试专家JamesBach总结出，85%的缺陷靠手工发现，而自动化测试只能发现15%的缺陷。
自动化测试能够很好的发现老缺陷。
（3）软件自动化测试不能提高有效性
自动化测试并不会比手工运行相同测试更有效，它可以提高测试效率，但也可能对测试的进展起反作用。
（4）软件自动化测试可能会制约软件开发
应用软件的变化对自动化测试的影响要比手工测试更大一些，软件的部分改变有可能使自动化测试软件崩溃。
而设计和实施自动化测试要比手工测试开销大，并需要维护，所以对自动化测试影响较大的软件修改可能受到限制。
（5）软件自动化测试本身没有想象力
自动化测试是通过软件进行，测试程序只是按照运行机制执行。
手工测试时可以直接判断结果的正确性，而自动测试许多情况下测试结果还需要人工干预判断。
手工测试可以处理意外事件网络连接中断，此时必须重新建立连接。
手工测试时可以及时处理该意外，而自动化测试时该意外事件一般会导致测试的中止。
总的说来，软件自动化测试的优点和收益是显而易见的，但它同时也并非万能，只有对其进行合理的设计和顺利的实施才能从中获益。
3.2自动化测试的适用范围
Peer给出了对各类型测试进行自动化的参考[12]。
表3.1各类型测试进行自动化
技术
描述
备注
单元测试/组件测试
该测试工作通常是开发人员的职责，很多不同的方法能够被使用，比如“测试先行”，它是一个测试框架，开发人员在编写代码前编写不同的单元测试。
当测试通过是，代码也被完成了。
通过使用正式的自动化单元测试，不仅能够帮助开发人员产生更加稳定的代码而且能够使软件的整体质量更加的好。
冒烟测试/构建版本测试
冒烟测试是一般验证被测试系统的功能性测试用例的集合，冒烟测试背后的思想是确保基础是可以工作的，以便更大的测试工作能够开始
在构建过程能够确保构建已经为测试准备好时，冒烟测试通常是自动化的运行
功能/集成测试
这里测试的工作关注在验证的不同的组件之间的集成上。
这些类型的测试通常是被测试的更加复杂测试的基础，大量的边缘测试被合并以制造出不同的错误处理测试。
系统测试/用例测试
这种测试是通过执行用户场景模拟真实用户使用系统以证明系统具有被期望的功能的测试。
不需要使用自动化的测试。
安装测试、安全性测试通常是由手工完成，因此系统的环境不会是恒定不变的。
回归测试
回归测试实际上是重复已经存在的测试。
通常如果是手工完成的话，这种测试只在项目的结尾执行少数几次。
这里完全有潜力完成自动化的测试。
能够在每次构件完成后执行自动化的回归测试，以验证被测试系统的改变是否影响了系统的其他功能。
性能测试
性能测试包括以下不同测试形式：
--负载测试
--压力测试
--并发测试
如果没有自动化的测试工具，将无法执行通过模拟用户的负载实现的高密集度的性能测试。
可见重复性比较高的回归测试，以及手工测试难以完成的性能测试是自动化测试最有潜力应用和最能体现价值的地方，而早期的单元测试中如果引入自动化，也将大大提高开发出的代码质量。
当决定在一个产品的测试过程中实现自动化测试的时候，必须将自动化测试手工测试结合起来使用。
目的就是用较少的开销，获得彻底的测试，并提高商品的质量。
下表对何时使用自动化测试和何时使用手工测试进行了一个概要的总结。
表3.2何时使用自动化测试和手工测试
使用自动化测试
使用手工测试
项目没有严格的时间压力
具有良好定义的测试策略和测试计划
¡
知道要测试什么
知道什么时候测试
对于自动化测试拥有一个能够被识别的测试框架和侯选者
能够确保多个测试运行的构建策略
多平台环境需要被测试
拥有运行测试的硬件
拥有关注在自动化过程上的资源
被测试系统是可自动化测试的
没有适当的测试过程
没有一个测试什么，什么时候测试的清晰的蓝图
刚加入项目组，并且还不是完全的理解方案的功能性和或者设计
项目成员或者整个项目在时
升级会员 