软件测试课程教科书.docx
《软件测试课程教科书.docx》由会员分享，可在线阅读，更多相关《软件测试课程教科书.docx（89页珍藏版）》请在冰豆网上搜索。
软件测试课程教科书
《软件测试技术》课程教学大纲
目录
第一章-软件测试的基本概述10
1.1软件测试的概念10
1.1.1软件测试的背景10
1.1.2软件测试的定义10
1.1.3软件测试的分类11
1.1.4软件测试的对象13
1.1.5软件测试的目的13
1.1.6软件测试的原则13
1.1.7软件测试的模型14
1.1.8软件测试技术的发展15
1.2软件的BUG16
1.2.1软件Bug的定义16
1.2.2软件Bug的类型16
1.2.3软件Bug的级别16
1.2.4软件Bug的产生17
1.2.5软件Bug的构成17
1.2.6修复Bug的代价18
1.2.7BUG的影响18
1.3软件测试的经济学与心理学19
1.3.1软件测试的经济学19
1.3.2软件测试的心理学19
1.4软件测试的职业素质与要求20
1.4.1软件测试职业发展20
1.4.2软件测试人员工作目标与必备素质20
1.5软件质量管理与评价22
1.5.1软件质量的定义22
1.5.2软件质量的属性23
1.5.3软件质量的模型24
1.5.4软件质量的度量24
第二章-软件开发过程中各阶段的测试26
2.1软件开发与测试生存周期26
2.1.1软件生存周期26
2.1.2软件测试的生存周期26
2.1.3测试信息流27
2.2需求阶段的测试28
2.2.1目标阐述28
2.2.2需求分析28
2.2.3功能定义28
2.2.4需求阶段进行的测试28
2.3设计阶段的测试29
2.3.1外部设计29
2.3.2内部设计29
2.3.3设计阶段的测试29
2.4编码阶段的测试29
2.4.1测试方法29
2.4.2自顶向下与自底向上测试29
2.4.3静态测试与动态测试30
2.4.4性能测试30
2.5回归测试30
2.6运行和维护阶段的测试30
第三章-覆盖率（白盒）测试33
3.1覆盖率的概念33
3.2逻辑覆盖33
3.2.1语句覆盖34
3.2.2判定覆盖34
3.2.3条件覆盖35
3.2.4组合覆盖35
3.2.5路径覆盖35
第四章-功能（黑盒）测试37
4.1等价类测试37
4.1.1等价类的概念37
4.1.2等价类测试的类型37
4.1.3等价类测试的原则39
4.1.4等价类方法设计举例40
4.2边界值测试40
4.2.1边界值分析的概念40
4.2.2选择测试用例的原则40
4.2.3边界值方法设计举例41
4.3基于判定表的测试41
4.3.1判定表的概念41
4.3.2基于判定表的设计举例42
4.4基于因果图的测试42
4.4.1因果图的适用范围43
4.4.2因果图图形符号介绍43
4.4.3因果图法测试用例设计举例44
4.5基于场景的测试46
4.5.1基本流和备选流47
4.6其他黑盒测试47
4.6.1规范导出法47
4.6.2错误猜测法47
4.6.3基于接口的测试48
4.6.4基于故障的测试48
4.6.5基于风险的测试48
4.6.6比较测试49
第五章-单元测试和集成测试50
5.1单元测试的基本概念50
5.1.1单元测试的定义和目标50
5.1.2单元测试与集成测试、系统测试的区别50
5.1.3单元测试环境50
5.2单元测试策略51
5.2.1自顶向下的单元测试策略51
5.2.2自底向上的单元测试策略51
5.2.3孤立测试51
5.3单元测试分析51
5.3.1模块接口51
5.3.2局部数据结构52
5.3.3出错处理52
5.3.4边界条件52
5.3.5其他测试分析的指导原则52
5.4集成测试的基本概念52
5.4.1集成测试的定义52
5.4.2集成测试重点52
5.5集成测试的策略53
5.5.1一次集成53
5.5.2其他集成方式53
第六章-系统测试55
6.1系统测试的概念55
6.1.1什么是系统测试55
6.1.2系统测试与单元测试、集成测试的区别55
6.1.3系统测试环境55
6.2系统测试的方法55
6.2.1功能测试55
6.2.2性能测试56
6.2.3压力测试56
6.2.4容量测试57
6.2.5安全性测试57
6.2.6恢复测试57
6.2.7界面测试57
6.2.8兼容性测试58
6.2.9易用性测试59
6.2.10安装测试59
6.2.11文档测试60
6.3其他测试简介60
6.3.1确认测试60
6.3.2α和β测试61
6.3.3验收测试61
6.3.4回归测试61
6.4如何做好系统测试61
6.5系统测试问题总结分析61
第七章-软件性能测试和可靠性测试62
7.1软件性能测试的基本概念62
7.1.1什么是软件性能62
7.1.2软件性能的测试62
7.2软件性能测试的执行63
7.2.1性能测试的过程与组织63
7.2.2性能分析64
7.3软件可靠性的概念66
7.3.1软件可靠性定义66
7.3.2影响软件可靠性的因素66
7.3.3软件可靠性与硬件可靠性的区别66
7.4软件可靠性测试的执行过程67
功能识别67
定义换效等级67
可靠性测试覆盖67
7.5软件可靠性的分析方法69
第八章-软件测试过程和管理70
8.1软件测试过程70
8.1.1测试过程的概念70
8.1.2测试过程的抽象模型70
8.2软件测试过程的组织和管理70
8.2.1软件测试过程管理的特点与原则70
8.3软件测试计划的确定71
8.3.1测试计划的整体目标71
8.3.2测试计划的要点71
8.4软件测试的管理71
8.4.1测试环境管理71
8.4.2测试文档管理72
8.4.3测试执行管理72
8.5软件测试质量分析72
第九章-软件自动化测试73
9.1自动化测试的原理和方法73
9.2自动化测试的优劣73
9.3测试工具的分类74
9.3.1白盒测试工具75
9.3.2黑盒测试工具76
9.3.3测试管理工具77
9.4主流测试工具产品简介77
9.4.1LoadRunner77
9.4.2BugFree79
前言
在当前国家重点扶持软件产业发展的新形势下，软件工程和软件质量保证中存在的问题已越来越成为制约软件产业快速发展的重要因素。
这其中，对软件测试技术的掌握和应用的欠缺是主要表现之一。
随着人们对软件本质的进一步认识，软件测试对于保证软件质量的作用逐渐为软件专业人员所重视，软件测试在软件开发中的作用也越来越重要，软件测试的地位得到前所未有的提高。
软件必须经过测试，测试是目前验证软件是否达到了预期设定功能的惟一有效方法，测试贯穿于整个软件开发的全过程。
软件测试是对需求分析、设计规格说明和编写的代码的最后复审，是为了发现软件缺陷或故障而执行程序的过程。
这里所说的程序是广义的概念。
随着软件系统的复杂性和规模不断地增加，测试工作开始的越早，测试执行得越彻底，所带来的整个软件开发成本下降得就越多，由此而引发的专业化、高效率的软件测试要求越来越高，软件测试职业的价值日益显著，软件测试专业机构和组织迅速发展，软件测试技术已成为软件产业的新兴门类。
第一章-软件测试基本概述
学习目标
1．正确理解软件测试的背景，软件BUG的概念。
2．正确理解软件测试定义、目的和原则。
3．正确理解软件测试不同的测试方法。
4．熟悉软件测试的几种模型。
5．了解软件测试职业与素质的要求。
1.1软件测试概述
1.1.1软件测试的背景
随着计算机技术的迅速发展，软件系统的规模与复杂性与日俱增，软件的成本、软件中存在的缺陷和故障造成的各类损失也大大增加，甚至带来灾难性的后果。
软件质量问题已成为所有使用软件和开发软件的人们的关注的焦点。
由于软件是人脑的高度智力化的体现，不同于其他科技和生产领域，因此软件与生俱来就是存在缺陷和故障的。
如何防止和减少这些存在的缺陷和故障，答案是进行软件测试。
测试是最有效的排除和防止软件缺陷和故障的手段，并由此促使了软件测试理论与技术实践的快速发展，新的测试理论、测试方法、测试工具不断涌现。
与此同时，软件测试技术也同步完善和发展起来。
今天，在软件比较发达的国家，软件测试已经成为一个独立的产业，软件公司纷纷建立独立的测试队伍研究测试技术并开展条件下运行测试工作。
中国的软件测试起步较晚，但随着我国软件产业的蓬勃发展以及人们对软件质量的重视，软件测试正在成为一个新兴的产业。
1.1.2软件测试的定义
1.关于软件测试的常用术语
（1）测试
1）测试是一项活动，在这项活动中某个系统或者组成的部分将在特定的条件下，结果将被观察和记录，并对系统或者组成部分进行评价。
2）测试是一个或者多个测试用例的集合。
3）我们说的测试，若无特别说明，一般是指系统测试。
（2）测试用例
1）测试用例是为特定的目的而设计的一组测试输入、执行条件和预期的结果。
2）测试用例是测试执行的最小实体。
2．软件测试定义
观点一：
1972年，软件测试领域先驱BillHetzel博士在美国的北卡罗来纳大学组织了历史上第一次正式的关于软件测试的会议。
1973年他首先给出软件测试的定义：
“测试就是建立一种信心，确信程序能够按预期的设想运行”。
1983年他又将软件测试的定义修改为“评价一个程序和系统的特性或能力，并确定它是否达到预期的结果。
软件测试就是以此为目的的任何行为。
”这他定义中的“设想”和“预期结果”其实就是我们现在所说的“用户需求”。
他把软件的质量定义为“符合要求”。
他认为：
测试方法是试图验证软件是“工作的”。
所谓“工作的”就是指软件的功能是按照预先的设想执行的。
观点二：
与观点一相反，代表人物是GlenfordJ.Myers。
他认为应该首先认定软件是有错误的，然后用测试去发现尽可能多的错。
除此之外，Myers还给出了与测试相关的三个重要观点，那就是：
（1）测试是为了证明程序有错，而不是证明程序无措
（2）一个好的测试用例是在于它发现以前未能发现的错误
（3）一个成功的测试时发现了以前未发现的错误测试
1.1.3软件测试的分类
软件测试是一项复杂的系统工程，从不同的角度考虑可以有不同的划分方法，对测试进行分类是为了更好的明确测试的过程，了解测试究竟要完成哪些工作，尽量做到全面测试。
1.按是否关心系统内部结构划分：
1）白盒测试
白盒测试也称结构测试或逻辑驱动测试，是指基于一个应用代码的内部逻辑知识，即基于覆盖全部代码、分支、路径、条件的测试，它是知道产品内部工作过程，可通过测试来检测产品内部动作是否按照规格说明书的规定正常进行，按照程序内部的结构测试程序，检验程序中的每条通路是否都有能按预定要求正确工作，而不顾它的功能，白盒测试的主要方法有逻辑驱动、基路测试等，主要用于软件验证。
“白盒”法全面了解程序内部逻辑结构、对所有逻辑路径进行测试。
“白盒”法是穷举路径测试。
在使用这一方案时，测试者必须检查程序的内部结构，从检查程序的逻辑着手，得出测试数据。
贯穿程序的独立路径数是天文数字。
但即使每条路径都测试了仍然可能有错误。
第一，穷举路径测试决不能查出程序违反了设计规范，即程序本身是个错误的程序。
第二，穷举路径测试不可能查出程序中因遗漏路径而出错。
第三，穷举路径测试可能发现不了一些与数据相关的错误。
白盒测试可以借助一些工具来完成如JunitFramework，Jtest等。
2）黑盒测试
黑盒测试是指不基于内部设计和代码的任何知识，而基于需求和功能性的测试，黑盒测试也称功能测试或数据驱动测试，它是在已知产品所应具有的功能，通过测试来检测每个功能是否都能正常使用，在测试时，把程序看作一个不能打开的黑盆子，在完全不考虑程序内部结构和内部特性的情况下，测试者在程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数锯而产生正确的输出信息，并且保持外部信息（如数据库或文件）的完整性。
黑盒测试方法主要有等价类划分、边值分析、因果图、错误推测等。
“黑盒”法着眼于程序外部结构、不考虑内部逻辑结构、针对软件界面和软件功能进行测试。
“黑盒”法是穷举输入测试，只有把所有可能的输入都作为测试情况使用，才能以这种方法查出程序中所有的错误。
实际上测试情况有无穷多个，人们不仅要测试所有合法的输入，而且还要对那些不合法但是可能的输入进行测试。
黑盒测试也可以借助一些工具，如WinRunner，QuickTestPro，RationalRobot等。
2.按是否需要执行被测软件的角度
按是否需要执行被测软件的角度，可分为静态测试和动态测试，前者不利用计算机运行待测程序而应用其他手段实现测试目的，如代码审核。
而动态测试则通过运行被测试软件来达到目的。
3.按阶段划分：
1）单元测试
单元测试是对软件中的基本组成单位进行的测试，如一个模块、一个过程等等。
它是软件动态测试的最基本的部分，也是最重要的部分之一，其目的是检验软件基本组成单位的正确性。
因为单元测试需要知道内部程序设计和编码的细节知识，一般应由程序员而非测试员来完成，往往需要开发测试驱动模块和桩模块来辅助完成单元测试。
因此应用系统有一个设计很好的体系结构就显得尤为重要。
一个软件单元的正确性是相对于该单元的规约而言的。
因此，单元测试以被测试单位的规约为基准。
单元测试的主要方法有控制流测试、数据流测试、排错测试、分域测试等等。
2）集成测试
集成测试是在软件系统集成过程中所进行的测试，其主要目的是检查软件单位之间的接口是否正确。
它根据集成测试计划，一边将模块或其他软件单位组合成越来越大的系统，一边运行该系统，以分析所组成的系统是否正确，各组成部分是否合拍。
集成测试的策略主要有自顶向下和自底向上两种。
3）系统测试
系统测试是对已经集成好的软件系统进行彻底的测试，以验证软件系统的正确性和性能等满足其规约所指定的要求，检查软件的行为和输出是否正确并非一项简单的任务，它被称为测试的“先知者问题”。
因此，系统测试应该按照测试计划进行，其输入、输出和其他动态运行行为应该与软件规约进行对比。
软件系统测试方法很多，主要有功能测试、性能测试、随机测试等等。
4）验收测试
验收测试旨在向软件的购买者展示该软件系统满足其用户的需求。
它的测试数据通常是系统测试的测试数据的子集。
所不同的是，验收测试常常有软件系统的购买者代表在现场，甚至是在软件安装使用的现场。
这是软件在投入使用之前的最后测试。
1.1.4软件测试的对象
软件测试是贯穿整个软件开发周期的，不仅仅是执行程序，软件测试对象包括需求规格说明、概要设计规格说明、详细设计规格说明以及源程序
1.1.5软件测试的目的
以最少的人力，物力和时间找出软件中潜在的各种错误与缺陷，通过修正各种错误和缺陷提高软件质量，规避软件发布后由于潜在的软件缺陷和错误造成的隐患以及带来的商业风险。
1.1.6软件测试的原则
1.软件开发人员即程序员应当避免测试自己的程序。
不管是程序员还是开发小组都应当避免测试自己的程序或者本组开发的功能模块。
若条件允许，应当由独立于开发组和客户的第三方测试组或测试机构来进行软件测试。
但这并不是说程序员不能测试自己的程序，而且更加鼓励程序员进行调试，因为测试由别人来进行可能会会更加有效、客观，并且容易成功，而允许程序员自己调试也会更加有效和针对性。
2.应尽早地和不断地进行软件测试。
应当把软件测试贯穿到整个软件开发的过程中，而不应该把软件测试看作是其过程中的一个独立阶段。
因为在软件开发的每一环节都有可能产生意想不到的问题，其影响因素有很多，比如软件本身的抽象性和复杂性、软件所涉及问题的复杂性、软件开发各个阶段工作的多样性，以及各层次工作人员的配合关系等。
所以要坚持软件开发各阶段的技术评审，把错误克服在早期，从而减少成本，提高软件质量。
3.对测试用例要有正确的态度：
第一，测试用例应当由测试输入数据和预期输出结果这两部分组成；第二，在设计测试用例时，不仅要考虑合理的输入条件，更要注意不合理的输入条件。
因为软件投入实际运行中，往往不遵守正常的使用方法，却进行了一些甚至大量的意外输入导致软件一时半时不能做出适当的反应，就很容易产生一系列的问题，轻则输出错误的结果，重则瘫痪失效！
因此常用一些不合理的输入条件来发现更多的鲜为人知的软件缺陷。
4.人以群分，物以类聚，软件测试也不例外，一定要充分注意软件测试中的群集现象，也可以认为是“80-20原则”。
不要以为发现几个错误并且解决这些问题之后，就不需要测试了。
反而这里是错误群集的地方，对这段程序要重点测试，以提高测试投资的效益。
5.严格执行测试计划，排除测试的随意性，以避免发生疏漏或者重复无效的工作。
6.应当对每一个测试结果进行全面检查。
一定要全面地、仔细地检查测试结果，但常常被人们忽略，导致许多错误被遗漏。
7.妥善保存测试用例、测试计划、测试报告和最终分析报告，以备回归测试及维护之用。
在遵守以上原则的基础上进行软件测试，可以以最少的时间和人力找出软件中的各种缺陷，从而达到保证软件质量的目的。
8.最重要的一个原则：
所有测试的标准都是建立在用户需求之上。
1.1.7软件测试的模型
（1）V模型
V模型中的过程从左到右，描述了基本的开发过程和测试行为。
V模型的价值在于它非常明确地标明了测试过程中存在的不同级别，并且清楚地描述了这些测试阶段和开发过程期间各阶段的对应关系。
从这个图，可以直观的观察到测试过程的局限性，它把测试过程放在了需求分析、概要设计、详细设计与编码之后了，容易使人理解测试是软件开发的最后一个阶段，主要针对程序进行测试寻找错误了。
而需求分析阶段隐藏的问题只能在最后才能发现。
所以，这个图形，不能很好的反应软件测试贯穿整个开发的过程。
（2）W模型
根据图形，很容易看出，W模型比V模型更科学，它伴随着整个开发过程，而且测试对象不仅仅是程序，同时也测试需求与设计。
（3）H模型
H模型：
测试条件只要成熟，测试准备活动完成了，那么就可以执行测试活动。
在H模型中，测试模型是一个独立的过程，贯穿于整个产品周期，与其他流程并发的进行。
当某个测试时间点就绪时，软件测试即从测试准备阶段进入测试执行阶段。
1.1.8软件测试技术的发展
当前，软件测试技术主要包括了一下几个方面的内容，这几方面都在不断地快速、规范的发展。
1.软件验证技术
软件验证的目的用于证明软件生命周期的各个阶段以及各阶段间的逻辑协调性和正确性。
目前，软件验证技术还只是适用于特殊用途的小型程序。
2.软件静态测试
目前，软件测试正在主键地由对程序代码的静态测试向高层开发产品的静态测试方向发展，如静态分析工具的产生。
所谓静态分析工具是在不执行程序的情况下，可以进行类型分析、接口分析、输入输出规格说明分析等。
3.测试数据的选择
在测试数据选择方面，主要是对测试用例进行选择，这对测试的成功与否有着重要的影响。
4.自动化测试技术
自动化测试是软件测试技术的最新发展方向，其主要的目标是研究如何实现软件测试的自动化过程以及相关的一系列内容，具体表现是集成化测试系统。
它将多种测试工具融为一体，合成为功能强大的测试工具。
1.2软件中的BUG
软件Bug实际是软件产品没有达到预期设计目标，在软件内部存在的一种缺陷。
在不影响用户和系统正常运行的情况下处于隐蔽状态，没有表现出来。
当Bug发生运行错误时，轻者影响用户使用，重者会构成事故，造成损失或伤害。
1.2.1软件Bug的定义
软件中的Bug是软件开发过程中的“副产品”。
通常，Bug会导致软件产品在某种程度上不能满足用户的需求。
1.2.2软件Bug的类型
1.产品说明书中规定要做的事情,而软件没有实现。
例如:
产品说明书要求计算器要实现加,减,乘和除功能,做出来的计算器不能进行除运算,这就是一个BUG.
2.产品说明书中规定不要做的事情,而软件却实现了。
例如:
产品说明书要求计算器除加,减,乘和除功能外其它的功能不要实现,做出来的计算器不仅能进行加减乘除运算,还能进行乘方或三角函数运算,这也是一个BUG.
3.产品说明书没有提到的事情,而软件却实现了。
例如:
产品说明书要求计算器要实现加,减,乘和除功能,做出来的计算器还能进行乘方运算,这也是一个BUG.
4.产品说明书中没有提到但是是必须要做的事情,软件却没有实现。
例如：
产品说明书要求计算器要实现加,减,乘和除功能,但是没有提到在电量很低情况下也能正常使用,而做出来的计算器在电量很低的时候计算错误,这也是一个BUG.
5.软件很难理解,很难去使用,速度超慢,测试人员站在最终用户的角度看到的问题是平常的但不是正确的。
例如：
产品说明书要求计算器要实现加,减,乘和除功能,但是按键使用的文字或标识不清楚,如:
"加"按键用"和"表示,或者计算1+1需要1分钟或者更长时间.这也是一个BUG.
1.2.3软件Bug的级别
致命：
数据被破坏、数据丢失、系统崩溃、系统无法运行
严重：
处理结果不正确、流程不对、性能不能满足要求
一般：
不会影响整个系统的运行性能
微小：
操作不方便，错别字，界面布局不合理，难以理解等
建议：
界面、描述更改等。
1.2.4软件Bug的产生
1.2.5软件Bug的构成
Bug类型
具体BUG
备注
功能BUG
需求规格说明BUG
功能BUG
测试BUG
测试标准引起的BUG
系统BUG
外部接口BUG
终端、打印机等设备接入
内部接口BUG
硬件结构BUG
软件结构BUG
控制与顺序BUG
资源管理BUG
加工BUG
算术与操作BUG
初始化BUG
控制与次序BUG
静态逻辑BUG
数据BUG
动态数据BUG
静态数据BUG
数据内容、结构、属性BUG
代码BUG
程序编写BUG
界面BUG
1.2.6修复Bug的代价
我们来看看修复一个bug所需要的成本。
在软件开发周期的不同阶段，修复一个bug所需的成本差别非常之大。
越是到了后期，修复bug越困难，成本也就越高。
从下图可以看出，在测试阶段修复bug的代价是设计开发阶段的几倍，而一旦产品上线，进入维护期后，所需的代价更是达到几十倍。
1.2.7BUG的影响
●1962年7月28日，MarinerI空间探测器事件。
Mariner1航空软件的bug导致火箭在发射时偏离了其的预期轨道。
任务控制器在大西洋上空将整个火箭摧毁。
在对这起事故进行调查中发现，使用铅笔撰写下的一个公式被不正确的录入到计算机代码中，直接导致计算机错误的计算
升级会员 