白盒测试_白盒测试工具 - CSDN
白盒测试 订阅
白盒测试又称结构测试、透明盒测试、逻辑驱动测试或基于代码的测试。白盒测试是一种测试用例设计方法,盒子指的是被测试的软件,白盒指的是盒子是可视的,即清楚盒子内部的东西以及里面是如何运作的。"白盒"法全面了解程序内部逻辑结构、对所有逻辑路径进行测试。"白盒"法是穷举路径测试。在使用这一方案时,测试者必须检查程序的内部结构,从检查程序的逻辑着手,得出测试数据。贯穿程序的独立路径数是天文数字。 [1] 展开全文
白盒测试又称结构测试、透明盒测试、逻辑驱动测试或基于代码的测试。白盒测试是一种测试用例设计方法,盒子指的是被测试的软件,白盒指的是盒子是可视的,即清楚盒子内部的东西以及里面是如何运作的。"白盒"法全面了解程序内部逻辑结构、对所有逻辑路径进行测试。"白盒"法是穷举路径测试。在使用这一方案时,测试者必须检查程序的内部结构,从检查程序的逻辑着手,得出测试数据。贯穿程序的独立路径数是天文数字。 [1]
信息
主要类别
测试
外文名
white-box testing
别    称
结构测试、透明盒测试
释    义
一种测试用例设计方法
中文名
白盒测试
白盒测试简介
白盒测试的测试方法有代码检查法、静态结构分析法、静态质量度量法、逻辑覆盖法、基本路径测试法、域测试、符号测试、路径覆盖和程序变异。 [1]  白盒测试法的覆盖标准有逻辑覆盖、循环覆盖和基本路径测试。其中逻辑覆盖包括语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖和路径覆盖。六种覆盖标准发现错误的能力呈由弱到强的变化: [1]  1.语句覆盖每条语句至少执行一次。 [1]  2.判定覆盖每个判定的每个分支至少执行一次。 [1]  3.条件覆盖每个判定的每个条件应取到各种可能的值。 [1]  4.判定/条件覆盖同时满足判定覆盖条件覆盖。 [1]  5.条件组合覆盖每个判定中各条件的每一种组合至少出现一次。 [1]  6.路径覆盖使程序中每一条可能的路径至少执行一次。 [1] 
收起全文
精华内容
参与话题
  • 白盒测试教程_详细教程

    热门讨论 2020-07-30 23:32:53
    白盒测试也称结构测试或逻辑驱动测试,是一种测试用例设计方法,它从程序的控制结构导出测试用例。(测试用例由测试输入数据以及与之对应的输出结果组成。 测试用例设计的好坏直接决定了测试的效果和结果。所以说在...
  • 白盒测试及用例详解

    万次阅读 多人点赞 2020-06-10 22:30:40
    今天复习到白盒测试,就上网找了一下,重新学习一下 做个记录,以后也会用得着吧 在白盒测试中,逻辑覆盖测试是使用较多的方法。按照其对测试的有效程度,又将其划分为由弱到强的6种:语句覆盖、判定覆盖、条件...

    目录

    第一部分:概念理解

    第二部分:上例题

    第三部分:例题解答

    附:纸质版解答过程

    参考链接


    第一部分:概念理解

    在白盒测试中,逻辑覆盖测试是使用较多的方法。按照其对测试的有效程度,又将其划分为由弱到强的6种:语句覆盖、判定覆盖、条件覆盖、判定-条件覆盖、条件组合覆盖、路径覆盖。

    详细看下图的分类:




    第二部分:上例题

    实践是检验真理的唯一标准,下面用一道例题,来巩固和学习上面的几种逻辑覆盖方法。

    源代码:

    public void function(int a, int b, int c)
    {
        if ((a > 1) && (b == 0))
        {
            c /= a;
        }
        if ((a == 5) || (c > 1))
        {
            c += 1;
        }
        c = a + b + c;
    }

    程序流程图:

    图中A、B、C、D、E分别表示路径;并且记第一个判断为P1,记第二个判断为P2;一共有4个条件,我们记为C1:a>1、C2:b=0、C3:a=5、C4:c>1。




    第三部分:例题解答

    根据上面例子来看看如何写出6种覆盖的测试用例。

    语句覆盖

    测试数据 C1 C2 C3 C4 P1 P2 路径
    a=5,b=0,c=6         T T A→C→E

    判定覆盖(也叫分支覆盖)

    测试数据 C1 C2 C3 C4 P1 P2 路径
    a=2,b=0,c=1         T F A→C→D
    a=0,b=1,c=2         F T A→B→E

     条件覆盖

    测试数据 C1 C2 C3 C4 P1 P2 路径
    a=5,b=0,c=1 T T T F     A→C→E
    a=1,b=3,c=6 F F F T     A→B→E

    判定-条件覆盖(也叫条件-分支覆盖)

    测试数据 C1 C2 C3 C4 P1 P2 路径
    a=2,b=0,c=1 T T F F T F A→C→D
    a=5,b=1,c=10 F F T T F T A→B→E

    条件组合覆盖

    测试数据 C1 C2 C3 C4 P1 P2 路径
    a=5,b=0,c=4 T T T F     A→C→E
    a=2,b=1,c=5 T F T T     A→B→E
    a=0,b=0,c=2 F T F T     A→B→E
    a=-1,b=1,c=-1 F F F F     A→B→D

    路径覆盖

    测试数据 C1 C2 C3 C4 P1 P2 路径
    a=1,b=1,c=1         F F A→B→D
    a=1,b=0,c=6         F T A→B→E
    a=2,b=0,c=1         T F A→C→D
    a=5,b=0,c=10         T T A→C→E

    附:纸质版解答过程

    参考链接

    参考例子和我的解答,你一定可以弄的清楚明白的。还有就是,最好自己动手做一做。

    参考博客1:https://blog.csdn.net/liujian619/article/details/45270813

    参考博客2:https://blog.csdn.net/u011032983/article/details/52123426

    如果想对软件测试这门课有更系统的认识,可以参考我的另一篇博文

    展开全文
  • 一、什么是白盒测试白盒测试也称结构测试或逻辑驱动测试,通过分析被测组件内部工作原理,通过测试来检测被测组件内部的运行是否符合产品规格说明书的规定 对应于黑盒测试,白盒测试要求测试人员打开软件...

    一、什么是白盒测试?

    白盒测试也称结构测试或逻辑驱动测试,通过分析被测组件内部工作原理,通过测试来检测被测组件内部的运行是否符合产品规格说明书的规定

    对应于黑盒测试,白盒测试要求测试人员打开软件黑盒,去了解开发人员的代码实现细节,这些细节包括数据流和控制流

    (1)数据流方面:进出组件的数据是否能被正确地处理、组件中用于计算使用的数据是否被正确使用、是否有冗余、其数据类型是否运用得当
    (2)控制流方面:程序中的每一条代码是否都有意义、程序中是否有无法被执行到的语句、程序中的判定是否正确、程序中的各条路径是否正确

    二、为什么要做白盒测试?

    1.白盒测试是高效的测试

    白盒测试不仅发现问题,还可以定位问题和解决问题,效率较高

    2.白盒测试可以彻底解决编码阶段引入的问题

    三、在软件生命周期的那些测试阶段中会用到白盒测试?

    单元测试阶段

    因为单元测试阶段是产品开发的早期阶段,在此阶段,使用白盒测试来测试程序是否正确,可以尽早的发现产品的缺陷,节约产品开发成本

    四、白盒测试的优点

    1.帮助软件测试人员,增大代码的覆盖率
    2.提高代码的质量

    因为白盒测试可以发现代码中存在的问题

    五、白盒测试的缺点

    1.程序在运行时,会有很多条路径,白盒测试并不能把所有路径都全部测试
    2.测试基于代码,只会测试开发人员写的代码是否正确,并不知道产品设计是否正确,所以会漏掉一些功能需求
    3.当测试的系统庞大时,测试开销大

    六、白盒测试的测试方法都有那些?

    1.语句测试
    2.分支/判定测试
    3.条件测试
    (1)条件分支测试
    (2)条件分支组合测试
    (3)修正条件判定测试
    4.数据流测试
    5.基本路径测试

    展开全文
  • 白盒测试

    千次阅读 2019-06-09 16:34:17
    白盒测试又称结构测试、透明盒测试、逻辑驱动测试或基于代码的测试。 白盒测试法的覆盖标准有逻辑覆盖、循环覆盖和基本路径测试。其中逻辑覆盖包括语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖和路径...

    白盒测试又称结构测试、透明盒测试、逻辑驱动测试或基于代码的测试。

    白盒测试法的覆盖标准有逻辑覆盖、循环覆盖和基本路径测试。其中逻辑覆盖包括语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖和路径覆盖。六种覆盖标准发现错误的能力呈由弱到强的变化:

    语句覆盖: 每条语句至少执行一次。在代码中只包含if而没有对应的else时测试用例可能只考虑执行if的情况。

    判断覆盖: 每个判定的每个分支至少执行一次。只考虑了判断语句的最终结果,而忽略了条件本身在执行过程中的变化。

    条件覆盖: 每个判定的每个条件应取到各种可能的值。只要求每个条件的真假都出现而对判断语句的真假没有做出要求,不能保证判断覆盖。

    判定/条件覆盖: 同时满足判定覆盖条件覆盖。判断中每个条件的所有可能结果至少出现一次,每个判定本身所有可能结果也至少出现一次。

    条件组合覆盖: 每个判定中各条件的每一种组合至少出现一次。线性的增加了用例的数量。

    路径覆盖: 程序中每一条可能的路径至少执行一次。使工作量呈指数级增长,在一定情况下执行路径使不可能被执行的。

    if(!lflag)
    	x++;
    if(!flag)
    	f--;
    

    路径覆盖认为包含了四条路径,而实际上只包含了两条路径。

    但即使每条路径都测试了仍然可能有错误。可能出现的情况如下:

    1. 穷举路径测试决不能查出程序违反了设计规范,即程序本身是个错误的程序。
    2. 穷举路径测试不可能查出程序中因遗漏路径而出错。
    3. 穷举路径测试可能发现不了一些与数据相关的错误。
    展开全文
  • 常见的几种白盒测试

    千次阅读 2019-09-16 22:47:03
    于是我去网上转了一圈,看了一些资料,大概搞明白了那几种常见的白盒测试是咋回事,特此记录。 目前我所了解到的逻辑覆盖(而非路径覆盖)型的白盒测试大概有这几种: SC,语句覆盖 DC,决策覆盖(也译作判定覆盖...

    2019.6.26 补充与修正了短路相关的内容。
    2019.9.16 修正了短路部分的错误,顺便去掉了用词不合适的前言


    目前我所了解到的逻辑覆盖(而非路径覆盖)型的白盒测试大概有这几种:

    1. SC,语句覆盖
    2. DC,决策覆盖(也译作判定覆盖)
    3. CC,条件覆盖(也译作状态覆盖)
    4. C/DC,条件决策覆盖
    5. MC/DC,Modified C/DC,即修正的条件决策覆盖
    6. MCC,Multiple CC,即多重条件覆盖(也译作条件组合覆盖)

    在此之前,困扰我最久的一个问题就是,什么是条件(Condition),什么是决策(Decision)?这个是搞清楚上述六种测试的前置条件(加上后置条件和不变式variant就是契约了,笑)。然后我看到了一个定义:

    Condition is a Boolean expression containing no Boolean operators.

    Decision is a Boolean expression composed of conditions and zero or more Boolean operators.

    简单说来,条件是一个布尔表达式(比如a < b),决策是几个条件用逻辑运算符拼在一起(比如a < b && c < d)。一定要注意,多个表达式用与或非(当然了,还有异或)连接起来,构成的那个整体,是决策而不是条件。我一开始把整体当成了条件,造成了很大的困扰。

    解决了这个定义问题,就来看看这六种逻辑覆盖测试。

    其实我觉得第六种多重条件覆盖MCC,也就是所谓的枚举法,应该是最容易想到的一种方案。要实现逻辑覆盖,我把所有的情况列举一遍,搞个真值表,不就好了吗?

    int count = 0;
    if(a || b) {
        count += 10}
    if(c) {
        count += 20}
    // 测试1:
    // in: a = true, b = true, c = true
    // expect: count = 30
    // 测试2:
    // in: a = true, b = true, c = false
    // expect: count = 10
    // 测试3:
    // in: a = true, b = false, c = true
    // expect: count = 30
    // 测试4:
    // in: a = true, b = false, c = false
    // expect: count = 10
    // 测试5:
    // in: a = false, b = true, c = true
    // expect: count = 30
    // 测试6:
    // in: a = false, b = true, c = false
    // expect: count = 10
    // 测试7:
    // in: a = false, b = false, c = true
    // expect: count = 20
    // 测试8:
    // in: a = false, b = false, c = false
    // expect: count = 0
    

    话虽如此,当条件增加的时候,MCC的复杂度是呈指数上升的,而且考虑到可能存在的短路求值(在这里,只要atrue,就没必要考虑b的取值了),有一些测试其实是无意义的。这不符合工程的理念(完全忽视了成本和效率)。于是,为了向现实妥协,就有了其他几种折衷的方案。

    第一种,语句覆盖SC,顾名思义,就是覆盖每一条语句,让每一条语句都执行一次。当然了,只要都执行一次就行,比如a || b这个表达式,能满足其中一个为真,让决策为真就可以了:

    int count = 0;
    if(a || b) {
        count += 10}
    if(c) {
        count += 20}
    // 测试1:
    // in: a = true, b = false, c = true
    // expect: count = 30
    // 测试2:
    // in: a = true, b = false, c = false
    // expect: count = 10
    

    在这里可以看到,只要a || b为真,就能确保if块里的语句被执行。从这个角度来说,语句覆盖是只考虑真不考虑假的(如果不包括else,如果包括else,为了覆盖肯定是需要考虑为假的情况的)。

    这种覆盖率显然是不行的,表达式为假时有些情况就覆盖不到了,语句覆盖SC并没有考虑决策为假对结果的影响,比如上面的例子中,如果a || b为假,count就是0或者20,但我写测试用例的时候并不会考虑这一点,因为语句实际上都覆盖到了。在这里因为简单,所以不会有什么问题,但规模大了之后,这个决策可能会带来的副作用就会产生不可预知的问题,这种低覆盖率的弊端就会很明显。

    为了解决这个问题,就有了第二种,决策覆盖DC。这也很符合人的认知过程,因为既然表达式为假时有些语句覆盖不到,那我把为假时的情况考虑进去不就行了吗?也就是说,需要同时考虑决策为真和为假时的情况。还用上面那个例子,也就是说,不仅需要考虑a || b为真的情况,还要考虑a || b为假的情况:

    int count = 0;
    if(a || b) {
        count += 10}
    if(c) {
        count += 20}
    // 测试1:
    // in: a = true, b = false, c = true
    // expect: count = 30
    // 测试2:
    // in: a = false, b = false, c = false
    // expect: count = 0
    

    有什么变化吗?似乎并没有。设想很美好,考虑了决策为假的情况,但测试覆盖率好像没什么太大的变化。究其原因,还是决策这个粒度太大了。面向代码的白盒测试应该是细粒度的,这里却有点类似于面向规格的黑盒测试的意味,把粗粒度的决策作为考察对象,不是很合适。所以,就有了第三种,条件覆盖CC。这次,我们把关注点放到了条件上,要覆盖每一个条件为真和为假的情况:

    int count = 0;
    if(a || b) {
        count += 10}
    if(c) {
        count += 20}
    // 测试1:
    // in: a = true, b = true, c = true
    // expect: count = 30
    // 测试2:
    // in: a = false, b = false, c = false
    // expect: count = 0
    

    ……似乎还是没什么变化。因为这次虽然粒度细了,但考虑得很粗,因为有些条件是相互关联的,要进行协作,形成决策,才能看出他们真正的影响,割裂来看还是有点考虑不周。既然如此,那我既覆盖决策,又覆盖条件,这总行了吧?所以,我们有了第四种,条件决策覆盖C/DC:

    int count = 0;
    if(a || b) {
        count += 10}
    if(c) {
        count += 20}
    // 测试1:
    // in: a = true, b = true, c = true
    // expect: count = 30
    // 测试2:
    // in: a = false, b = false, c = false
    // expect: count = 0
    

    为什么还是不行?!这次的思路是对的,但是还是有所疏忽。不知道你发现没有,和开头所说的短路求值一样,虽然同时覆盖了决策和条件,但某些条件的改变并不会影响决策。我们需要考虑的是那些重要的条件,足以影响决策的条件。这不正是软件测试的目的吗?所以,我们有了最后一种,也就是修正的条件决策覆盖MC/DC。这一次,我们在考虑决策和条件的基础上,要求每一个条件都是“重要”的;也就是说,每一个条件的改变,都会影响所在决策的值

    int count = 0;
    if(a || b) {
        count += 10}
    if(c) {
        count += 20}
    // 测试1:
    // in: a = true, b = false, c = true
    // expect: count = 30
    // 测试2:
    // in: a = false, b = true, c = false
    // expect: count = 10
    // 测试3:
    // in: a = false, b = false, c = false
    // expect: count = 0
    

    值得一提的是,改变决策的值,不一定是改变整体的决策值,有可能只是改变它所在的决策的值。比如,对于a && (b || c)的一个测试用例{ TFT }来说,看似第二个条件无关紧要,无论取T还是F都不改变整个决策的值,但它的改变会影响它所在的b || c决策的值啊。无论如何,只要能改变决策,就很“重要”了。

    可以看到,这里的覆盖率有了明显的提高,虽然和MCC比起来还是有所不足,但比起之前的任何一种都要好,而且只增加了一个用例,就提高了25%的覆盖率(2/4->3/4),简直就是成本和性能的完美平衡(笑)。

    这里有一个相对专业的定义:

    Modified Condition/Decision Coverage: every point of entry and exit in the program has been invoked at least once,every condition in the program has taken all possible outcomes at least once,and each condition in a decision has been shown to independently affect a decision.

    而且,还有一个很有意思的细节:MC/DC有类似于短路的实现。对于a && (b || c)这个决策来说,当a为假时,后面的b || c就不那么“重要”了(因为无法影响决策),所以b、c可以随意取值,这样就减少了测试用例的数目,降低了测试成本。当然,这一条可能只是对不包含短路机制的语言有意义,因为包含短路机制的语言会自行处理不“重要”的条件,不需要测试用例亲自出手。

    但短路带来的是测试用例的覆盖问题。因为在触发短路后,后面的状态是没有覆盖到的。举个例子吧,这里我们用-表示随便取什么值。对于a && ( b || c )这个整体的决策来说,如果取测试用例为F–,事实上b、c都是没有覆盖到的。因此,为了实现CC(以及后续的C/DC和MC/DC),就需要增加测试用例。所以,这里无论是C/DC还是MC/DC,测试集都应当取为{ F–, TT-, TFT, TFF }。

    事实上这里不够准确。可以用控制变量的方法,让某个条件成为足以影响决策的重要条件。可能比较合适的TR是{ FT-, TTF, TFT, TFF }。

    事实上,可以利用短路机制将布尔表达式转换成类似于if-else的结构。比如,我们可以把a && b转换成下面的结构:

    if (a) {
    	if (b) {
    		// ...
    	}	
    }	
    

    结束。

    参考资料:

    1. 条件判定覆盖和修正条件判定覆盖
    2. 白盒测试:语句覆盖、条件覆盖、判定覆盖、条件-判定覆盖、组合覆盖、路径覆盖
    展开全文
  • 白盒测试与黑盒测试的联系与区别

    万次阅读 2017-12-20 10:53:38
    简单介绍一下在软件测试过程中白盒测试和黑盒测试的定义,区别,联系,以及各自测试的目的。
  • 白盒测试与黑盒测试的定义与区别

    万次阅读 2014-06-24 19:37:17
    白盒测试方法按照程序内部的结构测试程序,检验程序中的meitiao
  • 白盒测试(white-box Testing,又称逻辑驱动测试,结构测试),它是知道产品内部过程,可通过测试来检测产品内部动作是否按照规格说明书的规定正常进行,按照程序内部的结构测试程序,检验程序中的每条通路是否都有...
  • 三角形- 白盒测试实例

    千次阅读 2014-03-12 22:07:19
    白盒测试实例 1~12: http://blog.csdn.net/aidisheng/article/details/2868709
  • 白盒测试----六种覆盖方法

    万次阅读 多人点赞 2017-12-12 22:44:12
    白盒测试又称结构测试,透明盒测试、逻辑驱动测试或基于代码的测试。白盒测试是一种测试用例设计方法,白盒指的是程序的内部结构和运作机制是可见的。白盒测试的目的: 通过检查软件内部的逻辑结构,对软件中的...
  • 黑盒测试和白盒测试区别

    万次阅读 2017-08-01 09:15:26
    一、黑盒测试和白盒测试  黑盒测试:已知产品的功能设计规格,可以进行测试证明每个实现了的功能是否符合要求。 白盒测试:已知产品的内部工作过程,可以进行测试证明每种内部操作是否符合设计规格要求,所有...
  • 白盒测试和黑盒测试的优缺点

    万次阅读 2013-11-19 10:40:22
    白盒测试和黑盒测试是软件测试的两种基本方法   =================================黑盒测试===========================================  1. 黑盒测试的优点有 : 1) 比较简单,不需要了解程序的内部的代码及...
  • 白盒测试技术

    千次阅读 2010-02-08 13:46:00
    白盒测试技术作者:张元礼http://blog.csdn.net/vincetest 目 录Chapter 1 白盒测试理论1.1 白盒测试概念1.2 白盒测试目的1.3 白盒测试范围1.4 白盒测试发展Chapter 2 单元测试理论2.1 单元测试概念2.2 单元测试...
  • 白盒测试与黑盒测试的比较

    千次阅读 2017-05-30 21:24:07
    白盒测试是穷举路径测试,黑盒测试是穷举输入测试,这两种方法是基于完全不同的观点,反应了事物的两个极端,它们各有侧重和优势,但不能彼此替代。在现代的测试理念中,这两种测试方法不是截然分开的,而是交叉使用...
  • 白盒测试用例设计练习(一)

    万次阅读 2018-01-19 20:54:29
    【图 1.1】 1、语句覆盖 请给出【图 1.1】的语句覆盖用例  a)主要特点:使程序中的每个可执行语句至少被执行一次。  b) 用例设计 ...【图 1.2】
  • 黑盒测试、白盒测试和灰盒测试的基本概念作者:Aken1. 黑盒测试 黑盒测试也称功能测试或数据驱动测试,它是在已知产品所应具有的功能,通过测试来检测每个功能是否都能正常使用,在测试时,把程序看作一个不能打开...
  •  渗透测试的两种基本类型:白盒测试与黑盒测试。白盒测试,有时也被称为“白帽测试”,是指渗透测试者在拥有客户组织所有知识的情况下所进行的测试;黑盒测试则设计为模拟一个对客户组织一无所知的攻击者所进行的...
  • 白盒测试方法和工具

    万次阅读 2016-08-28 20:29:53
    1. 白盒测试 白盒测试又称结构测试、逻辑驱动测试或基于程序本身的测试。测试者把被测程序看成一个盒子,而这个盒子是打开着的,以程序的内容来设计测试数据。采用这种测试方法,测试人员对被测试程序的内部结构...
  • 白盒测试方法和黑盒测试方法

    千次阅读 2018-03-04 13:08:14
    本文摘自kerryzhu测试方法的辩证统一 http://blog.csdn.net/KerryZhu/article/details/763181,感谢原创作者 白盒测试方法和黑盒测试方法黑盒测试方法,不考虑程序内部结构和内部特性,而是从用户观点出发,针对...
  • 黑盒测试与白盒测试的优缺点

    千次阅读 2018-08-12 08:54:56
    ※ 黑盒测试的优点: 比较简单,不需要了解程序内部的代码及实现; 与软件的内部实现无关; 从用户角度出发,能很容易的知道用户会用到哪些功能,会遇到哪些问题; 基于软件开发文档,...※ 白盒测试的优点: ...
1 2 3 4 5 ... 20
收藏数 29,294
精华内容 11,717
关键字:

白盒测试