第十二章：测试
关于动态和静态
- 静态测试：
- 基本特征是在对软件进行分析、检查和审阅，不实际运行被测试的软件。静态测试约可找出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 测试: 客户的验证
- 并行测试: 新系统与先前的版本并行运转
-
安装测试: 系统能在客户端运行吗 ?
测试之前：配置系统；将正确的数量和种类的设备连接到主处理器上；与其他系统建立通信
测试时候：回归测试: 验证系统被正确地安装
可靠性、可用性、可维护性
可靠性: 在给定时间间隔内、给定条件下无失效运作的概率
可用性: 在给定时间点上，一个系统能够按照规格说明正确运行的概率
可维护性: 给定的使用条件下，在规定的时间间隔内，使用规定的过程和资源完成维护活动的概率