测试的基本理论
-
掌握软件测试的基本流程
-
知道软件测试的V和W模型的优缺点
-
掌握软件测试的分类
软件测试的发展
1960年代是调试时期(测试即调试)
1960年 - 1978年 论证时期(软件测试是验证软件是正确的)和 1979年 - 1982年 破坏性测试时期(为了发现错误而执行程序的过程)
1983年起,软件测试已有了行业标准(IEEE829),它需要运用专门的方法和手段,需要专门人才和专家来承担。
1990年起软件迅速发展,测试行业也更着发生了巨大变化,开始引入专业测试工具
什么是软件测试
在规定条件下对程序进行操作,从而发现错误,对软件质量进行评估的一个过程.
软件测试的目的
是想以最少的人力,物力和时间找出软件中潜在的各种错误与缺陷,通过修正各种错误和缺陷提高软件质量,回避软件发布后由于潜在的软件缺陷和错误造成的隐患以及带来的商业风险。
注意:不要和软件测试的定义混淆
软件测试的定义
使用人工或自动手段来运行或测试摸个系统的过程,其目的在于检验它是否满足规定的需求或是弄清预期结果和实际结果之间的差别.
软件开发模型
软件开发模型(Software Development Model)是指软件开发全部过程、活动和任务的结构框架。软件开发包括需求、设计、编码和测试等阶段,有时也包括维护阶段。 软件开发模型能清晰、直观地表达软件开发全过程,明确规定了要完成的主要活动和任务,用来作为软件项目工作的基础。对于不同的软件系统,可以采用不同的开发方法、使用不同的程序设计语言以及各种不同技能的人员参与工作、运用不同的管理方法和手段等,以及允许采用不同的软件工具和不同的软件工程环境。
软件开发过程模型是软件开发人员在公司里工作的过程.
常见的软件开发过程模型
- 瀑布模型
- 快速原型模型
- 增量模型
- 螺旋模型
瀑布模型
1970年温斯顿·罗伊斯(Winston Royce)提出了著名的“瀑布模型”,直到80年代早期,它一直是唯一被广泛采用的软件开发模型。
瀑布模型将软件生命周期划分为制定计划、需求分析、系统设计、程序编写、软件测试和运行维护等六个基本活动,并且规定了它们自上而下、相互衔接的固定次序,如同瀑布流水,逐级下落
核心思想
在瀑布模型中,软件开发的各项活动严格按照线性方式进行,当前活动接受上一项活动的工作结果,实施完成所需的工作内容。当前活动的工作结果需要进行验证,如果验证通过,则该结果作为下一项活动的输入,继续进行下一项活动,否则返回修改。
地位
瀑布模型是最早出现的软件开发模型, 在软件工程中占有重要的地位,它提供了软件开发的基本框架.
优缺点
优点
为项目提供了按阶段划分的检查点,软件开发的每个阶段都很清晰明了
2. 当前阶段完成后,只要去关注后续阶段
3. 可在迭代模型中每轮迭代很类似于一个小的瀑布模型
4. 它提供了一个模版,这个模版使得分析、设计、编码、测试可以在改模版下有一个共同的指导
缺点
- 各个阶段的划分完全固定,阶段之间产生大量的文档,极大地增加了工作量
- 由于开发模型是线性的,用户只有等到整个过程的末期才能见到开发成果,从而增加了开发风险
- 突出缺点是不适应用户需求的变化
- 软件的实际情况必须到项目开发的后期客户才能看到,这要求客户有足够的耐心
使用范围
- 用户的需求非常清楚全面,且在开发过程中没有或很少变化;
- 开发工作对用户参与的要求很低。
快速原型模型
快速原型模型的第一步是建造一个快速原型,实现客户或未来的用户与系统的交互,用户或客户对原型进行评价,进一步细化待开发软件的需求。通过逐步调整原型使其满足客户的要求,开发人员可以确定客户的真正需求是什么;第二步则在第一步的基础上开发客户满意的软件产品。
核心思想
快速原型是利用原型辅助软件开发的一种新思想。经过简单快速分析,快速实现一个原型,用户与开发者在试用原型过程中加强通信与反馈,通过反复评价和改进原型,减少误解,弥补漏洞,适应变化,最终提高软件质量。
优缺点
优点:
克服瀑布模型的缺点,适应需求的变化,能够开发出更加让用户更加满意的需求
缺点:
- 所选用的开发技术和工具不一定符合主流的发展;
- 快速建立起来的系统结构加上连续的修改可能会导致产品质量低下。
- 使用这个模型的前提是要有一个展示性的产品原型,因此在一定程度上可能会限制开发人员的创新。
使用范围
-
不适合大型项目的研发
- 对所开发的领域比较熟悉而且有快速的原型开发工具
增量模型
介绍
增量模型又称为渐增模型,是把待开发的软件系统模块化,将每个模块作为一个增量组件,从而分批次地分析、设计、编码和测试这些增量组件。运用增量模型的软件开发过程是递增式的过程。相对于瀑布模型而言,采用增量模型进行开发,开发人员不需要一次性地把整个软件产品提交给用户,而是可以分批次进行提交。
基本思想
增量模型在各个阶段并不交付一个可运行的完整产品,而是交付满足客户需求的一个子集的可运行产品。整个产品被分解成若干个构件,开发人员逐个构件地交付产品,这样做的好处是软件开发可以较好地适应变化,客户可以不断地看到所开发的软件,从而降低开发风险。
优缺点
优点
- 将待开发的软件系统模块化,可以分批次地提交软件产品,使用户可以及时了解软件项目的进展
- 以组件为单位进行开发降低了软件开发的风险。一个开发周期内的错误不会影响到整个软件系统。
- 开发顺序灵活。开发人员可以对组件的实现顺序进行优先级排序,先完成需求稳定的核心组件。当组件的优先级发生变化时,还能及时地对实现顺序进行调整。
缺点
- 要求待开发的软件能给进行增量式的开发,否则会很麻烦
- 在软件开发过程中需求变化是不可避免的,增量模型的灵活性可以使其适应这种变化的能力大大优于瀑布模型和快速原型模型,但也很容易退化为边做边改模型,从而是软件过程的控制失去整体性.
使用场景*
-
进行已有产品升级或新版本开发
螺旋模型
1988年,巴利·玻姆(Barry Boehm)正式发表了软件系统开发的“螺旋模型]”,它将瀑布模型和快速原型模型结合起来,强调了其他模型所忽视的风险分析,特别适合于大型复杂的系统。
如图所示,螺旋模型沿着螺线进行若干次迭代,图中的四个象限代表了以下活动:
(1) 制定计划:确定软件目标,选定实施方案,弄清项目开发的限制条件;
(2) 风险分析:分析评估所选方案,考虑如何识别和消除风险;
(3) 实施工程:实施软件开发和验证;
(4) 客户评估:评价开发工作,提出修正建议,制定下一步计划。
螺旋模型由风险驱动,强调可选方案和约束条件从而支持软件的重用,有助于将软件质量作为特殊目标融入产品开发之中。
优缺点
优点:
- 设计灵活可以在项目各个阶段进行变更
- 风险驱动,每个项目上线前都要进行风险分析
缺点:
- 螺旋模型强调风险分析,需要相当丰富的风险评估经验和专门知识,在风险较大的项目开发中,如果未能够及时标识风险,势必造成重大损失;
- 如果执行风险分析将大大影响项目的利润,那么进行风险分析毫无意义,
使用场景
- 适合使用大规模的软件项目
测试模型
概述
软件测试和软件开发一样,都遵循软件工程原理,遵循管理学原理,所以理解好软件的开发模型会便于理解测试模型.
软件测试的一般流程:
我们发现一般的软件测试流程和软件开发的流程一样,但是这样的流程测试介入的较晚,对于前期重大的bug很难修复.所以测试的流程进行总结,总结出以下几个常用的测试模型:
- V模型
- W(双V)模型
- H模型
V模型
介绍
V模型和瀑布模型有一些共同的特性,V模型中的过程从左到右,描述了基本的开发 过程和测试行为。
单元测试:是模块测试,验证软件的基本组成单位的正确性,是白盒测试
集成测试:是模块间的测试,测试接口(软件各模块之间的接口和软件与硬件之间的接口)是否正确,是灰盒测试(白盒和黑盒结合)
系统测试:系统测试包括:冒烟测试 系统测试 回归测试
- 冒烟测试:主干流程测试,确认软件的基本功能正常,可以进行后续的测试工作
- 系统测试:是检测系统的功能、质量、性能能否满足系统的要求,包括功能、性能、界面、可靠性、兼容性等等,是黑盒测试
- 回归测试:修改了旧代码之后重新进行测试,确认修改后的代码没有引入新的错误或导致其他代码产生新的错误
验收测试:是确保软件的实现能否满足用户的需求或合同的要求
优缺点
优点:
- 每一个阶段都清晰明了、便于控制开发的每一个过程
- 既包含单元测试又饱含系统测试
缺点:
- 测试介入的较晚,对于前期的一些缺陷无从发现和修改
- 测试和开发串行
W模型
介绍
V模型的局限性在于没有明确地说明早期的测试,无法体现“尽早地和不断地进行软件测试” 的原则。在V模型中增加软件各开发阶段应同步进行的测试,演化为W 模型(如下图)。在模型中不难看出,开发是“V”,测试是与此并行的“V”。
W模型是V模型的发展,强调的是测试伴随着整个软件开发周期,而且测试的对象不仅仅是程序,需求、功能和设计同样要测试。测试与开发是同步进行的,从而有利于尽早地发现问题。
优缺点
优点
- 测试伴随软件的整个生命周期,例如,在需求分析结束后就可以进行需求分析测试、
- 测试于开发是并行独立进行
缺点
- 对需求和测试技术要求高
- 适用于大中型企业
H模型
简介
H模型中, 软件测试过程活动完全独立,贯穿于整个产品的周期,与其他流程并发地进行,某个测试点准备就绪时,就可以从测试准备阶段进行到测试执行阶段。软件测试可以尽早的进行,并且可以根据被测物的不同而分层次进行。
优缺点
优点:
-
开发的H模型揭示了软件测试除测试执行外,还有很多工作;
-
软件测试完全独立,贯穿整个生命周期,且与其他流程并发进行;
-
软件测试活动可以尽早准备、尽早执行,具有很强的灵活性;
缺点:
-
管理型要求高:由于模型很灵活,必须要定义清晰的规则和管理制度,否则测试过程将非常难以管理和控制;
-
技能要求高:H模型要求能够很好的定义每个迭代的规模,不能太大也不能太小;
-
测试就绪点分析困难:测试很多时候,你并不知道测试准备到什么时候是合适的,就绪点在哪里,就绪点的标准是什么,这就对后续的测试执行的启动带来很大困难;
小结
在实际工作中应灵活的运用各种模型的优点.
V模型: 强调了在整个软件项目开发中需要经历的若干个测试级别,并与每一个开发级别对应;忽略了测试的对象不应该仅仅包括程序,没有明确指出对需求、设计的测试
W模型: 补充了V模型中忽略的内容,强调了测试计划等工作的先行和对系统需求和系统设计的测试;与V模型相同,没有对软件测试的流程进行说明
H模型: 强调测试是独立的,只要测试准备完成,就可以执行测试
软件测试分类
从上图我们发现软件测试根据不同的分类条件会有不同的结果.
按照阶段进行划分
1.1 单元测试(Unit Testing)
单元测试是对软件组成单元进行测试。其目的是检验软件基本组成单位的正确性。测试的对象是软件设计的最小单位:模块。
- 测试阶段:编码后
- 测试对象:最小模块
- 测试人员:白盒测试工程师或开发工程师
- 测试依据:代码和注释+详细设计文档
- 测试方法:白盒测试
- 测试内容:模块接口测试、局部数据结构测试、路径测试、错误处理测试、边界测试
1.2 集成测试(Integration Testing)
集成测试也称联合测试、组装测试,将程序模块采用适当的集成策略组装起来,对系统的接口及集成后的功能进行正确性检测的测试工作。主要目的是检查软件单位之间的接口是否正确。
- 测试阶段:一般单元测试之后进行
- 测试对象:模块间的接口
- 测试人员:白盒测试工程师或开发工程师
- 测试依据:单元测试的模块+概要设计文档
- 测试方法:黑盒测试与白盒测试相结合
- 测试内容:模块之间数据传输、模块之间功能冲突、模块组装功能正确性、全局数据结构、单模块缺陷对系统的影响
补充说明: 单元测试是一个模块内部的测试,集成测试是在模块之间进行测试(至少两个)
1.3 系统测试(System Testing)
将软件系统看成是一个系统的测试。包括对功能、性能以及软件所运行的软硬件环境进行测试。时间大部分在系统测试执行阶段,包括回归测试和冒烟测试
- 测试阶段:集成测试通过之后
- 测试对象:整个系统(软、硬件)
- 测试人员:黑盒测试工程师
- 测试依据:需求规格说明文档
- 测试方法:黑盒测试
- 测试内容:功能、界面、可靠性、易用性、性能、兼容性、安全性等