当前位置:文档之家› 白盒测试及用例设计

白盒测试及用例设计

白盒测试白盒测试(White-box Testing,又称逻辑驱动测试,结构测试)是把测试对象看作一个打开的盒子。

利用白盒测试法进行动态测试时,需要测试软件产品的内部结构和处理过程,不需测试软件产品的功能。

白盒测试又称为结构测试和逻辑驱动测试。

白盒测试法的覆盖标准有逻辑覆盖、循环覆盖和基本路径测试。

其中逻辑覆盖包括语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖和路径覆盖。

六种覆盖标准:语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖和路径覆盖发现错误的能力呈由弱至强的变化。

语句覆盖每条语句至少执行一次。

判定覆盖每个判定的每个分支至少执行一次。

条件覆盖每个判定的每个条件应取到各种可能的值。

判定/条件覆盖同时满足判定覆盖条件覆盖。

条件组合覆盖每个判定中各条件的每一种组合至少出现一次。

路径覆盖使程序中每一条可能的路径至少执行一次。

白盒测试也称结构测试或逻辑驱动测试,它是知道产品内部工作过程,可通过测试来检测产品内部动作是否按照规格说明书的规定正常进行,按照程序内部的结构测试程序,检验程序中的每条通路是否都有能按预定要求正确工作,而不顾它的功能,白盒测试的主要方法有逻辑驱动、基路测试等,主要用于软件验证。

"白盒"法全面了解程序内部逻辑结构、对所有逻辑路径进行测试。

"白盒"法是穷举路径测试。

在使用这一方案时,测试者必须检查程序的内部结构,从检查程序的逻辑着手,得出测试数据。

贯穿程序的独立路径数是天文数字。

但即使每条路径都测试了仍然可能有错误。

第一,穷举路径测试决不能查出程序违反了设计规范,即程序本身是个错误的程序。

第二,穷举路径测试不可能查出程序中因遗漏路径而出错。

第三,穷举路径测试可能发现不了一些与数据相关的错误。

白盒测试六种覆盖方法摘要:白盒测试作为测试人员常用的一种测试方法,越来越受到测试工程师的重视。

白盒测试并不是简单的按照代码设计用例,而是需要根据不同的测试需求,结合不同的测试对象,使用适合的方法进行测试。

因为对于不同复杂度的代码逻辑,可以衍生出许多种执行路径,只有适当的测试方法,才能帮助我们从代码的迷雾森林中找到正确的方向。

本文介绍六种白盒子测试方法:语句覆盖、判定覆盖、条件覆盖、判定条件覆盖、条件组合覆盖、路径覆盖。

由于逻辑错误和不正确假设与一条程序路径被运行的可能性成反比。

由于我们经常相信某逻辑路径不可能被执行, 而事实上,它可能在正常的情况下被执行。

由于代码中的笔误是随机且无法杜绝的,因此我们要进行白盒测试。

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

白盒测试是一种测试用例设计方法,盒子指的是被测试的软件,白盒指的是盒子是可视的,你清楚盒子内部的东西以及里面是如何运作的。

白盒的测试用例需要做到:●保证一个模块中的所有独立路径至少被使用一次●对所有逻辑值均需测试●在上下边界及可操作范围内运行所有循环●检查内部数据结构以确保其有效性白盒测试的目的:通过检查软件内部的逻辑结构,对软件中的逻辑路径进行覆盖测试;在程序不同地方设立检查点,检查程序的状态,以确定实际运行状态与预期状态是否一致。

白盒测试的特点:依据软件设计说明书进行测试、对程序内部细节的严密检验、针对特定条件设计测试用例、对软件的逻辑路径进行覆盖测试。

白盒测试的实施步骤:1.测试计划阶段:根据需求说明书,制定测试进度。

2.测试设计阶段:依据程序设计说明书,按照一定规范化的方法进行软件结构划分和设计测试用例。

3.测试执行阶段:输入测试用例,得到测试结果。

4.测试总结阶段:对比测试的结果和代码的预期结果,分析错误原因,找到并解决错误。

白盒测试的方法:总体上分为静态方法和动态方法两大类。

静态分析是一种不通过执行程序而进行测试的技术。

静态分析的关键功能是检查软件的表示和描述是否一致,没有冲突或者没有歧义。

动态分析的主要特点是当软件系统在模拟的或真实的环境中执行之前、之中和之后, 对软件系统行为的分析。

动态分析包含了程序在受控的环境下使用特定的期望结果进行正式的运行。

它显示了一个系统在检查状态下是正确还是不正确。

在动态分析技术中,最重要的技术是路径和分支测试。

下面要介绍的六种覆盖测试方法属于动态分析方法。

白盒测试的优缺点1、优点●迫使测试人员去仔细思考软件的实现●可以检测代码中的每条分支和路径●揭示隐藏在代码中的错误●对代码的测试比较彻底●最优化2、缺点●昂贵●无法检测代码中遗漏的路径和数据敏感性错误●不验证规格的正确性六种覆盖方法首先为了下文的举例描述方便,这里先给出一张程序流程图。

(本文以1995年软件设计师考试的一道考试题目为例,图中红色字母代表程序执行路径)。

1、语句覆盖1)主要特点:语句覆盖是最起码的结构覆盖要求,语句覆盖要求设计足够多的测试用例,使得程序中每条语句至少被执行一次。

2)用例设计:(如果此时将A路径上的语句1—〉T去掉,那么用例如下)3)优点:可以很直观地从源代码得到测试用例,无须细分每条判定表达式。

4)缺点:由于这种测试方法仅仅针对程序逻辑中显式存在的语句,但对于隐藏的条件和可能到达的隐式逻辑分支,是无法测试的。

在本例中去掉了语句1—〉T去掉,那么就少了一条测试路径。

在if结构中若源代码没有给出else后面的执行分支,那么语句覆盖测试就不会考虑这种情况。

但是我们不能排除这种以外的分支不会被执行,而往往这种错误会经常出现。

再如,在Do-While结构中,语句覆盖执行其中某一个条件分支。

那么显然,语句覆盖对于多分支的逻辑运算是无法全面反映的,它只在乎运行一次,而不考虑其他情况。

2、判定覆盖1)主要特点:判定覆盖又称为分支覆盖,它要求设计足够多的测试用例,使得程序中每个判定至少有一次为真值,有一次为假值,即:程序中的每个分支至少执行一次。

每个判断的取真、取假至少执行一次。

23)优点:判定覆盖比语句覆盖要多几乎一倍的测试路径,当然也就具有比语句覆盖更强的测试能力。

同样判定覆盖也具有和语句覆盖一样的简单性,无须细分每个判定就可以得到测试用例。

4)缺点:往往大部分的判定语句是由多个逻辑条件组合而成(如,判定语句中包含AND、OR、CASE),若仅仅判断其整个最终结果,而忽略每个条件的取值情况,必然会遗漏部分测试路径。

3、条件覆盖1)主要特点:条件覆盖要求设计足够多的测试用例,使得判定中的每个条件获得各种可能的结果,即每个条件至少有一次为真值,有一次为假值。

2)用例设计:3)优点:显然条件覆盖比判定覆盖,增加了对符合判定情况的测试,增加了测试路径。

4)缺点:要达到条件覆盖,需要足够多的测试用例,但条件覆盖并不能保证判定覆盖。

条件覆盖只能保证每个条件至少有一次为真,而不考虑所有的判定结果。

4、判定/条件覆盖1)主要特点:设计足够多的测试用例,使得判定中每个条件的所有可能结果至少出现一次,每个判定本身所有可能结果也至少出现一次。

2)用例设计:3)优点:判定/条件覆盖满足判定覆盖准则和条件覆盖准则,弥补了二者的不足。

4)缺点:判定/条件覆盖准则的缺点是未考虑条件的组合情况。

5、组合覆盖:1)主要特点:要求设计足够多的测试用例,使得每个判定中条件结果的所有可能组合至少出现一次。

2)用例设计:3)优点:多重条件覆盖准则满足判定覆盖、条件覆盖和判定/条件覆盖准则。

更改的判定/条件覆盖要求设计足够多的测试用例,使得判定中每个条件的所有可能结果至少出现一次,每个判定本身的所有可能结果也至少出现一次。

并且每个条件都显示能单独影响判定结果。

4)缺点:线性地增加了测试用例的数量。

6、路径覆盖1)主要特点:设计足够的测试用例,覆盖程序中所有可能的路径。

23)优点:这种测试方法可以对程序进行彻底的测试,比前面五种的覆盖面都广。

4)缺点:由于路径覆盖需要对所有可能的路径进行测试(包括循环、条件组合、分支选择等),那么需要设计大量、复杂的测试用例,使得工作量呈指数级增长。

而在有些情况下,一些执行路径是不可能被执行的,如:If (!A)B++;If (!A)D--;这两个语句实际只包括了2条执行路径,即A为真或假时候对B和D的处理,真或假不可能都存在,而路径覆盖测试则认为是包含了真与假的4条执行路径。

这样不仅降低了测试效率,而且大量的测试结果的累积,也为排错带来麻烦。

总结白盒测试是一种被广泛使用的逻辑测试方法,是由程序内部逻辑驱动的一种单元测试方法。

只有对程序内部十分了解才能进行适度有效的白盒测试。

但是贯穿在程序内部的逻辑存在着不确定性和无穷性,尤其对于大规模复杂软件。

因此我们不能穷举所有的逻辑路径,即使穷举也未必会带来好运(穷举不能查出程序逻辑规则错误,不能查出数据相关错误,不能查出程序遗漏的路径)。

那么正确使用白盒测试,就要先从代码分析入手,根据不同的代码逻辑规则、语句执行情况,选用适合的覆盖方法。

任何一个高效的测试用例,都是针对具体测试场景的。

逻辑测试不是片面的测试正确的结果或是测试错误的结果,而是尽可能全面地覆盖每一个逻辑路径用例设计一、白盒测试根据软件产品的内部工作过程,在计算机上进行测试,以证实每种内部操作是否符合设计规格要求,所有内部成分是否已经过检查。

这种测试方法就是白盒测试。

白盒测试把测试对象看做一个打开的盒子,允许测试人员利用程序内部的逻辑结构及有关信息,设计或选择测试用例,对程序所有逻辑路径进行测试。

通过在不同点检查程序的状态,确定实际的状态是否与预期的状态一致。

不论是黑盒测试,还是白盒测试,都不可能把所有可能的输入数据都拿来进行所谓的穷举测试。

因为可能的测试输入数据数目往往达到天文数字。

下面让我们看两个例子。

假设一个程序P有输入X和Y及输出Z,参看图10-4-1。

在字长为32位的计算机上运行。

如果X 、Y只取整数,考虑把所有的X 、Y值都做为测试数据,按黑盒测试方法进行穷举测试,力图全面、无遗漏地“挖掘”出程序中的所有错误。

这样做可能采用的测试数据组(Xi,Yi)的最大可能数目为:。

如果程序P测试一组X、Y数据需要 1毫秒,且一天工作24小时,一年工作365天,要完成264组测试,需要5亿年。

图 10-4-1 黑盒子而对一个具有多重选择和循环嵌套的程序,不同的路径数目也可能是天文数字。

设给出一个如图 10-4-2所示的小程序的流程图,其中包括了一个执行达20次的循环。

那么它所包含的不同执行路径数高达条,若要对它进行穷举测试,覆盖所有的路径。

假使测试程序对每一条路径进行测试需要1毫秒,同样假定一天工作24小时,一年工作365 天,那么要想把如图 10-4-2所示的小程序的所有路径测试完,则需要3170年。

图 10-4-2 白盒测试中的穷举测试以上的分析表明,实行穷举测试,由于工作量过大,实施起来是不现实的。

相关主题