1. 逻辑覆盖法
语句覆盖(弱覆盖/最常见):判定覆盖(弱覆盖):条件覆盖(弱覆盖):判定-条件覆盖:条件组合覆盖:2. 基本路径测试法
(1) 程序控制流图:(2) 设计基本路径覆盖法的步骤3. 插桩法:
目标代码插桩法源代码插桩法黑盒测试和白盒测试比较
一般有以下五种覆盖方式
语句覆盖,判定覆盖,条件覆盖,判定-条件覆盖,条件组合覆盖
又称为行覆盖,段覆盖,基本块覆盖
目的:测试程序中的代码是否被执行,它只测试代码中的执行语句,这里的执行语句不包括头文件注释、空行等。
例:设计所有的测试用例来覆盖所有的情况,保证每条可执行语句至少执行一次
优缺点:可以测试到执行语句是否被执行到,但是无法测试程序中存在的逻辑错误. 语句覆盖无需详细考虑每个判断表达式,可以直观地从源程序中有效测试执行语句是否全部被覆盖,由于程序在设计时,语句之间存在许多内部逻辑关系,而语句覆盖不能发现其中存在的缺陷,因此语句覆盖并不能满足白盒测试的测试所有逻辑语句的基本需求。
又称为分支覆盖,其原则是设计足够多的测试用例,在测试过程中保证每个判定至少有一次为真值,有一次为假值.判定覆盖的作用是是真假分支均被执行,虽然判定覆盖比语句覆盖测试能力强,但仍然具有和语句覆盖一样的单一性.
例:
优缺点: 判定覆盖的作用是使真假分支均被执行,虽然判定覆盖比语句覆盖测试能力强,但仍然具有和语句覆盖一样的单一性。如果只考虑判定中if的取值,而忽略了if中每个逻辑条件(例如x>0与y<0)则会导致覆盖的范围不够完整,遗落部分判定路径
设计做够多的测试用例, 使得每个判定语句中的逻辑条件取真值与取假值至少出现一次
例如:
并没有完全覆盖所有的执行路径,
优缺点:从条件覆盖的测试用例可知,使用3个测试用例就达到了使每个逻辑条件取真值与取假值都至少出现了一次,但从测试用例的执行路径来看,条件分支覆盖的状态下仍旧不能满足判定覆盖,即没有覆盖acd路径。相比于语句覆盖与判定覆盖,条件覆盖达到了逻辑条件的最大覆盖率,但却不能保证判定覆盖,仍旧不能满足白盒测试覆盖所有分支的需求。
要求设计足够多的测试用例,使得判定语句中所有条件的可能取值至少出现一次,同时,所有判定语句的可能结果也至少出现一次
例:
优缺点:
在判定-条件覆盖中,3个测试用例满足了所有条件可能取值至少出现一次,以及所有判定语句可能结果也至少出现一次的要求。相比于条件覆盖、判定覆盖,判定-条件覆盖弥补了两者的不足之处,但是由于判定-条件覆盖没有考虑判定语句与条件判断的组合情况,其覆盖范围并没有比条件覆盖扩展,判定-条件覆盖也没有覆盖acd路径,因此判定-条件覆盖在仍旧存在遗漏测试的情况。没有考虑到判定语句和条件组合情况**,**没有考虑到每个条件组合相互组合的情况
设计足够多的测试用例, 使得判定语句中的每个条件的所有可能,至少出现一次,并且每个判定语句本身的判定结果也至少出现一次,它与判定-条件覆盖的差别是,条件组合覆盖不是简单地要求每个条件都出现真假两种结果,而是这些结果的所有组合多至少出现一次
例:
序号组合含义1S1、S2、S3、S4x>0成立, y<0成立; x>2成立, z>0成立。2S1、S2、S3、S4x>0不成立, y<0成立; x>2成立, z>0成立。3S1、S2、S3、S4x>0成立, y<0不成立; x>2成立, z>0成立4S1、S2、-S3、S4x>0成立, y<0成立; x>2不成立, z>0成立5S1、S2、S3、-S4x>0成立, y<0成立; x>2成立, z>0不成立。6S1、-S2、S3、S4x>0不成立.y<0不成立; x>2成立, z>0成立。7S1、S2、-S3、S4x>0不成立, y<0成立; x>2不成立, z>0成立。8S1、S2、S3、-S4x>0不成立, y<0成立; x>2成立, z>0不成立。9S1、S2、-S3、S4x>0成直,y<0不成立; x>2不成立, z>0成立10S1、S2、S3、-S4x>0成立.y<0成立; x>2不成立, z>0不成立。11S1、S2、S3、S4x>0成立, y<0不成立; x>2成立, z>0不成立。12S1、S2、-S3、S4x>0不成立, y<0不成立; x2不成立, z>0成立。13S1、-S2、S3、S4x>0不成立, y<0不成立; x>2成立, 2>0不成立14S1、S2、S3、S4x>0成立, y<0不成立; x>2不成立, z>0不成立1SS1、S2、-S3、-S4x>0不成立, y<0成立; x>2不成立,z>0不成立。16S1、-S2、S3、-S4x>0不成立, y<0不成立; x>2不成立,z>0不成立优缺点:
与判定-条件覆盖相比,条件组合覆盖包括了所有判定-条件覆盖,因此它的覆盖范围更广。但是当程序中条件比较多时,条件组合的数量会呈指数型增长,组合情况非常多,要设计的测试用例也会增加,这样反而会使测试效率降低。
定义:路径测试时从一个程序的入口开始,执行所经历的各个语句。从广义的角度讲,任何有关路径分析的测试都可以被称为路径测试。完成路径测试的理想情况是做到路径覆盖,但对于复杂性大的程序要做到所有路径覆盖(测试所有可执行路径)是不可能的。
在不能做到所有路径覆盖的前提下,如果某一程序的每一个独立路径都被测试过,那么可认为程序中的每个语句都己经检验过,即达到了语句覆盖。这种测试方法就是通常所说的基本路径覆盖法。
通过了解基本路径的概念,利用基本路径覆盖法设计测试用例,实现CVIT系统部分发布新闻功能模块的测试用例设计,对该功能模块实施测试,书写测试报告。
DD路径
DD路径是决策到决策的路径，是指一个语句序列。DD路径是程序图中的一条链，分为5种情况。
由一个入度为0的节点组成，对应于源节点由一个出度为0的节点组成，对应于汇节点由一个入度>=2或出度>=2的节点组成，对应于判定语句或其结束语句由一个入度为1且出度为1的节点组成，对应于短分支由长度>=1的最大链组成，对应于串行语句序列DD路径图
定义：DD路径图DP={V,G}是一个有向图，V是节点的集合、E是有向边的集合。其中节点表示的是程序中的DD路径，边表示连续DD路径之间的控制流。
DD路径图是一种压缩格式的程序图。
拓扑路径与可行路径：拓扑路径不一定全是可行路径
程序流程图又称框图,是我们最熟悉,也是最容易理解的一种程序控制结构的图形表示了。在这种图上的框里面常常标明了处理要求或者条件,但是,这些标注在做路径分析时是不重要的。为了更加突出控制流的结构需要对程序流程图做一些简化。
两种图形符号:
圆圈代表流图中的一个节点,表示一条或多条无分支的语句
箭头称为边或者连接,代表控制流线或弧.
常见控制结构的程序控制流图的基本结构
程序控制流图==>控制流图
在选择或多分支结构中,分支的汇聚出应有一个汇聚节点
边和节点圈定的范围叫做区域,当对区域进行计数时,图形外的区域也应该记为一个区域
例:
l 如果判断中的条件表达式是有一个或者多个逻辑运算符进行连接的复合条件表达式,则需要将该判断改为一系列只有单条件的嵌套的判断
例:
if(a or b) x; else y;
举例:
代码：
void sort(int iRecordNum, int iType){ int x = 0; int y = 0; while (iRecordNum-- > 0){ if (iType == 0){ x = y + 2; }else if (iType == 1){ x = y + 10; }else{ x = y + 20; } } }步骤1:
画出程序控制流程图
程序控制流程图用来描述程序控制结构,可将程序控制流程图映射到一个相应的程序控制流图(假设流程图的菱形判定框中不包含复合条件)。在程序控制流图中,每一个圆称为流图的节点,代表一个或多个语句。一个处理方框序列和一个菱形判定框可被映射为一个节点,流图中的箭头,称为边或连接,代表控制流,类似于流程图中的箭头。
一条边必须终止于一个节点,即使该节点并不代表任何语句(例如 If-Else-Then结构)。由边和节点限定的范围称为区域。计算区域时应包括图外部的范围。画出其程序流程图和对应的控制流程图如图所示。
步骤2:
计算程序的环形复杂度,导出程序基本路径集中的独立路径条数,这是确定程序中每个可执行语句至少执行一次所必需的测试用例数目的上界。
圈复杂度是一种为程序逻辑复杂性提供定量测度的软件度量,将该度量用于计算程序的基本的独立路径数目,为确保所有语句至少被执行一次的测试数量的上界。独立路径必须包含一条在定义之前不曾用到的边。
有以下三种方法计算圈复杂度:
流图中区域的数量对应于环形复杂度。给定流图G的圈复杂度V(G),定义为V(G)=E-N+2,E是流图中边的数量,N是流图中节点的数量。给定流图G的圈复杂度V(G),定义为V(G)P+1,P是流图G中判定节点的数量。例如,图3-25所示的程序控制流图,按照上面方法计算圈复杂度,计算如下:
流图中有4个区域。T(G)=10条边-8节点+2=4。T(G)=3个判定节点+1=4。步骤3:
导出基本路径集,确定程序的独立路径。根据上面的计算方法,可得出4条独立的路径(一条独立路径是指,和其他的独立路径相比,至少引入一个新处理语句或一个新判断的程序通路。V(G)值正好等于该程序的独立路径的条数)。
路径1:4-14路径2:4-6-7-14路径3:4-6-8-10-13-4-14路径4:4-6-8-11-13-4-14根据上面的独立路径,去设计输入数据,使程序分别执行到上面4条路径。步骤4:根据步骤3中的独立路径,设计测试用例的输入数据和预期输出。为了确保基本路径集中的每一条路径都被执行,判断节点给出的条件,选择适当的数据以保证某一条路径可以被测试到,满足上面示例基本路径集的测试用例如下。
路径1: 4-14
输入数据: iRecoedNun=0,或者取 iRecordNum<0的某一值
预期结果:x=0
路径2: 4-6-7-14
输入数据: iRecoedNum=1,iype=0
预期结果:x=2
路径3: 4-6-8-10-13-4-14
输入数据: iRecoedNum=1, IType=1
预期结果:x=10
路径4: 4-6-8-11-13-4-14
输入数据: iRecoedNun=1, IType=2
预期结果:x=20
程序插桩就是往被测试程序中插入测试代码以达到测试目的的方法,插入的测试代码被称为探针.根据测试代码插入的时间可以将插桩法分为目标代码插桩和源代码插桩
目标代码插桩法的原理是在程序运行平台和底层操作系统之间建立中间层,通过中间层检查执行程序,修改指令.开发人员,软件分析工程师等对运行的程序进行观察,判断程序是否被恶意攻击或者出现异常行为,从而提高程序的整体质量.
- 即时模式:原始的二进制或可执行文件没有被修改或执行,将修改部分的二进制代码生成文件副本存储在新的内存区域中,在测试时仅仅执行被修改部分的目标代码.
- 解释模式:在解释模式中目标代码被视为数据,测试人员插入的测试代码作为目标代码指令的解释语言,每当执行一条目标代码指令,程序就会在测试代码中查找并执行相应的替代指令,测试通过替代指令的执行信息就可以获取程序的运行信息。
- 探测模式( Probe mσde):探测模式使用新指令覆盖旧指令进行测试,这种模式在某些体系结构(如×86)中比较好用。
- Pin
- DynamoRIO
相比于目标代码插桩,源代码插桩实现复杂程度低。源代码插桩是源代码级别的测试技术,探针代码程序具有较好的通用性,使用同一种编程语言编写的程序可以使用一个探针代码程序来完成测试
总结:程序插桩测试方法有效的提高了代码测试覆盖率,但是插桩测试方法会带来代码膨胀、执行效率低下和 Heisen Bugs在一般情况下插桩后的代码膨胀率在20%~40%,甚至膨胀率达到100%导致插桩测试失败
Heisen Bugs称为海森堡bug,它是一种软件缺陷,这种缺陷的重现率很低,当人们试图研究时bug会消失或改变行为。实际开发软件测试中,这种缺陷也比较常见,测试人员测试到一个缺陷提交给开发人员,开发人员执行缺陷重现步骤却得不到报告的缺陷,缺陷已经消失或者出现了其他缺陷。
黑盒测试过程中不用考虑内部逻辑结构,仅仅需要验证软件外部功能是否符合用户实际需求。
黑盒测试可发现以下缺陷:
外部逻辑功能缺陷,如界面显示信息错误等兼容性错误,如系统版本支持、运行环境等。性能问题,如运行速度、响应时间等。白盒测试与黑盒测试不同,白盒测试可以设计测试用例尽可能覆盖程序中分支语句,分析程序内部结构。白盒测试常用于以下几种情况
源程序中含有多个分支,在设计测试用例时要尽可能覆盖所有分支提高测试覆盖率。内存泄漏检查迅速,黑盒测试只能在程序长时间运行中发现内存泄漏可题,而白盒测试能立即发现内存泄露问题。