软件测试期末复习资料
合集下载
相关主题
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
执行测试 工具配置
探索性测试
后将通过频繁的交接, 最终集成为一个可执行
测试设计
执行测试 的程序
程序片段n
黑盒测试基本概念
黑盒测试基本概念
◦ 只知道系统输入和预期输出,不需要了解程序内 部结构和内部特性的测试方法称为黑盒测试。
◦ 黑盒测试又叫功能测试,它主要关注被测软件功 能的实现,而不是其内部逻辑。
第三方测试也叫做独立测试,是指介于软件开发 者和软件用户之间的测试组织对软件进行的测试。
测试用例
从测试目的的角度来看,为达到最佳的 测试效果或高效的揭露隐藏的错误,而 精心设计并执行的少量测试数据,称之 为测试用例。
测试用例最基本由输入和预期输出组成。
软件开发过程模型
软件工程的核心就是过程,软件产品、人 员、技术通过过程关联起来。软件工程过 程能够将软件生命周期内涉及的各种要素 集成在一起,从而使软件的开发能够以一 种合理而有序的方式进行。
最优方案; ◦ 开发本次迭代可供交付的内容; ◦ 评估完成情况,规划下一个迭代过
程; ◦ 交付给下一步,开始新的迭代过程。
RUP模型
RUP吸取了已有模型的优点, 克服了瀑布模型过分强调序 列化和螺旋模型过于抽象的 不足,总结了多年来软件开 发的最佳经验:
◦ 迭代开发,提前认知风险。 ◦ 需求管理,及早达成共识。 ◦ 基于构建,搭建弹性框架。 ◦ 可视化建模,打破沟通壁垒。 ◦ 持续验证质量,降低缺陷代价。 ◦ 管理变更,有序积累资产。
◦ 与瀑布模型相比,需要更多用户/获取方的参 与。
螺旋模型-风险!
螺旋模型是另一种过程模型。在 这一模型中,开发工作是迭代进 行的,即只要完成了开发的一个 迭代过程,另一个迭代过程就开 始了。
开发人员和客户使用螺旋模型可 以完成如下工作:
◦ 确定目标、方案和约束; ◦ 识别风险和效益的可选路线,选择
软件测试的分类
按是否需要查看代码
◦ 白盒测试
输入
白盒测试是指已知软件产品 的内部工作过程,通过验证 每种内部操作是否符合设计 规格的要求来进行测试。
◦ 黑盒测试
黑盒测试是指已知软件产品 的功能设计规格,测试每个 输入 实现了的功能是否满足要求。
◦ 灰盒测试
灰盒测试是介于白盒测试和 黑盒测试之间的测试,是对 两种测试的一种折中。
敏捷开发过程模型 TDD
敏捷开发是一种以人为核心、迭代、循序 渐进的开发方法。在敏捷开发中,软件项 目的构建被切分成多个子项目,各个子项 目的成果都经过测试,具备集成和可运行 的特征。换言之,就是把一个大项目分为 多个相互联系,但也可独立运行的小项目, 并分别完成,在此过程中软件一直处于可 使用状态。
自动化测试的优缺点
软件测试的分类
按测试实施组织
◦ 开发方测试
开发方测试也叫做α测试,是指在软件开发环境 下,由开发方提供检测和提供客观证据,验证软 件是否满足规定的要求。
◦ 用户测试
用户测试是指在用户的应用环境下,由用户通过 运行和使用软件,验证软件是否满足自己预期的 需求。
◦ 第三方测试
用。 ◦ 对于规模稍大的项目,采用这种模型是很危险的,由于缺乏
预先的计划并且通常伴随着不正规的开发方式,容易导致代 码碎片,交付的产品质量也很难保证。且因为设计没有很好 的文档化,因此代码维护困难。
交付
瀑布模型
需求分析
瀑布模型是典型的软硬件开发模型,它包括需求、设计、编码、 测试、运行与维护几个阶段。在每一阶段提交以下产品:软件 需求规格说明书、系统设计说明书、实际代码和测试用例、最 终产品、产品升级等。
敏捷的最低要求应该是使得项目具备以下 基本条件:
◦ 可追溯性、可理解性、可验证量性、其他“开 发时质量要求”
测试过程模型
随着计算机的普及和计算机应用的飞速 发展,软件数量和复杂度不断增加,导 致软件开发过程越来越难以控制。
软件测试过程模型是对软件测试过程的 一种抽象,用于定义和描述软件测试的 流程和方法。软件测试过程模型的发展 伴随着人们对软件工程理解和软件测试 理解的深入和发展。
需求 构造增量1
需求 构造增量2
演化模型是显式地把增量模型扩展到需求 阶段。为了第二个构造增量,使用了第一 个构造增量来精化需求。这一精化可以有 多个来源和路径。
演化模型的长处和不足与增量模型类似。 优点有:
◦ 在需求不能予以规范时,可以使用这一演化模 型;
◦ 用户可以通过运行系统的实践,对需求进行改 进;
增量模型作为瀑布模型的一个变体,具有瀑布 模型的所有优点,此外,还有以下优点:
◦ 第一个可交付版本所需要的成本和时间较少。 ◦ 开发由增量表示的小系统所承担的风险不大。
◦ 由于很快发布了第一个版本,因此可以减少用户 需求的变更。
◦ 允许增量投资,即在项目开始时,可以仅对一个 或两个增量投资。
演化模型
是一种利用图解法分析输入的各种 组合情况,从而设计测试用例的方 法,它适合于检查程序输入条件的 各种组合情况。
26
黑盒测试方法
决策表法
◦ 决策表是分析和表达多逻辑条件下执行不 同操作的情况的工具,可以把复杂逻辑关 系和多种条件组合的情况表达的比较明确。 决策表通常由四部分组成
条件桩 动作桩
规则
需求分析与系统 设计
系统测试
概要设计
集成测试
详细设计
单元测试
编码
W模型
W模型由Evolutif公司提出,强调测试活动伴随着整个软件开发 周期,而且测试对象不仅仅是程序,需求、设计等活动同样需 要测试,也就是说,测试与开发是同步进行的。
W模型可以说是V模型的自然而然的发展。W模型体现了“及早 的和不断的进行软件测试”原则,能够帮助改进项目的内部质 量,减少总体测试时间,加快项目进度,降低测试和修改成本。
◦ 单元测试、集成测试、系统测试和验收测 试。
软件测试的分类
按是否需要执行被测试软件
◦ 静态测试
静态测试又称静态分析,是不实际运行被测软件,而 是直接分析软件的形式和结构,查找缺陷。主要包括 对源代码、程序界面和各类文档及中间产品(如产品 说明书、技术设计文档等)所做的测试。
◦ 动态测试
动态测试又称动态分析,是指需要实际运行被测软件, 通过观察程序运行时所表现出来的状态、行为等发现 软件缺陷,包括在程序运行时,通过有效的测试用例 (对应的输入、输出关系)来分析被测程序的运行情 况或进行跟踪对比,发现程序所表现的行为与设计规 格或客户需求不一致的地方。
场景法
◦ 用例场景是通过描述流经用例的路径来确 定的过程,这个流经过程要从用例开始到 结束遍历其中所有的基本流和备选流。
软件测试的定义
概括说来,软件测试是为了发现错误而 执行程序的过程。或者说,软件测试是 根据软件开发各阶段的规格说明和程序 的内部结构,而精心设计一批测试用例, 并利用这些测试用例去执行程序,以发 现程序错误的过程。
软件测试的对象包括:源程序、目标程 序、数据及相关文档。
实际的测试过程中无法做到穷举测试。
黑盒测试设计方法
◦ 侧重于测试软件的功能需求,主要试图发现几类 错误:功能不对或遗漏、界面错误、数据结构或 外部数据访问错误、性能问题、初始化和终止错 误。
黑盒测试方法
等价类划分法
◦ 设计测试用例的步骤
对每个输入和外部条件进行等价类划分,画出等 价类表,并为每个等价类进行编号。
设计一个测试用例,使其尽可能多地覆盖有效等 价类,重复这一步,直到所有的有效等价类被覆 盖。
H模型体现了测试活动的独立性,它存在于整 个软件生命周期并与其他流程并发进行,体现 了“及早的和不断的进行软件测试”原则。不 同的测试活动可以按照某个次序先后进行,也 可以支持反复和迭代过程。只要某个测试达到 测试就绪点,测试执行活动就可以进行。
测试准备
测试就绪点 测试执行
测试流程
其他流程
X模型
软件测试的原则
不可能进行完全测试 测试中有风险存在 软件测试只能表明缺陷的存在,而不能证
明产品已经没有缺陷 软件产品中所存在的缺陷数与已发现的缺
陷数成正比 要避免软件测试的杀虫剂现象 及早的和不断的进行软件测试 进行回归测试 软件测试应该有计划、有组织的进行
软件测试的分类
按测试阶段
条件项
动作项
条件桩:列出问题的所有条件 条件项:列出所列条件下的取值,在所有
可能情况下的真假值 动作桩:列出问题规定可能采取的动作 动作项:列出在条件项的各种取值情况下
应采取的动作
将任何一个条件组合的特定取
值及相应要执行的动作称为一
条规则。在决策表中贯穿条件
项和动作项的一列就是一条规
则。
27
黑盒测试方法
所有的模型都具有如下基本特征:
◦ 描述了开发的主要阶段; ◦ 定义了每一个阶段要完成的主要过程和活动; ◦ 规范了每一个阶段的输入和输出; ◦ 提供了一个框架,可以把必要的活动映射到该
框架中。
编码修正模型(边做边改)
编码 测试
编码修正模型是所有模型中最古老也是最简单的模型, 该模型将软件开发过程分为编码和测试两项活动。
V模型
V模型是最有代表性的软件测试过程模型, 最早由Paul Rook在20世纪80年代提出。
在V模型中,单元测试和集成测试验证程序的设计,检测程序的执行 是否满足软件设计的要求;系统测试验证系统设计,验证系统功能、 性能的质量特性是否达到系统设计的指标;验收测试验证软件需求, 确定软件的实现是否满足用户需求或合同的要求。但是,V模型没有 明确说明早期的测试,不能体现“及早的和不断的进行软件测试”原 则动,才因能此发前现期。各开用户发需求阶段隐藏的错误,需要完成该阶段对应的测验试收测活试
该模型的主要特点是:
◦ 最适用于很小且很简单的项目。编码修正模型是从一个大致 想法开始工作,然后经过非正规的设计、编码、调试和测试 过程,最后完成工作。
◦ 成本可能很低,经过少量设计就进入编码阶段。 ◦ 易于使用,人员只需要很少的专业知识,写过程序的人都可
以用。 ◦ 对于一些非常小的、开发完成后就会很快丢弃的软件可以采
用户需求
用户需求V&V验收测试 准备
需求分析与系统 设计
需求分析与系统设计 V&V系统测试准备
概要设计
概要设计V&V集成测试 准备
详细设计
详细设计V&V单元测试 准备
编码
交付
验收测试
实施
系统测试
集成
集成测试
单元测试
H模型
H模型,它将测试活动完全独立出来,形成一 个独立的流程,将测试准备活动和测试执行活 动清晰的体现出来。
输出
需求 输出
软件
事件
软件测试的分类
按测试执行时是否需要人工干预
◦ 手工测试
手工测试是完全由人工完成测试工作,包括测试 计划的制定,测试用例的设计和执行,以及测试 结果的检查和分析。传统的测试工作都是由人工 来完成的。
◦ 自动测试
自动测试指的是通过软件测试工具,按照测试人 员的预定计划对软件产品进行自动的测试。
黑盒测试方法
边界值分析法-健壮性测试
◦ 健壮性测试是边界值分析的一种简单扩展,除了 使用5个边界值分析取值,还要通过采用1个略小 于最小值和1个略大于最大值的取值。 1个n变量函 x2数的健壮性边界值有6n+1个测试用例。
d
◦
min-
◦
max+
c
a
b
x1
健壮性边界值测试用例示意图
因果图法的定义:
该模型的主要特点是:
◦ 每一阶段都以验证/确认活动作为结束,其目的是尽可能多地消除 本阶段产品中存在的问题;
确认 ◦ 在随后的阶段里,尽可能对前面阶段的产品进行迭代。
设计
验证
编码 单元测试
测试 验收测试
运维 重新确认
需求
增量模型
构造增量1
构造增量2
增量模型是由瀑布模型演变而来的第一个模型, 它是对瀑布模型的精化。该模型有一个假设, 即需求可以分段,成为一系列增量产品,对每 一增量可以分别地开发。
为每一个无效等价类设计一个测试用例。
23
黑盒测试方法
边界值分析法基本思想
最小值(min)
x2
略大于最小值(min+)
输入范围内任意值(nom)
d
略小于最大Fra Baidu bibliotek(max-)
最大值(max)
c
a
b
x1
边界值分析测试用例示意图
对于n个变量,使除1个以外 的所有变量都取正常值,使 剩余的那个变量取上述5个 值,对每个变量都重复进行。 1个n变量函数的边界值有 4n+1个测试用例。
X模型也是对V模型和W
模型的改进。X模型提
出针对单独的程序片段
进行相互分离的编码和
封版 测试,此后通过频繁的
程序片段1 测试设计
X模型是事先计划再进行测试
执行测试 交接,通过集成最终合 成为可执行的程序。
工具配置
测试设计
X模型左边描述的是对
执行测试
工具配置
单独程序片段所进行的
编码完成
集成1~n
分离的编码和测试,此