软件评测师教程(第一版)笔记
第一篇 理论篇
第 1 章软件测试概论
1.1 概述
早期的测试等同于“调试”。
测试是为发现错误而执行的一个程序或者系统的过程。
测试是以评价一个程序或者系统属性为目标的任何一种活动,测试是对软件质量的度量。
1.3 软件测试与软件项目的关系
软件测试的目的是为了发现软件中存在的错误,但是,其根本目的是为了提高软件质量,降低软件项
目的风险。软件的质量风险表现在两个方面,一种是内部风险,一种是外部风险。内部风险是在即将销售
的时候发现有重大的错误,从而延迟发布日期,失去市场机会;外部风险是用户发现了不能容忍的错误,
引起索赔,法律纠纷,以及用于客户支持的费用甚至失去客户的风险。
软件测试只能证明软件存在错误,而不能证明软件没有错误。软件公司对软件项目的期望是在预计的
时间、合理的预算下,提交一个可以交付的产品,测试的目的就是把软件的错误控制在一个可以进行产品
交付/发布的程度上,可以交付/发布的产品并不是没有错误的产品,因此软件测试不可能无休止地进行下
去,而是要把错误控制在一个合理的范围之内,因为软件测试也是需要花费巨大成本的。
1.5 第三方测试
第三方测试是指独立于软件公司自身测试的测试。第三方测试机构的测试除了发现软件问题之外,还
有对软件进行科学、公正的评价的职能,这就要求第三方测试机构要保持公正、廉洁、客观、科学、独立
的态度。
第 2 章软件测试基础
1、什么是软件测试
测试(test)被当作一个常规的检验产品质量的生产活动。测试的含义为“为检验产品是否满足需求为
目标”。
“软件测试”的经典定义是在规定条件下对程序进行操作,以发现错误,对软件质量进行评估。
软件是由文档、数据以及程序组成的,那么软件测试就应该是对软件形成过程的文档、数据以及程序进行
的测试,而不仅仅是对程序进行的测试。
2、什么是软件质量
ISO9126 中定义的“软件质量”是:软件满足规定或潜在用户需求特性的总和。
ISO14598 中“软件质量”定义是:软件特性的总和,软件满足规定或潜在用户需求的能力。
ISO9126 定义的软件质量包括“内部质量”、“外部质量”、“使用质量”三部分。也就是说,“软件满足规定
或潜在用户需求的能力”要从软件在内部、外部和使用中的表现来衡量。
3、软件测试是在规定条件下对程序进行操作,以发现错误,对软件质量进行评估。
4、软件质量定义是:软件特性的总和,软件满足规定或潜在用户需求的能力。
软件质量包括:内部质量、外部质量、使用质量三个部分。
5、软件测试与质量保证的区别:
质量保证(QA)质量保证的重要工作通过预防、检查与改进来保证软件质量。QA 采用“全面质量管理”
和“过程改进”的原理开展质量保证工作。关注软件质量的检查与测量。
软件测试也与软件开发过程紧密相关,关心的不是过程的活动,而是对过程的产物以及开发出的软件
进行剖析。测试员要“执行”软件,对过程中的产物开发文档和源代码进行走查,运行软件,以找出问题,
报告质量。对测试中发现的问题的分析、追踪和回归测试。软件测试是保证软件质量的一个重要环节。
6、软件测试目的
测试目的三个观点:
测试是程序的执行过程,目的在于发现错误;
一个好的测试用例在于能发现至今未发现的错误;
一个成功的测试是发现了至今未发现的错误的测试;
测试的目的,是想以最少的人力、物力和时间找出软件潜在的各种错误和缺陷,通过修正各种错误和缺陷
提高软件质量,回避软件发布后由于潜在的软件缺陷和错误造居的隐患所带来的商业风险。
测试是对软件质量的度量与评价,以验证软件的质量满足用户的需求的程度,为用户选择与接受软件提供
有力的依据。
7、软件测试原则
所有的软件测试都应追溯到用户需求。
应当把“尽早地和不断地进行软件测试”作为软件测试者的座左铭。
完全测试是不可能的,测试需要终止。
在有限的时间和资源条件下,软件趋于完美,是不可能的。主要有三个原因:
软件入量太大;
输出结果太多;
路径组合太多。
测试无法显示软件潜在的缺陷
充分注意测试中的群集现象。
程序员应避免检查自己的程序。
尽量避免测试的随意性。(应该从工程的角度去理解软件测试,它是有组织、有计划、步骤的活动。)
8、软件测试对象
根据软件定义,软件包括程序、数据和文档,所以软件测试并不仅仅是程序测试。
在软件编码结束后,对编写的每一个程序模块进行测试,称为模块测试或单元测试。
在模块集成后,对集成在一起模块组件,有时称为部件,进行测试,称为集成测试。
在集成测试后,需要检测与证实软件是否满足软件需求说明书中规定的要求,称为确认测试。
将整个程序模块集成为软件系统,安装在运行环境下,对硬件、网络、操作系统及支撑平台构成的整体系
统进行测试,称为系统测试。
软件错误中,属于需求分析和软件设计的错误约为 64%,属于程序编写的错误仅占 36%。
验证(verification)是保证软件正确实现特定功能的一系列活动和过程,目的是保证软件生命周期中
的每一个阶段的成果满足上一个阶段所设定的目标。
确认(validation)是保证软件满足用户需求的一系列的活动和过程,目的是在软件开发完成后保证软
件与用户需求相符合。
验证与确认都属于软件测试,它包括对软件分析、设计以及程序的验证和确认。
需求分析、概要设计、详细设计以及程序编码等各阶段所得到的文档,包括需求规格说明、概要设计
规格说明、详细设计规格说明以及源程序,都应成为“软件测试”的对象。在软件编码结束后,对编写的
每一个程序模块进行测试,称为“模块测试”或“单元测试”;在模块集成后,对集成在一起的模块组件,
有时也可称为“部件”,进行测试,称为“集成测试”;在集成测试后,需要检测与证实软件是否满足软件
需求说明书中规定的要求,称为“确认测试”。将整个程序模块集成为软件系统,安装在运行环境下,对
硬件、网络、操作系统及支撑平台构成的整体系统进行测试,称为“系统测试”。
测试过程按 4 个步骤进行,即单元测试、集成(组装)测试、确认测试和系统测试。
9、软件测试分类
按照开发阶段划分软件测试可分为:单元测试、集成测试、系统测试、确认测试和验收测试。
单元测试:单元测试又称模块测试,是针对软件设计的最小单位——程序模块进行正确性检验的测试
工作。其目的在于检查每个程序单元能否正确实现详细设计说明中的模块功能、性能、接口和设计约束等
要求,发现各模块内部可能存在的各种错误。单元测试需要从程序的内部结构出发设计测试用例。多个模
块可以平行地独立进行单元测试。
集成测试:也叫组装测试。通常在单元测试的基础上,将所有的程序模块进行有序的、递增的测试。
集成测试是检验程序单元或部件的接口关系,逐步集成为符合概要设计要求的程序部件或整个系统。
确认测试:就是通过检验和提供客观证据,证实软件是否满足特定预期用途的要求。确认测试是检测
与证实软件是否满足软件需求说明书中规定的要求。
系统测试:它是为验证和确认系统是否达到其原始目标,而对集成的硬件和软件系统进行的测试。系
统测试是在真实或模拟系统运行的环境下,检查完整的程序系统能否(包括硬件、外设、网络和系统软件、
支持平台等)正确配置、连接,并满足用户需求。
验收测试:按照项目任务书或合同、供需双方约定的验收依据文档进行的对整个系统的测试与评审,
决定是否接收或拒收系统。
按照开发阶段划分
单元测试。
单元测试又称模块测试,是针对程序模块进行正确性检验的测试工作。
集成测试
集成测试也叫组装测试。通常在单元测试的基础上,将所有的程序模块进行有序的、递增的测试。集成测
试是检验程序或部件的接口关系,逐步集成为符合概要设计要求的程序部件或整个系统。
冒烟测试也叫验证测试、提交测试。
确认测试
确认测试是通过检验和提供客观证据,证实软件是否满足特定预期用途的需求。确认测试是检测与证实软
件是否满足软件需求说明书中规定的要求。
系统测试
系统测试是为验证和确认系统是否达到其原始目标,而对集成的硬件和软件系统进行的测试。系统测试是
在真实或模拟系统运行的环境下,检查完整的程序系统能否和系统(包括硬件、外设、网络和系统软件、
支持平台等)正确配置、连接、并满足用户需求。
验收测试
按照项目任务书或合同、供需双方约定的验收依据文档进行的对整个系统的测试与评审,决定是否接收或
拒收系统。
按照测试实施组织划分
按照测试实施组织划分,软件测试可分为开发方测试、用户测试(Beta 测试)、第三方测试。
(1)开发方测试
通常也叫“验证测试”或“α测试”。验证测试是在软件开发环境下,由开发者检测与证实软件的实
现是否满足软件设计说明或软件需求说明的要求。主要是指在软件开发完成以后,开发方对要提交的软件
进行全面的自我检查与验证,可以和软件的“系统测试”一并进行。
(2)用户测试
在用户的应用环境下,用户通过运行和使用软件,检测与核实软件实现是否符合自己预期的要求。用
户测试不是指用户的“验收测试”,而是指用户的使用性测试,由用户找出软件的应用过程中发现的软件
的缺陷与问题,并对使用质量进行评价。
(3)第三方测试
介于软件开发方和用户方之间的测试组织的测试。一般情况下是在模拟用户真实应用环境下,进行软
件确认测试。
按照测试技术划分
按照测试技术划分:白盒测试、黑盒测试、灰盒测试。也可划分为静态测试和动态测试。静态测试是指不
运行程序,通过人工对程序和文档进行分析与检查:静态测试技术又称静态分析技术,静态测试实际上是
对软件中的需求说明书、设计说明书、程序源代码等进行非运行的检查,静态测试包括:走查、符号执行、
需求确认等。动态测试是指通过人工或使用工具运行程序进行检查、分析程序的执行状态和程序的外部表
现。
(1)白盒测试
通过对程序内部结构的分析、检测来寻找问题。了解程序结构和处理过程,检查是否所有的结构及路
径都是正确的,检查软件内部动作是否按照设计说明的规定正常进行。
(2)黑盒测试
通过软件的外部表现来发现其缺陷和错误。黑盒测试法把测试对象看成一个黑盒子,完全不考虑程序
内部结构和处理过程。黑盒测试是在程序界面处进行测试,它只是检查程序是否按照需求规格说明书的规
定正常实现。
(3)灰盒测试
灰盒测试关注输出对于输入的正确性
静态测试
它是指不运行程序,通过人工对程序和文档进行分析与检查; 静态测试技术又称静态分析技术,静
态测试实际上是对软件中的需求说明书、设计说明书、程序源代码等进行非运行检查,
静态测试包括:走查、符号执行、需求确认等。
动态测试
它是指通过人工或使用工具运行程序进行检查、分析程序的执行状态和程序的外部表现。
白盒测试
又称结构测试。通过对程序内部结构的分析、检测来寻找问题。
黑盒测试
通过软件的外部表现来发现其缺陷和错误。它是在程序界面处进行测试,它只是检查样序是否按照需
求规格说明书的规定正常实现。
10、软件测试过程模型
V 模型
它反映了测试活动与分析和设计的关系,从左到右,描述了基本的开发过程和测试行为,非常明确地
标明了测试过程中存在的不同级别,并且清楚地描述了这些测试阶段和开发过程期间各阶段的对应关系,
如图所示,图中的箭头代表了时间方向,左边下降的是开发过程各阶段,与此相对应的是右边上升的部分,
即各测试过程的各个阶段。
V 模型指出,单元和集成测试是验证的程序设计,检测程序的执行是否满足软件设计的要求;
系统测试应当验证系统设计,检测系统功能、性能的质量特性是否达到系统设计的指标;
测试员和用户进行软件的确认测试和验收测试,追溯软件需求说明书进行测试,以确定软件的实现是否满
足用户需求或合同的要求。
V 模型存在一定的局限性,它仅仅是测试过程作为在需求分析、概要设计、详细设计及编码后的一个
阶段。需求分析阶段隐藏的问题一直到后期的验收测试才被发现。
V 模型的软件测试策略既包括低层测试又包括了高层测试,低层测试是为了源代码的正确性,高层测
试为了使整个系统满足用户的需求。
W 模型
1、W 模型建立
V 模型的局限性在于没有明确地说明早期的测试,不能体现“尽早地和不断地进行软件测试”的原则。
在 V 模型中增加软件各开发阶段应同步进行的测试,被演化为一种 W 模型,因为实际上开发是“V”,测
试也是与此相并行的“V”。基于“尽早地和不断地进行软件测试”的原则,
优点:
测试伴随着整个软件开发周期,而且测试的对象不仅仅是程序,需求、功能和设计同样要测试。
体现“尽早地和不断地进行软件测试”的原则。
在 V 模型中增加软件和开发阶段应同步进行的测试。
局限性:
软件开发和测试保持一种线性的前后关系,需要有严格的指令表示上一阶段完全结束,才可正式开始
下一个阶段。这就无法支持迭代、自发性以及变更调整。
2、W 模型应用
它强调:测试伴随着整个软件开发周期,而且测试的对象不仅仅是程序,需求、功能和设计同样要测
试。只要相应的开发活动完成,我们就可以开始执行测试,可以说,测试与开发是同步进行的,有利于尽
早地发现问题。以需求为例,需求分析一完成,我们就可以对需求进行测试,而不是等到最后才进行针对
需求的验收测试。
参与前期工作的测试者可以预先估计问题和难度,这将可以显著地减少总体测试时间,加快项目进度。
根据 W 模型的要求,一旦有文档提供,就要及时确定测试条件,以及编写测试用例。
W 模型也是有局限性。W 模型和 V 模型都把软件的开发视为需求、设计、编码等一系列串行的活动。同
样的,软件开发和测试保持一种线性的前后关系,需要有严格的指令表示上一阶段完全结束,才可正式开
始下一个阶段。这样就无法支持迭代、自发性以及变更调整。
H 模型
1、H 模型建立
它将测试活动独立出来,形成一个完全独立的流程,将测试准备活动和测试执行活动清晰地体现出来。
2、H 模型应用
软件测试不仅仅指测试的执行,还包括很多其他的活动。
软件测试是一个独立的流程,贯穿产品整个生命周期,与其他流程并发地进行。
软件测试要尽早准备,尽早执行。
软件测试是根据被测物的不同而分层次进行的。不同层次的测试活动可以是按照某个次序先后进行的,但
也可能是反复的。
在 H 模型中,软件测试模型是一个独立的流程,贯穿于整个产品周期,与其他流程并发地进行。
其他模型
1、 X 模型
该模型定位了探索性测试。
Marick 对 V 模型最主要批评是 V 模型无法引导项目全部过程。他认为一个模型必须能处理开发的所有方
面,包括交接、频繁重复的集成以及需求文档的缺乏等。
2、前置测试模型
它是一个将测试和开发紧密结合的模型,该模型提供了轻松的方式,可使你的项目加快速度。