编辑推荐
本书详尽地介绍了软件测试的各个方面从测试概念、测试模型、测试过程、测试阶段等各个不同的视角来探讨软件测试的重要性，重点讲解了软件测试的各种方法和技术，并将它们应用在软件测试框架的不同阶段，满足不同的应用系统测试的需求。
目录
第1章软件测试概述1
1.1软件测试产生的背景2
1.2软件测试的定义3
1.3软件测试的复杂性与经济性分析4
1.4软件缺陷6
1.5软件测试人员应具备的素质8
本章小结9
练习题10
第2章软件测试基础11
2.1软件测试的目的12
2.2软件测试的原则13
2.3软件测试的分类14
2.4常见的一些软件测试16
2.5软件测试过程模型17
本章小结20
练习题20
第3章软件测试过程与方法22
3.1单元测试23
3.2集成测试25
3.3确认测试30
3.4系统测试31
3.5验收测试32
本章小结34
练习题34
第4章软件测试策略36
4.1软件测试策略的定义37
4.2软件测试策略的重要性37
4.3软件测试策略的主要目的37
4.4软件测试策略的主要内容38
4.5软件测试策略的影响因素41
4.6软件测试策略的制定过程41
本章小结42
练习题43
第5章白盒测试44
5.1逻辑覆盖法45
5.2路径覆盖法48
本章小结52
练习题52
第6章黑盒测试54
6.1等价类划分法55
6.2边界值法57
6.3决策表法58
6.4因果图法61
6.5场景法65
本章小结69
练习题70
第7章面向对象的软件测试72
7.1面向对象的特点73
7.2面向对象的开发对软件测试的影响74
7.3面向对象的软件测试的基本概念75
7.4面向对象的软件测试的内容76
7.5面向对象的测试模型及方法78
7.6面向对象测试工具JUnit87
本章小结88
练习题89
第8章缺陷跟踪管理90
8.1Bug的影响91
8.1.1精神的摧残91
8.1.2形象的损失91
8.1.3财富的流失91
8.2Bug的产生92
8.2.1交流的误解92
8.2.2软件的复杂性、程序员的错误92
8.2.3需求变化92
8.2.4时间压力92
8.2.5文档贫乏93
8.2.6软件开发工具93
8.3Bug如何穿透测试93
8.3.1代价太大93
8.3.2市场决策93
8.3.3时间紧迫93
8.3.4现场证据94
8.3.5过于自信94
8.3.6模糊提交和测试环境94
8.4Bug的种类94
8.4.1需求阶段的Bug——三种需求94
8.4.2分析、设计阶段的Bug——忽略设计94
8.4.3实现阶段的Bug——遗漏的功能95
8.4.4配置阶段的Bug95
8.4.5短视将来的Bug95
8.4.6静态文档的Bug95
8.5Bug的生命周期96
8.6Bug的关键字96
8.6.1Bug的流转状态关键字96
8.6.2Bug的解决关键字97
8.6.3Bug的严重等级关键字97
8.6.4Bug处理的优先等级关键字97
8.7Bug的管理98
8.8缺陷管理工具JIRA99
8.8.1JIRA介绍99
8.8.2JIRA安装100
8.8.3JIRA用户使用101
8.8.4JIRA后台使用102
本章小结105
练习题105
第9章项目质量保证107
9.1软件质量保证的理论探索108
9.1.1软件质量保证过程的认识108
9.1.2生产线的隐喻109
9.1.3SQA和其他工作的组合109
9.1.4QA和QC109
9.1.5QA和SEPG110
9.1.6QA和组织级的监督管理110
9.2软件质量保证的工作内容和工作方法111
9.2.1计划111
9.2.2审计/证实111
9.2.3问题跟踪111
9.3软件质量保证的素质112
9.4软件质量保证的活动内容112
9.5软件质量保证正式的技术评审113
9.6软件质量保证统计114
9.7质量保证与检验114
9.8软件质量保证检验项目的内容115
9.9ISO 9000软件质量标准的了解116
本章小结116
练习题117
第10章项目质量控制118
10.1项目质量控制的定义、目的和必要性119
10.2质量控制的内容及过程120
10.3质量控制的方法、技术和工具122
10.4质量控制的依据及成果123
本章小结131
练习题131
第11章Web网站测试133
11.1Web网站功能测试134
11.2性能测试的种类136
11.3安全性测试136
11.4可用性/可靠性测试137
11.5配置和兼容性测试138
11.6数据库测试139
11.7Web测试用例考虑的因素139
本章小结142
练习题143
第12章自动化测试144
12.1什么是软件自动化测试145
12.2软件自动化的使用范围146
12.3软件自动化工具分类146
12.3.1白盒测试工具146
12.3.2黑盒测试工具147
12.3.3测试设计与开发工具147
12.3.4测试执行和评估工具148
12.3.5测试管理工具148
12.3.6常用测试工具148
12.3.7其他公司测试工具150
12.3.8一些开源测试工具150
12.4Quality Center的基本介绍152
12.5QTP的基本介绍153
12.5.1启动QTP153
12.5.2插件加载设置与管理153
12.5.3创建一个空的测试项目153
12.5.4录制和测试运行设置154
12.5.5指定需要录制的应用程序155
12.5.6使用QTP编写第一个自动化测试脚本156
12.6LoadRunner的基本介绍158
12.6.1LoadRunner 常用术语158
12.6.2LoadRunner工作流程159
12.6.3Virtual User Generator(VuGen)简介160
12.6.4设置运行时行为161
12.6.5查看脚本的运行情况164
12.6.6查看测试结果165
本章小结166
练习题166
第13章软件测试文档168
13.1测试文档169
13.1.1测试文档的定义169
13.1.2测试文档的内容169
13.1.3软件生命周期各阶段的测试任务与可交付的文档170
13.2测试计划172
13.2.1测试计划的定义172
13.2.2测试计划的目的和作用173
13.2.3测试计划书173
13.2.4测试计划的内容173
13.2.5软件测试计划的制订174
13.3测试用例设计176
13.3.1测试用例176
13.3.2测试用例文档应包含以下内容176
13.4测试总结报告177
13.4.1测试结果统计表177
13.4.2测试问题表和问题统计表178
13.4.3测试进度表178
13.4.4测试总结表178
本章小结179
练习题179
第14章软件质量保障与软件测试181
14.1软件质量的定义182
14.2软件质量的模型182
14.2.1McCall 质量模型182
14.2.2Bohm 质量模型182
14.2.3ISO的软件质量模型182
14.3软件质量要素184
14.4软件质量保证（SQA）185
14.4.1基本目标185
14.4.2品质保证人员（QA）186
14.4.3QA与QC的区别186
14.4.4SQA活动187
14.5软件质量保证与软件测试187
本章小结188
练习题188
参考文献190软件测试技术目录
序言
近年来，计算机技术突飞猛进，软件的开发与使用越来越普遍、越来越高端，从早期的数值计算，到现在云计算、互联网+、电子商务、大数据等，涉及各个领域。软件中存在的问题或安全漏洞也频繁出现，显然，软件的质量保证越来越受到重视。而目前我国软件测试行业的从业人员相当缺乏，并且在IT行业中重视程度不够。
本书从软件测试的基础开始，将软件测试的测试流程与软件开发的流程联系起来作为主线，介绍软件测试的过程、测试计划、测试用例设计与实施、测试缺陷跟踪以及测试分析等。在测试的不同阶段开始单元测试、集成测试、系统测试、验收测试等；在不同阶段选择不同的测试方法和技术，如静态测试、白盒测试、黑盒测试等，并分别介绍怎样使用自动化工具对相关软件进行测试，主要介绍了功能自动化工具QPT以及性能测试工具LoadRunner的基本使用方法，还以案例穿插介绍了缺陷管理工具JIRA。
本书的特点如下。
（1）软件测试知识点全面。本书包括基本的软件测试理论知识，也包括当今业界常用的测试方法。
（2） 具有科学、系统的工程观点和方法。全书以软件工程开发系统的科学思想，将软件测试贯穿于整个软件生命周期，介绍了软件测试在软件生命周期中各个阶段采用的方法和应用。
（3）理论联系实际。本书各个章节都提供了大量的应用实例以说明各个测试知识点的运用，并且每章后附有习题和练习。
本书由何春梅、唐滔任主编，苟英、陈怡然、谭凤任副主编。何春梅主持了全书的编写以及审稿工作，苟英负责全书的总体框架设计和统稿工作。第1～4章由苟英编写，第5和6章由何春梅编写，第7章由谭凤编写，第8～11章由唐滔编写，第12～14章由陈怡然编写。本书在编写过程中得到了重庆工程学院软件学院师生的大力支持，在此表示感谢！
由于作者水平有限，书中疏漏之处在所难免，欢迎广大读者提出宝贵意见。
编者
2017年5月软件测试技术
文摘
第1章软件测试概述
本章目标
了解软件测试的背景
掌握软件缺陷的定义及缺陷跟踪流程
熟悉软件测试的复杂性与经济性分析
掌握软件测试的定义
熟悉软件测试人员应具备的素质本章单词
test case: bug:
static testing:walkthrough:软件测试是软件开发过程中的重要阶段，它是伴随着软件的产生而产生的。软件测试是保证软件质量、提高软件可靠性的重要途径。软件测试的质量与测试人员的技能、经验以及对被测软件的理解密切相关。在最初的软件开发过程中，软件规模小而简单，开发过程随意而无序。软件测试的含义也比较狭窄，仅仅等同于调试，往往由开发人员兼任测试工作，目的是为了纠正软件中存在的已知问题。对测试的投入少，测试介入晚，往往是等到代码成形，产品完成后才进行测试。随着时间的推移，软件测试的内涵在不断丰富，人们对软件测试的认识在不断深入。要完整地理解软件测试，就要从不同角度去审视。
1.1软件测试产生的背景
早期的软件开发过程中，开发人员将测试等同于“调试”，目的是纠正软件中已知的故障，常常由开发人员自己完成这部分的工作。对测试的投入极少，测试介入也晚，常常是等到形成代码，产品已经基本完成时才进行测试。
直到1957年，软件测试才开始与调试区别开来，作为一种发现软件缺陷的活动。由于一直存在着“为了让我们看到产品在工作，就得将测试工作往后推一点”的思想，潜意识里对测试的目的就理解为“使自己确信产品能工作”。测试活动始终晚于开发的活动，测试通常被作为软件生命周期中最后一项活动而进行。当时也缺乏有效的测试方法，主要依靠错误推测(Error Guessing)寻找软件中的缺陷。因此，大量软件交付后，仍存在很多问题，软件产品的质量无法保证。
20世纪70年代，这个阶段开发的软件仍然不复杂，但人们已开始思考软件开发流程的问题，尽管对“软件测试”的真正含义还缺乏共识，但这一词条已经频繁出现。一些软件测试的探索者们建议在软件生命周期的开始阶段就根据需求制订测试计划，这时也涌现出一批软件测试的宗师，Bill Hetzel 博士和Glenford J. Myers就是其中的领导者。
20世纪80年代初期，软件和IT行业进入了大发展时期，软件趋向大型化、高复杂度，所以软件的质量越来越重要。这个时候，一些软件测试的基础理论和实用技术开始形成，并且人们开始为软件开发设计了各种流程和管理方法，软件开发的方式也逐渐由混乱无序的开发过程过渡到结构化的开发过程，以结构化分析与设计、结构化评审、结构化程序设计以及结构化测试为特征。人们还将“质量”的概念融入其中，软件测试定义发生了改变，测试不单纯是一个发现错误的过程，而且将测试作为软件质量保证（SQA）的主要职能。此时软件开发人员和测试人员开始坐在一起探讨软件工程和测试问题。软件测试已有了行业标准（IEEE/ANSI），需要运用专门的方法和手段。
在竞争激烈的今天，无论是软件的开发商还是软件的使用者，都生存在竞争环境中。软件开发商为了占有市场，必须把产品质量作为企业的重要目标之一，以免在竞争中被淘汰出局。用户为了保证自己的业务顺利完成，当然希望选用优质的软件。质量不佳的产品不仅会使开发上的维护费用和用户的使用成本增加，还可能产生其他的问题，造成公司信誉下降。一些关键的应用领域如果质量有问题，还可能造成灾难性的后果。现在人们已经逐步认识到软件中存在的错误导致了软件开发在成本、进度和质量上的失控。由于软件是由人来完成的，所以它不可能十全十美，虽然不可能完全杜绝软件中的错误，但是可以用软件测试等手段使程序中的错误数量尽可能少，密度尽可能小。
国际上，软件测试（软件质量控制）是一件非常重要的工作，测试也作为一个非常独立的职位。IBM、微软等开发大型系统软件公司，很多重要项目的开发测试人员的比例能够达到1∶2甚至1∶4。在软件测试技术方面，自动化测试系统（ATS,automatic test system）正朝着通用化、标准化、网络化和智能化的方向迈进。20世纪90年代中期以来，自动测试系统开发研制的指导思想发生了重大变化，以综合通用的ATS代替某一系列，采用共同的硬件及软件平台实现资源共享的思想受到高度重视。其主要思路是: 采用共同的测试策略，从设计过程开始，通过“增值开发”的方式使后一阶段测试设备的研制能利用前一阶段的开发成果；TPS要能够移植，软件模块可以重用；使用商业通用标准、成熟的仪器设备，缩短研发时间，降低开发成本并且易于升级和扩展。
国内软件测试的现状主要表现在以下方面。
（1） 软件测试的地位还不高，在很多公司还是一种可有可无的地位，大多只停留在软件单元测试、集成测试和功能测试上。
（2） 软件测试标准化和规范化不够。
（3） 软件测试从业人员的数量同实际需求有不小差距，国内软件企业中开发人员与测试人员数量一般为5∶1，国外一般为2∶1或1∶1，而最近有资料显示微软已把此比例调整为1∶2。
（4） 国内缺乏完全商业化的操作机构，一般只是政府部门的下属机构在做一些产品的验收测试工作，实质意义不大，软件测试产业化还有待开发和深掘。
因此，我国的软件测试行业较欧美国家的差距还比较大。通过研究发现，造成这种情况的原因主要有以下几点:
(1) 国内软件产业本身不强大，软件质量较低；
(2) 软件管理者与用户对软件质量意识有待加强；
(3) 软件管理者对软件测试的认识和重视程度不够；
(4) 软件行业质量监督体系不够好；
(5) 软件从业人员的素质不够高；
(6) 软件测试行业处于起步阶段，经济效益短期内不明显。
1.2软件测试的定义
1983年IEEE提出的软件工程术语中给软件测试下的定义是: 使用人工或自动的手段来运行或测定某个软件系统的过程，其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别。这个定义明确指出: 软件测试的目的是为了检验软件系统是否满足需求。它再也不是一个一次性的，而且只是开发后期的活动，而是与整个开发流程融合成一体。
扩展定义: 软件测试就是在软件投入运行前，对软件需求分析、设计规格说明和编码的最终复审，是软件质量保证的关键步骤。
软件测试是根据软件开发各阶段的规格说明和程序的内部结构而精心设计一批测试用例（包括输入数据与预期输出结果），并利用这些测试用例运行软件，以发现软件错误的过程。广义的软件测试是由确认、验证、测试3个方面组成。
(1) 确认: 评估将要开发的软件产品是否正确无误、可行和有价值的。确认意味着确保一个待开发软件是正确无误的，是对软件开发构想的检测，主要体现在计划阶段、需求分析阶段，也会出现在测试阶段。
(2) 验证: 检测软件开发的每个阶段、每个步骤结果是否正确无误，是否与软件开发各阶段的要求或期望的结果相一致。验证意味着确保软件会正确无误地实现软件的需求，开发过程是沿着正确的方向进行的。主要体现在设计阶段、编码阶段。
(3) 测试: 与狭隘的测试概念统一。主要体现在编码阶段和测试阶段。
确认、验证与测试是相辅相成的。确认产生验证和测试的标准，验证和测试帮助完成确认。
1.3软件测试的复杂性与经济性分析
人们在对软件工程开发的常规认识中，认为开发程序是一个复杂而困难的过程，需要花费大量的人力、物力和时间，而测试一个程序则比较容易，不需要花费太多的精力。这其实是人们对软件工程开发过程理解上的一个误区。在实际的软件开发过程中，作为现代软件开发工业一个非常重要的组成部分，软件测试正扮演着越来越重要的角色。随着软件规模的不断扩大，如何在有限的条件下对被开发软件进行有效的测试正成为软件工程中一个非常关键的课题。
设计测试用例是一项细致并且需要具备高度技巧的工作，稍有不慎就会顾此失彼，发生不应有的疏漏。下面分析了容易出现问题的根源。
(1) 完全测试是不现实的
在实际的软件测试工作中，不论采用什么方法，由于软件测试工作量极其巨大，都不可能进行完全彻底的测试。所谓彻底测试，就是让被测程序在一切可能的输入情况下全部执行一遍。通常也称这种测试为“穷举测试”。
穷举测试会引起以下几种问题:
① 输入量太大；
② 输出结果太多；
③ 软件执行路径太多；
④ 说明书存在主观性。
E.W.Dijkstra的一句名言对测试的不彻底性做了很好的注解: “程序测试只能证明错误的存在，但不能证明错误的不存在。”由于穷举测试工作量太大，实践上行不通，这就注定了一切实际测试都是不彻底的，也就不能够保证被测试程序在理论上不存在遗留的错误。
(2) 软件测试是有风险的
穷举测试的不可行性使得大多数软件在进行测试的时候只能采取非穷举测试，这又意味着一种冒险。比如在使用Microsoft Office工具中的Word时，可以做这样的一个测试: ①新建一个Word文档； ②在文档中输入汉字“胡”； ③设置其字体属性为“隶书”，字号为初号，效果为“空心”； ④将页面的显示比例设为“500%”。这时在“胡”字的内部会出现“胡万进印”四个字。类似问题在实际测试中如果不使用穷举测试是很难发现的，而如果在软件投入市场时才发现则修复代价会非常高。这就会产生一个矛盾: 软件测试员不能做到完全的测试，不完全测试又不能证明软件的百分之百可靠。那么如何在这两者的矛盾中找到一个相对的平衡点呢？
如图11所示的最优测试量示意图可以观察到，当软件缺陷降低到某一数值后，随着测试量的不断上升软件缺陷并没有明显地下降。这是软件测试工作中需要注意的重要问题。如何把数据量巨大的软件测试减少到可以控制的范围，如何针对风险做出最明智的选择是软件测试人员必须能够把握的关键问题。
图11的最优测试量示意图说明了发现软件缺陷数量和测试量之间的关系，随着测试量的增加，测试成本将呈几何数级上升，而软件缺陷降低到某一数值之后将没有明显的变化，最优测量值就是这两条曲线的交点。
本书详尽地介绍了软件测试的各个方面从测试概念、测试模型、测试过程、测试阶段等各个不同的视角来探讨软件测试的重要性，重点讲解了软件测试的各种方法和技术，并将它们应用在软件测试框架的不同阶段，满足不同的应用系统测试的需求。
目录
第1章软件测试概述1
1.1软件测试产生的背景2
1.2软件测试的定义3
1.3软件测试的复杂性与经济性分析4
1.4软件缺陷6
1.5软件测试人员应具备的素质8
本章小结9
练习题10
第2章软件测试基础11
2.1软件测试的目的12
2.2软件测试的原则13
2.3软件测试的分类14
2.4常见的一些软件测试16
2.5软件测试过程模型17
本章小结20
练习题20
第3章软件测试过程与方法22
3.1单元测试23
3.2集成测试25
3.3确认测试30
3.4系统测试31
3.5验收测试32
本章小结34
练习题34
第4章软件测试策略36
4.1软件测试策略的定义37
4.2软件测试策略的重要性37
4.3软件测试策略的主要目的37
4.4软件测试策略的主要内容38
4.5软件测试策略的影响因素41
4.6软件测试策略的制定过程41
本章小结42
练习题43
第5章白盒测试44
5.1逻辑覆盖法45
5.2路径覆盖法48
本章小结52
练习题52
第6章黑盒测试54
6.1等价类划分法55
6.2边界值法57
6.3决策表法58
6.4因果图法61
6.5场景法65
本章小结69
练习题70
第7章面向对象的软件测试72
7.1面向对象的特点73
7.2面向对象的开发对软件测试的影响74
7.3面向对象的软件测试的基本概念75
7.4面向对象的软件测试的内容76
7.5面向对象的测试模型及方法78
7.6面向对象测试工具JUnit87
本章小结88
练习题89
第8章缺陷跟踪管理90
8.1Bug的影响91
8.1.1精神的摧残91
8.1.2形象的损失91
8.1.3财富的流失91
8.2Bug的产生92
8.2.1交流的误解92
8.2.2软件的复杂性、程序员的错误92
8.2.3需求变化92
8.2.4时间压力92
8.2.5文档贫乏93
8.2.6软件开发工具93
8.3Bug如何穿透测试93
8.3.1代价太大93
8.3.2市场决策93
8.3.3时间紧迫93
8.3.4现场证据94
8.3.5过于自信94
8.3.6模糊提交和测试环境94
8.4Bug的种类94
8.4.1需求阶段的Bug——三种需求94
8.4.2分析、设计阶段的Bug——忽略设计94
8.4.3实现阶段的Bug——遗漏的功能95
8.4.4配置阶段的Bug95
8.4.5短视将来的Bug95
8.4.6静态文档的Bug95
8.5Bug的生命周期96
8.6Bug的关键字96
8.6.1Bug的流转状态关键字96
8.6.2Bug的解决关键字97
8.6.3Bug的严重等级关键字97
8.6.4Bug处理的优先等级关键字97
8.7Bug的管理98
8.8缺陷管理工具JIRA99
8.8.1JIRA介绍99
8.8.2JIRA安装100
8.8.3JIRA用户使用101
8.8.4JIRA后台使用102
本章小结105
练习题105
第9章项目质量保证107
9.1软件质量保证的理论探索108
9.1.1软件质量保证过程的认识108
9.1.2生产线的隐喻109
9.1.3SQA和其他工作的组合109
9.1.4QA和QC109
9.1.5QA和SEPG110
9.1.6QA和组织级的监督管理110
9.2软件质量保证的工作内容和工作方法111
9.2.1计划111
9.2.2审计/证实111
9.2.3问题跟踪111
9.3软件质量保证的素质112
9.4软件质量保证的活动内容112
9.5软件质量保证正式的技术评审113
9.6软件质量保证统计114
9.7质量保证与检验114
9.8软件质量保证检验项目的内容115
9.9ISO 9000软件质量标准的了解116
本章小结116
练习题117
第10章项目质量控制118
10.1项目质量控制的定义、目的和必要性119
10.2质量控制的内容及过程120
10.3质量控制的方法、技术和工具122
10.4质量控制的依据及成果123
本章小结131
练习题131
第11章Web网站测试133
11.1Web网站功能测试134
11.2性能测试的种类136
11.3安全性测试136
11.4可用性/可靠性测试137
11.5配置和兼容性测试138
11.6数据库测试139
11.7Web测试用例考虑的因素139
本章小结142
练习题143
第12章自动化测试144
12.1什么是软件自动化测试145
12.2软件自动化的使用范围146
12.3软件自动化工具分类146
12.3.1白盒测试工具146
12.3.2黑盒测试工具147
12.3.3测试设计与开发工具147
12.3.4测试执行和评估工具148
12.3.5测试管理工具148
12.3.6常用测试工具148
12.3.7其他公司测试工具150
12.3.8一些开源测试工具150
12.4Quality Center的基本介绍152
12.5QTP的基本介绍153
12.5.1启动QTP153
12.5.2插件加载设置与管理153
12.5.3创建一个空的测试项目153
12.5.4录制和测试运行设置154
12.5.5指定需要录制的应用程序155
12.5.6使用QTP编写第一个自动化测试脚本156
12.6LoadRunner的基本介绍158
12.6.1LoadRunner 常用术语158
12.6.2LoadRunner工作流程159
12.6.3Virtual User Generator(VuGen)简介160
12.6.4设置运行时行为161
12.6.5查看脚本的运行情况164
12.6.6查看测试结果165
本章小结166
练习题166
第13章软件测试文档168
13.1测试文档169
13.1.1测试文档的定义169
13.1.2测试文档的内容169
13.1.3软件生命周期各阶段的测试任务与可交付的文档170
13.2测试计划172
13.2.1测试计划的定义172
13.2.2测试计划的目的和作用173
13.2.3测试计划书173
13.2.4测试计划的内容173
13.2.5软件测试计划的制订174
13.3测试用例设计176
13.3.1测试用例176
13.3.2测试用例文档应包含以下内容176
13.4测试总结报告177
13.4.1测试结果统计表177
13.4.2测试问题表和问题统计表178
13.4.3测试进度表178
13.4.4测试总结表178
本章小结179
练习题179
第14章软件质量保障与软件测试181
14.1软件质量的定义182
14.2软件质量的模型182
14.2.1McCall 质量模型182
14.2.2Bohm 质量模型182
14.2.3ISO的软件质量模型182
14.3软件质量要素184
14.4软件质量保证（SQA）185
14.4.1基本目标185
14.4.2品质保证人员（QA）186
14.4.3QA与QC的区别186
14.4.4SQA活动187
14.5软件质量保证与软件测试187
本章小结188
练习题188
参考文献190软件测试技术目录
序言
近年来，计算机技术突飞猛进，软件的开发与使用越来越普遍、越来越高端，从早期的数值计算，到现在云计算、互联网+、电子商务、大数据等，涉及各个领域。软件中存在的问题或安全漏洞也频繁出现，显然，软件的质量保证越来越受到重视。而目前我国软件测试行业的从业人员相当缺乏，并且在IT行业中重视程度不够。
本书从软件测试的基础开始，将软件测试的测试流程与软件开发的流程联系起来作为主线，介绍软件测试的过程、测试计划、测试用例设计与实施、测试缺陷跟踪以及测试分析等。在测试的不同阶段开始单元测试、集成测试、系统测试、验收测试等；在不同阶段选择不同的测试方法和技术，如静态测试、白盒测试、黑盒测试等，并分别介绍怎样使用自动化工具对相关软件进行测试，主要介绍了功能自动化工具QPT以及性能测试工具LoadRunner的基本使用方法，还以案例穿插介绍了缺陷管理工具JIRA。
本书的特点如下。
（1）软件测试知识点全面。本书包括基本的软件测试理论知识，也包括当今业界常用的测试方法。
（2） 具有科学、系统的工程观点和方法。全书以软件工程开发系统的科学思想，将软件测试贯穿于整个软件生命周期，介绍了软件测试在软件生命周期中各个阶段采用的方法和应用。
（3）理论联系实际。本书各个章节都提供了大量的应用实例以说明各个测试知识点的运用，并且每章后附有习题和练习。
本书由何春梅、唐滔任主编，苟英、陈怡然、谭凤任副主编。何春梅主持了全书的编写以及审稿工作，苟英负责全书的总体框架设计和统稿工作。第1～4章由苟英编写，第5和6章由何春梅编写，第7章由谭凤编写，第8～11章由唐滔编写，第12～14章由陈怡然编写。本书在编写过程中得到了重庆工程学院软件学院师生的大力支持，在此表示感谢！
由于作者水平有限，书中疏漏之处在所难免，欢迎广大读者提出宝贵意见。
编者
2017年5月软件测试技术
文摘
第1章软件测试概述
本章目标
了解软件测试的背景
掌握软件缺陷的定义及缺陷跟踪流程
熟悉软件测试的复杂性与经济性分析
掌握软件测试的定义
熟悉软件测试人员应具备的素质本章单词
test case: bug:
static testing:walkthrough:软件测试是软件开发过程中的重要阶段，它是伴随着软件的产生而产生的。软件测试是保证软件质量、提高软件可靠性的重要途径。软件测试的质量与测试人员的技能、经验以及对被测软件的理解密切相关。在最初的软件开发过程中，软件规模小而简单，开发过程随意而无序。软件测试的含义也比较狭窄，仅仅等同于调试，往往由开发人员兼任测试工作，目的是为了纠正软件中存在的已知问题。对测试的投入少，测试介入晚，往往是等到代码成形，产品完成后才进行测试。随着时间的推移，软件测试的内涵在不断丰富，人们对软件测试的认识在不断深入。要完整地理解软件测试，就要从不同角度去审视。
1.1软件测试产生的背景
早期的软件开发过程中，开发人员将测试等同于“调试”，目的是纠正软件中已知的故障，常常由开发人员自己完成这部分的工作。对测试的投入极少，测试介入也晚，常常是等到形成代码，产品已经基本完成时才进行测试。
直到1957年，软件测试才开始与调试区别开来，作为一种发现软件缺陷的活动。由于一直存在着“为了让我们看到产品在工作，就得将测试工作往后推一点”的思想，潜意识里对测试的目的就理解为“使自己确信产品能工作”。测试活动始终晚于开发的活动，测试通常被作为软件生命周期中最后一项活动而进行。当时也缺乏有效的测试方法，主要依靠错误推测(Error Guessing)寻找软件中的缺陷。因此，大量软件交付后，仍存在很多问题，软件产品的质量无法保证。
20世纪70年代，这个阶段开发的软件仍然不复杂，但人们已开始思考软件开发流程的问题，尽管对“软件测试”的真正含义还缺乏共识，但这一词条已经频繁出现。一些软件测试的探索者们建议在软件生命周期的开始阶段就根据需求制订测试计划，这时也涌现出一批软件测试的宗师，Bill Hetzel 博士和Glenford J. Myers就是其中的领导者。
20世纪80年代初期，软件和IT行业进入了大发展时期，软件趋向大型化、高复杂度，所以软件的质量越来越重要。这个时候，一些软件测试的基础理论和实用技术开始形成，并且人们开始为软件开发设计了各种流程和管理方法，软件开发的方式也逐渐由混乱无序的开发过程过渡到结构化的开发过程，以结构化分析与设计、结构化评审、结构化程序设计以及结构化测试为特征。人们还将“质量”的概念融入其中，软件测试定义发生了改变，测试不单纯是一个发现错误的过程，而且将测试作为软件质量保证（SQA）的主要职能。此时软件开发人员和测试人员开始坐在一起探讨软件工程和测试问题。软件测试已有了行业标准（IEEE/ANSI），需要运用专门的方法和手段。
在竞争激烈的今天，无论是软件的开发商还是软件的使用者，都生存在竞争环境中。软件开发商为了占有市场，必须把产品质量作为企业的重要目标之一，以免在竞争中被淘汰出局。用户为了保证自己的业务顺利完成，当然希望选用优质的软件。质量不佳的产品不仅会使开发上的维护费用和用户的使用成本增加，还可能产生其他的问题，造成公司信誉下降。一些关键的应用领域如果质量有问题，还可能造成灾难性的后果。现在人们已经逐步认识到软件中存在的错误导致了软件开发在成本、进度和质量上的失控。由于软件是由人来完成的，所以它不可能十全十美，虽然不可能完全杜绝软件中的错误，但是可以用软件测试等手段使程序中的错误数量尽可能少，密度尽可能小。
国际上，软件测试（软件质量控制）是一件非常重要的工作，测试也作为一个非常独立的职位。IBM、微软等开发大型系统软件公司，很多重要项目的开发测试人员的比例能够达到1∶2甚至1∶4。在软件测试技术方面，自动化测试系统（ATS,automatic test system）正朝着通用化、标准化、网络化和智能化的方向迈进。20世纪90年代中期以来，自动测试系统开发研制的指导思想发生了重大变化，以综合通用的ATS代替某一系列，采用共同的硬件及软件平台实现资源共享的思想受到高度重视。其主要思路是: 采用共同的测试策略，从设计过程开始，通过“增值开发”的方式使后一阶段测试设备的研制能利用前一阶段的开发成果；TPS要能够移植，软件模块可以重用；使用商业通用标准、成熟的仪器设备，缩短研发时间，降低开发成本并且易于升级和扩展。
国内软件测试的现状主要表现在以下方面。
（1） 软件测试的地位还不高，在很多公司还是一种可有可无的地位，大多只停留在软件单元测试、集成测试和功能测试上。
（2） 软件测试标准化和规范化不够。
（3） 软件测试从业人员的数量同实际需求有不小差距，国内软件企业中开发人员与测试人员数量一般为5∶1，国外一般为2∶1或1∶1，而最近有资料显示微软已把此比例调整为1∶2。
（4） 国内缺乏完全商业化的操作机构，一般只是政府部门的下属机构在做一些产品的验收测试工作，实质意义不大，软件测试产业化还有待开发和深掘。
因此，我国的软件测试行业较欧美国家的差距还比较大。通过研究发现，造成这种情况的原因主要有以下几点:
(1) 国内软件产业本身不强大，软件质量较低；
(2) 软件管理者与用户对软件质量意识有待加强；
(3) 软件管理者对软件测试的认识和重视程度不够；
(4) 软件行业质量监督体系不够好；
(5) 软件从业人员的素质不够高；
(6) 软件测试行业处于起步阶段，经济效益短期内不明显。
1.2软件测试的定义
1983年IEEE提出的软件工程术语中给软件测试下的定义是: 使用人工或自动的手段来运行或测定某个软件系统的过程，其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别。这个定义明确指出: 软件测试的目的是为了检验软件系统是否满足需求。它再也不是一个一次性的，而且只是开发后期的活动，而是与整个开发流程融合成一体。
扩展定义: 软件测试就是在软件投入运行前，对软件需求分析、设计规格说明和编码的最终复审，是软件质量保证的关键步骤。
软件测试是根据软件开发各阶段的规格说明和程序的内部结构而精心设计一批测试用例（包括输入数据与预期输出结果），并利用这些测试用例运行软件，以发现软件错误的过程。广义的软件测试是由确认、验证、测试3个方面组成。
(1) 确认: 评估将要开发的软件产品是否正确无误、可行和有价值的。确认意味着确保一个待开发软件是正确无误的，是对软件开发构想的检测，主要体现在计划阶段、需求分析阶段，也会出现在测试阶段。
(2) 验证: 检测软件开发的每个阶段、每个步骤结果是否正确无误，是否与软件开发各阶段的要求或期望的结果相一致。验证意味着确保软件会正确无误地实现软件的需求，开发过程是沿着正确的方向进行的。主要体现在设计阶段、编码阶段。
(3) 测试: 与狭隘的测试概念统一。主要体现在编码阶段和测试阶段。
确认、验证与测试是相辅相成的。确认产生验证和测试的标准，验证和测试帮助完成确认。
1.3软件测试的复杂性与经济性分析
人们在对软件工程开发的常规认识中，认为开发程序是一个复杂而困难的过程，需要花费大量的人力、物力和时间，而测试一个程序则比较容易，不需要花费太多的精力。这其实是人们对软件工程开发过程理解上的一个误区。在实际的软件开发过程中，作为现代软件开发工业一个非常重要的组成部分，软件测试正扮演着越来越重要的角色。随着软件规模的不断扩大，如何在有限的条件下对被开发软件进行有效的测试正成为软件工程中一个非常关键的课题。
设计测试用例是一项细致并且需要具备高度技巧的工作，稍有不慎就会顾此失彼，发生不应有的疏漏。下面分析了容易出现问题的根源。
(1) 完全测试是不现实的
在实际的软件测试工作中，不论采用什么方法，由于软件测试工作量极其巨大，都不可能进行完全彻底的测试。所谓彻底测试，就是让被测程序在一切可能的输入情况下全部执行一遍。通常也称这种测试为“穷举测试”。
穷举测试会引起以下几种问题:
① 输入量太大；
② 输出结果太多；
③ 软件执行路径太多；
④ 说明书存在主观性。
E.W.Dijkstra的一句名言对测试的不彻底性做了很好的注解: “程序测试只能证明错误的存在，但不能证明错误的不存在。”由于穷举测试工作量太大，实践上行不通，这就注定了一切实际测试都是不彻底的，也就不能够保证被测试程序在理论上不存在遗留的错误。
(2) 软件测试是有风险的
穷举测试的不可行性使得大多数软件在进行测试的时候只能采取非穷举测试，这又意味着一种冒险。比如在使用Microsoft Office工具中的Word时，可以做这样的一个测试: ①新建一个Word文档； ②在文档中输入汉字“胡”； ③设置其字体属性为“隶书”，字号为初号，效果为“空心”； ④将页面的显示比例设为“500%”。这时在“胡”字的内部会出现“胡万进印”四个字。类似问题在实际测试中如果不使用穷举测试是很难发现的，而如果在软件投入市场时才发现则修复代价会非常高。这就会产生一个矛盾: 软件测试员不能做到完全的测试，不完全测试又不能证明软件的百分之百可靠。那么如何在这两者的矛盾中找到一个相对的平衡点呢？
如图11所示的最优测试量示意图可以观察到，当软件缺陷降低到某一数值后，随着测试量的不断上升软件缺陷并没有明显地下降。这是软件测试工作中需要注意的重要问题。如何把数据量巨大的软件测试减少到可以控制的范围，如何针对风险做出最明智的选择是软件测试人员必须能够把握的关键问题。
图11的最优测试量示意图说明了发现软件缺陷数量和测试量之间的关系，随着测试量的增加，测试成本将呈几何数级上升，而软件缺陷降低到某一数值之后将没有明显的变化，最优测量值就是这两条曲线的交点。
| ISBN | 9787302473633 |
|---|---|
| 出版社 | 清华大学出版社 |
| 作者 | 何春梅 |
| 尺寸 | 16 |