第十二章:测试
关于动态和静态
- 静态测试:
- 基本特征是在对软件进行分析、检查和审阅,不实际运行被测试的软件。静态测试约可找出30~70%的逻辑设计错误。
- 对需求规格说明书、软件设计说明书、源程序做检查和审阅,包括:
是否符合标准和规范;通过结构分析、流图分析、符号执行指出软件缺陷;
- 动态测试:
- 通过运行软件来检验软件的动态行为和运行结果的正确性
- 动态测试的两个基本要素:
被测试程序
测试数据(测试用例)
测试目标:发现错误
只有当发现了错误时,测试才被认为是成功的
故障识别是确定由哪一个故障或哪些故障引起失效的过程
故障改正是修改系统使得故障得以去除过程
故障类型
- 算法故障
- 计算故障和精度故障:一个公式的实现是错误的
- 文档故障:文档与程序实际做的不一致
- 能力或边界错误:系统活动达到极限时,系统性能会变得不可接受
- 计时故障或协调故障
- 性能故障:系统不能以需求规格的速度执行
- 标准和过程故障
测试的分类
分类:
-
模块测试、构件测试、单元测试(详细设计文档)
-
集成测试(概要设计文档)
-
功能测试(需求规格说明文档)
-
性能测试(需求规格说明文档)
-
验收测试(用户需求、验收标准)
-
安装测试
-
Alpha测试
-
Beta测试
黑盒测试:
- 内容:闭盒或黑盒: 测试对象的功能。是一种确认技术
- 类型:数据驱动测试
- 依据:SRS(Software requriement specification软件需求说明书)
- 目的:从质量特性的不同方面,对软件进行测试,检测该软件是否实现了SRS中所有显示和隐式的需求
- 步骤:构造输入和预期输出,通过一定的操作步骤来测试软件。
- 优点:
- 对较大的代码单元来说,黑盒测试比白盒测试的效率高
- 测试人员不需要了解实现得细节,包括特定的编程语言.免于受强加给测试对象内部结构和逻辑的约束
- 测试人员和编程人员是相互独立的
- 从用户的角度进行测试,很容易被接受和理解
- 测试用例可以在规格完成后马上进行
缺点:
- 不可能总是进行完备的测试
- 不能测试程序内部特定部位
- 如果程序未执行的代码无法发现
- 没有清晰的和简明的规格,测试用例很难被设计
白盒测试:
- 内容:开盒或白盒: 测试对象的结构。是一种验证技术
- 类型:结构测试
- 依据:LLD(详细设计)
- 目的:利用不同的逻辑率到达某种程度的代码覆盖率(考虑全部程度的代码覆盖率会增加本)
- 步骤:静态分析和动态分析
- 优点:
- 迫使测试人员去了解软件的实现
- 检测代码中的每条路径和分支
- 揭示隐藏在代码中的错误
- 对代码的测试进行比较彻底
- 缺点:
- 白盒测试投入较大,成本较高
- 白盒测试不验证规格的正确性
- 无法检查代码中遗漏的路径和数据敏感性错误
白盒测试使用的方法
- 逻辑覆盖法(分支覆盖、条件覆盖、语句覆盖、条件组合覆盖、路径覆盖)
- 基本路径测试法:通过分析由控制构造的环路的复杂性,导出基本路径集合,从而设计测试用例,保证这些路径至少通过一次。
基本路径测试步骤:
(1)导出程序流程图的拓扑结构-流图(程序图)
(2)计算流图G的环路复杂度V(G)
(3)确定只包含独立路径的基本路径集
(4)设计测试用例
例:
PROCEDURE SAMPAL
(A,B:REAL; VAR X:REAL);
BEGIN
IF (A>1) AND (B=0)
THEN X:=X/A
IF (A=2) OR (X>1)
THEN X:=X+1
END;
计算流图G的环路复杂度V(G)
V(G)= 区域个数=4
V(G)=边的条数-节点个数+2=4
V(G)=判定节点个数+1=4
确定只包含独立路径的基本路径集
path1:1-11
path1:1-2-3-4-5-10-1-11
path1:1-2-3-6-8-9-10-1-11
path1:1-2-3-6-7-9-10-1-11
一条新路径必须包含一条新边。这4条路径组成了一个基本路径集。4(环路复杂度V(G))是构成这个基本路径集的独立路径数的上界,也是设计测试用例的数目。
设计测试用例,保证基本路径集中每条路径的执行。
灰盒测试
是介于白盒测试与黑盒测试之间的一种测试,灰盒测试多用于集成测试阶段,不仅关注输出、输入的正确性,同时也关注程序内部的情况。
单元测试:
-
概念:单元测试是对软件组成单元进行测试。
-
目的:检验软件基本组成单位的正确性。测试的对象是软件设计的最小单位:模块。
-
内容:主要对模块的五个基本特性进行评价:
- 模块接口
- 局部数据结构
- 边界条件
- 重要的执行路径
- 错误处理
-
依据:代码和注释+详细设计文档(单元测试一般为编码步骤的附属部分。)
-
测试方法:白盒测试
-
模块不是独立的程序,自己不能运行,要靠其它部分来调用和驱动,要为每个单元测试开发两个软件:
(1)驱动模块(驱动程序):相当于主模块
(2)桩模块(测试存根、连接程序) :代替所测模块调用的子模块
集成测试:
-
概念:集成测试也称联合测试、组装测试,将程序模块采用适当的集成策略组装起来,对系统的接口及集成后的功能进行正确性检测的测试工作。
-
目的是检查软件单位之间的接口是否正确。
-
测试方法:黑盒测试与白盒测试相结合
-
内容:模块之间数据传输、模块之间功能冲突、模块组装功能正确性、全局数据结构、单模块缺陷对系统的影响
-
术语:
构件驱动程序: 是调用特定构件并向其传递测试用例的程序
桩: 用于模拟缺少构件时的活动 -
类型:
- 自底向上的测试
- 自顶向下测试
- 一次性测试
- 三明治测试
- 改进的自顶向下测试
- 改进的三明治测试
构建层次的例子:
- 自底向上的测试
测试序列和它们之间的关系
-
自顶向下测试(深度优先、广度优先)
只有A是独立测试的
-
修改的自顶向下测试:
进行合并之前每一个层的构件进行单独测试
-
一次性测试
同时需要桩和驱动程序来测试独立的构件
-
三明治测试
将系统看作三层
-
改进的三明治集成测试
允许在将较上层的构件和其他构件合并前,先对这些较上层的构件进行测试
- 对比
系统测试
-
概念:将软件系统看成是一个系统的测试。包括对功能、性能以及软件所运行的软硬件环境进行测试。时间大部分在系统测试执行阶段
-
测试依据:需求规格说明文档
-
测试方法:黑盒测试
-
测试内容:功能、界面、可靠性、易用性、性能、兼容性、安全性等
确认测试(验收测试)
-
概念:验收测试是部署软件之前的最后一个测试操作。它是技术测试的最后一个阶段,也称为交付测试。
-
目的:确保软件准备就绪,按照项目合同、任务书、双方约定的验收依据文档,向软件购买都展示该软件系统满足原始需求。
-
测试依据:用户需求、验收标准
-
测试方法:黑盒测试
-
测试内容:同系统测试(功能…各类文档等)
α测试(Alpha Testing)
α测试是由一个用户在开发环境下进行的测试,也可以是公司内部的用户在模拟实际操作环境下进行的测试。α测试的目的是评价软件产品的FLURPS(即功能、局域化、可使用性、可靠性、性能和支持)。
大型通用软件,在正式发布前,通常需要执行Alpha和Beta测试。α测试不能由程序员或测试员完成。
β测试(Beta Testing)
Beta测试是一种验收测试。Beta测试由软件的最终用户们在一个或多个客房场所进行。
α测试与Beta测试的区别:Findyou
测试的场所不同:Alpha测试是指把用户请到开发方的场所来测试,beta测试是指在一个或多个用户的场所进行的测试。
Alpha测试的环境是受开发方控制的,用户的数量相对比较少,时间比较集中。beta测试的环境是不受开发方控制的,用户数量相对比较多,时间不集中。
alpha测试先于beta测试执行。通用的软件产品需要较大规模的beta测试,测试周期比较长。sdf
测试计划
- 内容:
- 构建测试目标
- 设计测试用例
- 编写测试用例
- 测试测试用例
- 执行测试
- 评估测试结果
- 目的:测试计划解释
- 由谁进行测试
- 为什么进行测试
- 怎样执行测试
- 测试的进度安排
测试系统的测试过程
-
功能测试: 集成系统是否按照需求规格说明执行它的功能?
任务:
比较系统的实际功能与需求;
根据需求文档开发测试用例 -
性能测试: 是否满足非功能需求?
任务:
检查响应速度;
结果的精确性;
数据的可访问性。
–性能测试类型–:
压力测试、容量测试、配置测试、兼容性测试、回归测试、安全测试、计时测试、环境测试、质量测试、恢复测试、维护测试、文档测试、人为因素测试、容错测试 -
验收测试: 系统是客户期望的吗?
任务:
让客户和用户能够确定我们构建的系统满足了他们的期望;
编写、执行和评估都是由客户来进行
–验收测试类型–:- 验证性测试: 在实验的环境中安装系统
- Alpha 测试: 内部测试
- Beta 测试: 客户的验证
- 并行测试: 新系统与先前的版本并行运转
-
安装测试: 系统能在客户端运行吗 ?
测试之前:配置系统;将正确的数量和种类的设备连接到主处理器上;与其他系统建立通信
测试时候:回归测试: 验证系统被正确地安装
可靠性、可用性、可维护性
可靠性: 在给定时间间隔内、给定条件下无失效运作的概率
可用性: 在给定时间点上,一个系统能够按照规格说明正确运行的概率
可维护性: 给定的使用条件下,在规定的时间间隔内,使用规定的过程和资源完成维护活动的概率