-
花了一个多星期整理上课使用的ppt,书写不易,请大家多多支持
文章目录
概述
计算机系统的软件可靠性问题
- 1994年，Intel奔腾芯片缺陷
- 千年虫问题
- ”冲击波“计算机病毒
- 2008年奥运会门票预售叫停
- 系统访问量超8倍
- 票务系统抗压测试
- 性能测试
软件质量
软件质量包括正确性，可靠性，可读性，可移植性和健壮性，主要含义是软件的可靠性
软件可靠性
特定环境下，在给定时间内，无障碍运行的概率
度量
- 软件中初始故障的数量
- 软件经过测试后，通过查错，改错，在软件中剩余故障的数量
- 平均无故障时间
- 故障间隔的时间长度
- 故障发生率
- 经过预测下次故障的发生时间
软件故障
定义
- 从内部看，软件故障是软件产品开发或维护过程中存在的错误，毛病等各种问题
- 从外部看，软件故障是系统所需要实现的某种功能的失效或违背
计算机系统或程序存在任何一种破坏正常运行能力的问题，错误，或者隐藏的功能缺陷等
软件故障导致软件产品在某种程度上不能满足用户的需求- 硬件故障
物理性能恶化
- 软件故障
设计阶段人为因素造成的 - 操作故障
操作人员和维护人员的错误 - 环境故障
电源，外界干扰，地震，火灾，病毒等各种外界因素引起的故障
错误
人是会犯错的。过失是人犯下的，是人做一件错事或认为产生的一个不正确的结果
故障
故障时错误的结果
失效
故障引起的结果
软件测试与软件可靠性
- 软件中都会有故障存在
- 可以减少故障的引入，但是不可能完全杜绝软件中的故障
软件测试
- 软件需求分析，设计说明和编码的最终复审
- 是软件质量保证的关键步骤
- 是为了发现故障而执行程序的过程
定义：
- 是否满足规定的需求
- 是否有差别
测试是为了发现故障而执行程序的过程
- 谁来执行
- 测试什么
- 什么时候测试
- 怎样进行测试
- 测试停止的标准
- 成功采用了具体的测试用例设计方法
- 每一类覆盖的覆盖率
- 故障检测率
- 检测出故障的具体数量或消耗的具体时间
软件生存周期
- 制定计划
- 需求分析
- 设计
- 程序编码
- 测试
- 运行维护
黑盒测试
不考虑内部结构和内部特性，只根据需求规格说明书，设计测试用例，检查程序的功能是否按照规范说明的规定正确的执行
- 一切实际测试都是不彻底的
测试原则
黑盒测试与白盒测试
黑盒测试
- 等价类划分
- 边界值分析
- 决策表驱动
白盒测试
- 逻辑覆盖
- 数据流测试
- 域测试
- 符号测试
- 路径分析
- 程序变异
- 程序插装技术
软件测试过程
软件开发是自顶向下，软件测试自底向上
单元测试
又称模块测试，针对程序模块来进行正确性检验的测试工作
- 模块接口测试
- 局部数据结构测试
- 路径测试
- 错误处理测试
- 边界测试
静态测试与动态测试
静态测试
不利用计算机运行被测试的程序，通过其他手段达到检测的目的
动态测试
通过运行和使用被测程序，发现软件故障，达到检测目的
回归测试
对程序进行测试已确定是否因修复故障而引入了新的故障
\alphaα测试
由一个用户在开发环境下进行的测试
目的是平价产品的功能，可使用性，可靠性，性能和支持\betaβ测试
软件的多个用户在一个或多个用户的实际使用环境下进行的测试。开发者通常不在测试现场
\alphaα测试达到一定的可靠程度时才能进行\betaβ测试，它处在整个测试的最后阶段
测试与调试
调试不属于测试
成功的测试发现错误从而引起调试的进行测试生命周期
- 测试计划
- 测试设计
- 测试开发
- 测试执行
- 测试评估
测试工具
测试评估
- 测试覆盖测试
- 软件故障评估
- 测试有效性评估
软件质量评估
检查和评价当前软件开发过程,并设法达到防止软件故障出现
软件过程成熟度
- 初始度
- 可重复级
- 定义明确
- 定量管理级
- 优化级
第二章
三角形问题
三角形问题之所以复杂,是因为输入与输出之间的关系比较复杂
NextDate函数
- 讨论输入域的复杂性
- 确定闰年的规则
股佣金问题
功能性测试(黑盒测试)
优点
- 功能性测试与软件如何实现无关
- 测试用例的开发可以和实现并行进行
问题
- 测试用例之间可能存在严重的冗余
- 可能有未被测试的软件漏洞
常用测试方法
- 边界值分析
- 等价类划分
- 决策表驱动法
边界值分析
基本原理:故障往往出现在输入变量的边界值附近
基本思想: 利用输入变量的最小值,稍大于最小值,正常值,稍小于最大值,最大值-
健壮性测试
除了取5个边界值,还要采用一个略大于最大值,略小于最小值,看看超过极限时系统会出现什么情况
-
最坏情况测试
除了五个边界值,对五个边界值进行笛卡尔乘积运算,生成测试用例
等价类测试
把输入域划分成若干个互不相交的一组子集–等价类
-
特点
- 如果等价类中的一个元素作为测试数据进行测试不能发现程序中的故障,那么使用集合中的其他元素进行测试也不能发现故障
对于揭露程序的故障来说,等价类的每个元素是等效的
-
步骤
- 确定等价类
- 有效等价类
- 对程序规格说明,是有意义的,合理的输入数据所构成的集合
具体问题中,有效等价类可以是一个,也可以是多个
- 无效等价类
- 对程序来说,是不合理或无意义的输入数据所构成的集合
无效等价类可以一个,也可以多个
- 有效等价类
- 确定测试用例
- 为每个等价类规定一个唯一的编号
- 设计一个新的测试用例,尽可能多覆盖尚未被覆盖的有效等价类
- 设计一个新的测试用例,覆盖且覆盖一个还没有被覆盖的无效等价类
- 确定等价类
-
弱一般等价类测试
- 测试数据不考虑无效数据值
- 测试用例使用每个等价类中的一个值
-
强一般等价类测试
- 需要将所有的等价类进行笛卡尔乘积,每部分设计一个测试用例
- 笛卡尔乘积确保了两种意义上的完备性
- 覆盖了所有等价类
- 采用了所有可能的输入组合
- 笛卡尔乘积确保了两种意义上的完备性
- 需要将所有的等价类进行笛卡尔乘积,每部分设计一个测试用例
-
健壮性等价类测试
- 遂与有效输入,测试用例使用每个有效类中的一个值
- 对于无效输入,一个测试用例只拥有一个无效值,其他值都有效
健壮指的是无效值的考虑
强指的是多故障的假设
基于决策表的测试
最严格,最有逻辑严格性的测试方法
- 优点
- 把复杂的问题按各种可能的情况一一列举出来,简明而易于理解,也可避免遗漏
- 决策表
描述不同条件集合下采取行动的若干组合情况
- 利用决策表,可以很好的发现冗余和不一致性
- 适用于
- if-then-else逻辑很突出
- 输入变量存在逻辑关系
- 设计输入变量子集的计算
- 输入与输出之间存在因果关系
- 很高圈复杂度的程序
第三章 结构性测试
- 特点
- 基于被测试程序的源代码,而不是软件规格说明
- 更容易发现软件测试故障,常用于单元测试
结构性测试
白盒测试又称结构测试或者基于程序的测试.
- 该方法将被测对象看做一个打开的盒子,允许内部人员检查其内部结构.测试人员根据程序内部结构特性,设计,选择测试用例,检查程序的每条路径是否都按照预定的要求正确执行.
常见的白盒测试方法有:
- 逻辑覆盖
- 数据流测试
- 域测试
- 符号测试
- 路径分析
- 程序变异
- 程序插装
逻辑覆盖
使用最广泛
- 要求对被测试程序逻辑结构有清楚的了解,要能掌握程序的所有细节
- 要求对被测试程序的结构做到一定程度的覆盖
- 分为:
- 语义覆盖
是比较弱的测试覆盖准则
- 判定覆盖
又称之为分支覆盖,使得每个判断的取真分支和取假分支至少执行一次,即判断的真假值均要被检测
- 条件覆盖
每个判断的每个条件的可能取值至少被执行一次
- 判定-条件覆盖
判断中的每个条件的所有可能取值至少执行一次,同时每个判断的所有可能判断结果也至少被执行一次
- 路径覆盖
程序控制图
- 重要性
明确地描述测试用例和测试用例所执行的程序部分之间的关系.
McCabe的基本路径法
测试观点
强连通图的圈数就是图中线性独立环路的数目
- 选择一条基线路径,一般选择有较多判断结点的路径
- 回溯基线路径
符号测试
基本思想
- 允许程序的输入不仅可以是具体的数值数据,而且还可以包括符号值.
- 执行过程中以符号计算代替了普通执行中的数值计算,所得到的结果自然是符号公式或符号谓词
普通测试执行的事算数运算,符号测试执行的是代数计算
程序插装
借助于往被测试程序中插入操作来实现测试目的的方法
考虑的方面
- 探测哪些信息
- 在程序的什么部位设置探测点
- 需要设置多少个探测点
用途
- 覆盖分析
- 监控和断言
- 查找数据流异常
指导方针
基本原则
- 具有高圈复杂度的程序需要更充分的测试
- 一般选择V(G)=10
- 如果单元具有更高的复杂度,可以简化单元或计划更充分的测试
- 简化单元的最好方法是解决非结构化的问题
覆盖指标
- 作为一种强制执行的标准
- 作为一种机制,指导要求更严格部分的代码有选择地进行测试
数据流测试
数据流是指关注定义点和使用(或引用)点的一种结构测试方法,它和数据流图没有什么联系.
实际上很多数据流测试支持者和研究人员将这种测试方法看作是一种路径测试.
通过分析变量的定义和使用,以查找如引用未定义变量等程序错误,也可以用来查找对以前未曾使用的变量的再次赋值等数据流异常的情况
早期数据流分析常常集中于现在叫定义/引用异常的缺陷:- 变量被定义但是从来没有被使用
- 所使用的变量没有被定义
- 变量在使用之前被定义了两次
这些异常可以通过程序的索引表发现,可以通过所谓的静态分析发现
- 将程序中的变量出现分为定义和引用
- 👎语句K执行时改变了程序变量V的值,则称K定义了变量V
- 若语句k执行时引用了变量V的值,则称K引用了变量V
定义/使用测试
假设V是程序P中的变量的集合,程序P控制流程图用G(P)表示,其中结点代表语句或语句片段,边代表结点序列.G(P)有一个单入口节点和一个单出口节点,并且不允许有某个结点到自身的边
- 变量V的定义结点,记作DEF(v,n)
结点n\in∈ G(P)是变量v\in∈V定义的结点,当且仅当变量V的值由对应结点n的语句或语句片段所定义.
- 变量v的使用结点n记作USE(v,n)
结点n\in∈ G(P)是变量v\in∈V的使用结点,当且仅当变量v的值在对应结点n的语句或语句片段中被引用.
- 谓词使用,记作P-use
USE(v,n)是一个谓词使用,当且仅当n是谓词语句,否则,USE(v,n)是计算使用,记作C-use.
- 定义/使用路径,记作du-path
如果对某个变量v\in∈V,存在一个定义,使用结点对,即DEF(v,m)和USE(v,n),使得变量v在结点m处被定义,在结点n处被使用,则称为一条定义/使用路径,结点m称为该定义使用路径的开始结点,而结点n则称为该定义/使用路径的结束结点.
- 定义清晰路径(defination-clear path),记作dc-path
如果一个变量v\in∈V,存在一个定义,使用结点对,即DEF(v,m)和USE(v,n),使得变量v在结点m处被定义,在结点n处被使用,并且从m到n的结点序列中没有其他结点对对变量v进行过定义,则从m到n的结点序列称为一条定义清晰路径,结点m称为该定义/使用路径的开始结点,而结点n则称为该定义/使用路径的结束结点.
定义/使用路径和定义清晰路径描述了变量从被定义到被引用点数据流向.
不是定义清晰的定义/使用路径,很可能是潜在问题的所在.所以应该特别关注定义/使用路径定义/使用路径覆盖测试
- 数据流覆盖测试指标
P是被测程序,G(P)是其控制流图,T是G(P)的路径集合,并假设定义/使用路径都是可执行路径
- 所有定义/使用路径覆盖准则
集合T满足程序P的所有定义/使用路径覆盖准则,当且仅当对所有的变量v\in∈V,T包含了从v的每个定义结点到v所有使用结点的定义清晰路径.
- 所有定义覆盖准则
集合T满足程序P所有定义覆盖准则,当且仅当对所有的变量v\in∈V,T包含了从变量v的每个定义结点到v的一个使用结点的定义清晰路径.
- 所有使用覆盖准则
集合T满足程序P的所有使用覆盖准则,当且仅当对所有的变量v\in∈V,T包含了从v的每个定义结点到v的所有使用结点的定义清晰路径
- 所有谓词使用/部分计算使用覆盖准则
集合T满足程序P的所有谓词使用/部分计算使用覆盖准则,当且仅当对所有的变量v\in∈V,T包含了从v的每个定义结点到v的所有谓词使用结点的定义清晰路径,并且如果v的一个定义没有谓词使用结点,则定义清晰路径至少包含一个计算使用
- 所有计算使用/部分谓词使用覆盖准则
集合T满足程序P的所有计算使用/部分谓词使用覆盖准则,当且仅当对所有的变量v\in∈V,T包含了从每个定义结点v的所有计算使用结点的定义清晰路径,并且如果v的一个定义没有使用计算节点,则定义清晰路径至少包含一个谓词使用.
来源：https://www.cnblogs.com/zhichao123/p/11715398.html