软件測试基本方法(二)之白盒測试

白盒測试

概念:依照程序内部的结构測试程序,通过測试来检測产品内部动作是否依照设计规格说明书的规定正常进行。检验程序中的每条通路是否都能按预定要求正确工作。

分类:白盒測试是基于覆盖的測试。尽可能覆盖程序的结构特性和逻辑路径。所以其详细方法有逻辑覆盖、循环覆盖、基本路径覆盖。逻辑覆盖又可进一步分为语句覆盖、判定(分支)覆盖、条件覆盖、判定-条件覆盖、条件组合覆盖等。

白盒測试主要用于单元測试(我们须要了解程序源代码和结构,并且基于输入输出。适合单元模块)。以下重点介绍经常使用的几种白盒測试方法。

语句覆盖:

定义:仅仅要求覆盖到全部可运行语句(每一个可运行语句至少运行一次),不关注推断运算,确保可运行语句处没有错误。

样例:

依照白盒,我们仅仅需覆盖到全部可运行语句就可以。而为此我们仅仅需用測试用例(X=1。Y=4,Z=9)。这样三句话都会打印出来。

但假设编码时将X=1 AND Y>3错误写成X=1 OR Y>3。尽管我们的測试用例能够覆盖到全部可运行语句,并且证明可运行语句无误。但因此我们的password系统面临巨大风险。Y仅仅要大于3就能攻破第一道防线。

而我们对此浑然不知。所以语句覆盖不能满足我们的需求(有人说它是最弱的逻辑覆盖准则)。

判定(分支)覆盖:

定义:每一个推断的取真分支和取假分支至少经历一次。弥补语句覆盖对推断逻辑的不足。

样例:同上。

  • (X=1。Y=4,Z=9)—— 通过路径T->T
  • (X=0,Y=4,Z=0)—— 通过路径F->F

上面两个測试用例。将两个推断条件的真假值都遍历了,是运行判定覆盖的最少測试用例。这样当将X=1 AND Y>3误写成X=1 OR Y>3时,第二个測试用例就能发现错误。

但假设选择的測试用例是(X=0。Y=0,Z=0)还是不能发现错误。

试试以下的覆盖。

条件覆盖:

定义:使每一个推断中每一个条件的真假至少满足一次。

样例:同上。

第一个推断中有两个条件X=1和Y>3,第二个推断中有一个条件Z=9。

  • (X=1,Y=4。Z=9)—— X=1真。Y>3真。Z=9真
  • (X=0,Y=0,Z=0)—— X=1假,Y>3假,Z=9假

也是两个測试用例就可以。这样的覆盖有两个问题:

  • 任然不能解决那个OR问题
  • 假设选择的測试用例是(X=1,Y=2。Z=9)和(X=0,Y=4,Z=0)。尽管符合条件覆盖,但第一个推断仅仅运行了假分支,这会遗漏逻辑错误。

判定——条件覆盖:

定义:是判定覆盖和条件覆盖的结合。保证每一个推断中每一个条件的真假至少满足一次,同一时候每一个推断的取真分支和取假分支至少经历一次。

样例:同上。

  • (X=1。Y=4,Z=9)
  • (X=0,Y=0,Z=0)

这样既让每一个推断的真假分支都取到,也让每一个推断中每一个条件的真假也都取到。但这相同解决不了OR问题——当AND误写为OR时,两个用例的运行路径不变,所以仅凭这两个用例是无法察觉错误的。

条件组合覆盖:

定义:对于每一个推断。组合当中的条件的真假值(假如这个推断中由两个条件组成。那么应设计T1T2、T1F2、F1T2、F1F2这种组合),并让每一个推断的真假值都取到。

样例:同上。

  • (X=1。Y=4。Z=9)—— X=1真,Y>3真,Z=9真——覆盖路径:T-T
  • (X=1,Y=0,Z=0)—— X=1真。Y>3假,Z=9假——覆盖路径:F-F
  • (X=0,Y=4,Z=9)—— X=1假。Y>3真。Z=9真——覆盖路径:F-T
  • (X=0,Y=0,Z=0)—— X=1假,Y>3假。Z=9假——覆盖路径:F-F

当OR问题出现时,上述第二、三个用例的路径就会发生改变。察觉到错误。这样便攻克了OR问题,由于第一个推断中条件真假的组合中一真一假的组合是区分AND和OR的根本手段。

尽管OR问题攻克了。但我们发现有一条路径没有覆盖到——T-F。

路径覆盖:

定义:覆盖全部可能运行的路径。

样例:同上。

让我们在条件组合覆盖用例的基础上改动第二个用例。

  • (X=1,Y=4,Z=9)—— X=1真,Y>3真。Z=9真——覆盖路径:T-T
  • (X=1。Y=4,Z=0)—— X=1真,Y>3真,Z=9假——覆盖路径:T-F
  • (X=0,Y=4,Z=9)—— X=1假,Y>3真。Z=9真——覆盖路径:F-T
  • (X=0。Y=0,Z=0)—— X=1假,Y>3假,Z=9假——覆盖路径:F-F

尽管路径都覆盖了。但路径覆盖没有覆盖全部的条件组合。

总结:

可见没有一种覆盖能全然覆盖全部的測试用例。因此,在实际的測试用例设计中,往往将多种覆盖进行组合,达到最高的覆盖率。像本例中,终于測试用例是在在条件组合覆盖的基础上补上路径覆盖所涉及的。

  • (X=1,Y=4。Z=9)—— X=1真。Y>3真,Z=9真——覆盖路径:T-T
  • (X=1,Y=0,Z=0)—— X=1真。Y>3假。Z=9假——覆盖路径:F-F
  • (X=0。Y=4。Z=9)—— X=1假,Y>3真。Z=9真——覆盖路径:F-T
  • (X=0,Y=0。Z=0)—— X=1假,Y>3假,Z=9假——覆盖路径:F-F
  • (X=1。Y=4,Z=0)—— X=1真,Y>3真,Z=9假——覆盖路径:T-F

补:

基本路径測试法:

(1)程序流程图

上述样例的流程图为:

(2)计算程序环路复杂度。

  • V(G) = 区域数目。区域是由边界和节点包围起来的形状所构成。计算区域时包含图的外部区域,将其作为一个区域。所以上图有3个区域,也就是有3条基本路径。
  • V(G) = 边界数目-节点数目+2。这样V(G) = 6 - 5 + 2 = 3。
  • V(G) = 推断节点数目 + 1。上图的推断节点是A和C,所以V(G) = 2 + 1 = 3——一般用它作为圈的复杂度。而圈复杂度是路径数的上限,以下就来看一看基本路径是哪些。

(3)确定基本路径。

上图所看到的的程序有3条基本路径。以下是一组基本路径:

  • A-C-end
  • A-B-C-end
  • A-B-C-D-end

基本路径是什么,3条基本路径是怎样得出的(为什么有3条,选择这3条的原则)。

希望知道的朋友留下评论:)

时间: 2024-10-12 04:17:06

软件測试基本方法(二)之白盒測试的相关文章

单元測试和白盒測试相关总结

一.  软件測试方法 1.        软件測试方法包含:白盒測试(White  Box  Testing).黑盒測试(Black  Box Testing).灰盒測试.静态測试.动态測试. 2.        白盒測试:是一种測试用例设计方法.在这里盒子指的是被測试的软件,白盒.顾名思义即盒子是可视的,你能够清晰盒子内部的东西以及里面是怎样运作的.因此白盒測试须要你对系统内部的结构和工作原理有一个清晰的了解,并且基于这个知识来设计你的用例. 白盒測试技术一般可被分为静态分析和动态分析两类技术

白盒測试

大家都熟知软件測试的方法分为黑盒測试和白盒測试,当中的黑盒測试是功能測试比較简单这里就不再赘述.以下主要区分白盒測试中的几种比較easy弄混的測试方法. 软件測试中最经常使用的是逻辑覆盖法,全部可用的方法按覆盖程度从弱到强的顺序分为:语句覆盖.判定覆盖.条件覆盖.判定-条件覆盖.条件组合覆盖.路径覆盖. 仅仅要搞清楚本质,事实上这几种的測试方法就没那么难了. 例如以下图 这张图有两个推断语句分支形成4条路径.分析各种覆盖所能覆盖的路径条数. 语句覆盖:每一条语句 都要运行一遍比如:ace路径运行

【金阳光測试】大话Android自己主动化測试--Android自己主动化系列(1)--金阳光于2013年4月份

Android自己主动化測试框架和工具在四年多的发展日趋成熟. 从五年前的第一代自己主动化架构演进到眼下第四代(本系列讲座第7篇后将具体剖析第三代和第四代自己主动化框架)从曾经最早谷歌推崇的monkey随机測试工具到点触流自己主动化工具monkeyrunner.MonkeyTalk.基于元素识别的自己主动化框架sikuli.seeTest.iTest.基于控件识别的Robotium.SL4A.这三种技术各有千秋.基本上如今做出的自己主动化框架都是整合或者改动了以上这些免费的自己主动化框架:比方中

黑盒、白盒、灰盒测试的基本概念

黑盒: 对于一段程序,对其测试时,不需要知道内部结构和特性,在输入接口处输入激励,观察输出是否正确. 主要用于软件界面和功能测试. 实际应用中,由于输入为无穷个,不仅要测试所有合法的输入,也要测试不合法但是可能发生的输入. 白盒: 白盒测试也称结构测试和逻辑驱动测试,知道程序内部结构,验证内部每条通路是否能正常工作. 也就是穷举路径测试,从检查程序的逻辑出发.主要用于软件验证. 但是, 第一,穷举路径测试决不能查出程序违反了设计规范,即程序本身是个错误的程序. 第二,穷举路径测试不可能查出程序中

白盒交换机

如上图所示,AT&T将白盒生态系统分为4层.硬件1层(Hardware 1 Layer):底层是商用芯片,在3月份的ONS大会上,AT&T高管宣布已经进行的开源白盒试验,通过使用博通和Barefoot的商用芯片进行试验. 软件1层(software 1 layer):芯片接口,该层提取了芯片的功能,开源软件初创公司SnapRoute是AT&T在白盒化试验中操作系统的提供商,其他开源软件包括DPDK和交换机抽象接口(SAI),以及可编程语言P4. 硬件2层(hardware 2 la

软件測试基本方法(六)之集成測试和系统測试

在软件开发中.常常会遇到这种情况.单元測试时确认每一个模块都能单独工作,但这些模块集成在一起之后会出现有些模块不能正常工作.比如,在chrome环境下用js写了一个实时捕捉video中特定区域的模块,正常工作:利用worker线程进行webgl场景渲染,也正常.但是当两个运算合并时.出现一个模块不能正常执行,原因在于两个模块不适合在worker线程中结合.基于worker本身的局限性,仅仅能有一个模块正常工作. 所以,非常有必要进行集成測试. (1)集成測试定义: 集成測试是将软件集成起来,对模

软件測试基本方法(七)之验收測试

验收測试是在功能測试和系统測试之后进行的,所以验收測试的前提条件是系统或软件产品已通过了内部測试.然后和用户一起验收软件,在真实环境下执行软件,看是否存在与用户需求不一致的问题或违背产品规格书的要求.因为測试人员不可能全然用户实际使用情况,所以软件是否真正满足终于用户的要求.应由用户进行一系列的验收測试. (1)验收測试定义: 检查软件是否符合合同要求,包含需求规格说明.设计规格说明和用户手冊等. (2)測试内容: 易用性測试(用户界面和可用性測试) 兼容性測试(软件兼容性測试.数据共享兼容性測

Cocos2d-x 精灵碰撞检測(方法二)

将"Cocos2d-x 精灵碰撞检測(方法一)" update函数改动一下. 使用精灵boundingBox函数获取直接精灵边界框, 不用自己计算精灵矩形大小了,还比較精确,然后调用intersectsRect计算2个精灵矩形是否存在交集. 代码: void HelloWorld::update(float delta) { //返回精灵边界框 CCRect cr1 = sp1->boundingBox(); CCRect cr2 = sp2->boundingBox();

Linux设置某软件开机自动启动的方法

方法一 将启动命令写到系统启动时会自动调用的脚本中 echo "/usr/local/apache2/bin/apachectl start" >> /etc/rc.d/rc.local 方法二 有些软件源代码包中提供了启动脚本,放到Linux默认的启动脚本目录中 cp /lamp/mysql-5.0.41/support-files/mysql.server /etc/rc.d/init.d/mysqldchown root.root /etc/rc.d/init.d/m