基于新信息技术的软件测试技术 课件 第4章 白盒测试

第4章白盒测试4.1白盒测试简介4.2白盒测试过程4.3白盒测试任务4.4逻辑覆盖4.5逻辑覆盖测试用例设计举例4.6基本路径测试法则

4.1白盒测试简介

白盒测试又称结构测试、透明盒测试、逻辑驱动测试、基于代码的测试。其中，盒子指被测试的软件，白盒指盒子是可视的。白盒测试是一种测试用例设计方法，测试人员依据程序内部逻辑结构相关信息，设计或选择测试用例。白盒测试主要针对被测程序的源代码，主要用于软件验证，不考虑软件的功能实现，只验证内部动作是否按照设计说明书的规定进行。

1．白盒测试的目的

其测试目的如下：

(1)保证一个模块中的所有独立路径至少被使用一次。

(2)对所有逻辑值均需测试TRUE和FALSE。

(3)在上下边界及可操作范围内运行所有循环。

(4)检查内部数据结构以确保其有效性。

2．白盒测试的特点

白盒测试的优点如下：

(1)迫使测试人员去仔细思考软件的实现。

(2)可检测代码中的每条分支和路径。

(3)可揭示隐藏在代码中的错误。

(4)对代码的测试比较彻底。

(5)最优化。

白盒测试的缺点如下：

(1)昂贵。

(2)无法检测代码中遗漏的路径和数据敏感性错误。

(3)不验证规格的正确性。

3．白盒测试的实施步骤

(1)测试计划阶段：根据需求说明书，制定测试进度。

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

(3)测试执行阶段：输入测试用例，得到测试结果。

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

4．白盒测试的方法

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

静态分析是一种不通过执行程序而进行测试的技术。静态分析的关键功能是检查软件的表示和描述是否一致，没有冲突或者没有歧义。

动态分析的主要特点是当软件系统在模拟的或真实的环境中执行之前、之中和之后，对软件系统行为进行分析。动态分析包含了程序在受控的环境下使用特定的期望结果进行正式的运行。它显示了一个系统在检查状态下是正确还是不正确。在动态分析技术中，最重要的技术是路径和分支测试。后面要介绍的六种覆盖测试方法属于动态分析方法。

4.2白盒测试过程

应为测试模块开发一个驱动模块(Driver)和若干个桩模块(Stub)，图4.1给出了一般白盒测试的环境。驱动模块在大多数场合称为“主程序”，它接收测试数据并将这些数据传递到被测试模块，被测试模块被调用后，“主程序”打印“进入/退出”消息。

图4.1白盒测试环境

驱动模块和桩模块是测试使用的软件，而不是软件产品的组成部分，但它需要一定的开发费用。若驱动模块和桩模块比较简单，实际开销相对低些。遗憾的是，仅用简单的驱动模块和桩模块不能完成某些模块的测试任务，这些模块的白盒测试只能采用下面讨论的综合测试方法。

提高模块的内聚度可简化单元测试，如果每个模块只能完成一个，则所需测试用例数目将显著减少，模块中的错误也更容易被发现。

4.3白盒测试任务

白盒测试的任务主要包括以下几个方面。

1．模块接口测试模块接口测试是白盒测试的基础。只有在数据能正确流入、流出模块的前提下，其他测试才有意义。测试接口正确与否应该考虑下列因素：(1)输入的实际参数与形式参数的个数是否相同；(2)输入的实际参数与形式参数的属性是否匹配；(3)输入的实际参数与形式参数的量纲是否一致；

(4)调用其他模块时所给实际参数的个数是否与被调模块的形参个数相同；

(5)调用其他模块时所给实际参数的属性是否与被调模块的形参属性匹配；

(6)调用其他模块时所给实际参数的量纲是否与被调模块的形参量纲一致；

(7)调用预定义函数时所用参数的个数、属性和次序是否正确；

(8)是否存在与当前入口点无关的参数引用；

(9)是否修改了只读型参数；

(10)对全程变量的定义各模块是否一致；

(11)是否把某些约束作为参数传递。

如果模块内包括外部输入/输出，还应该考虑下列因素：

(1)文件属性是否正确；

(2) OPEN/CLOSE语句是否正确；

(3)格式说明与输入/输出语句是否匹配；

(4)缓冲区大小与记录长度是否匹配；

(5)文件使用前是否已经打开；

(6)是否处理了文件尾；

(7)是否处理了输入/输出错误；

(8)输出信息中是否有文字性错误。

2．模块局部数据结构测试

检查局部数据结构是为了保证临时存储在模块内的数据在程序执行过程中完整、正确。局部数据结构往往是错误的根源，应仔细设计测试用例，力求发现下面几类错误：

(1)不合适或不相容的类型说明；

(2)变量无初值；

(3)变量初始化或缺省值有错；

(4)不正确的变量名(拼错或不正确的截断)；

(5)出现上溢、下溢和地址异常。

3．模块边界条件测试

除了局部数据结构外，如果可能，单元测试时还应该查清全局数据(例如FORTRAN的公用区)对模块的影响。

4．模块中所有独立执行通路测试

在模块中应对每一条独立执行路径进行测试，白盒测试的基本任务是保证模块中每条语句至少执行一次。设计测试用例是为了发现因错误计算、不正确的比较和不适当的控制流造成的错误。基本路径测试和循环测试是最常用且最有效的测试技术。

计算中常见的错误包括：

(1)误解或用错了运算符优先级；

(2)混合类型运算；

(3)变量初值错；

(4)精度不够；

(5)表达式符号错。

比较判断与控制流常常紧密相关，测试用例还应致力于发现下列错误：

(1)不同数据类型的对象之间进行比较；

(2)错误地使用逻辑运算符或优先级；

(3)因计算机表示的局限性，期望理论上相等而实际上不相等的两个量相等；

(4)比较运算或变量出错；

(5)循环终止条件或不可能出现；

(6)迭代发散时不能退出；

(7)错误地修改了循环变量。

5．模块的各条错误处理通路测试

一个好的设计应能预见各种出错条件，并预设各种出错处理通路。出错处理通路同样需要认真测试，测试应着重检查下列问题：

(1)输出的出错信息难以理解；

(2)记录的错误与实际遇到的错误不相符；

(3)在程序自定义的出错处理段运行之前，系统已介入；

(4)异常处理不当；

(5)错误陈述中未能提供足够的定位出错信息。

4.4逻辑覆盖

4.4.1覆盖率的概念覆盖率是用于度量测试完整性的一个手段。覆盖率的种类有很多，经常接触到的覆盖率是逻辑覆盖。现在有越来越多的测试工具能够支持测试的覆盖率度量。但是，这些度量本身并不包含测试技术，它们只是测试技术有效性的一个度量。

覆盖率可以通过一个比率公式来表示：

公式中的“项”视不同情况而定，对于具体准则可定义它的语义。

4.4.2逻辑覆盖测试法

为了下文的举例描述方便，这里先给出一张程序流程图，如图4.2所示。图4.2程序流程图

1．语句覆盖

1)主要特点

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

(1)优点：可以很直观地从源代码得到测试用例，无需细分每条判定表达式。

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

2)用例设计

如果此时将A路径上的语句1→T去掉，那么用例如表4-1所示。

2．判定覆盖

1)主要特点

判定覆盖又称为分支覆盖，它要求设计足够多的测试用例，使得程序中每个判定至少有一次为真值，有一次为假值，即程序中的每个分支至少执行一次。每个判断的取真、取假至少执行一次。

(1)优点：判定覆盖比语句覆盖要多几乎一倍的测试路径，当然也就具有比语句覆盖更强的测试能力。同样，判定覆盖也和语句覆盖一样简捷，无需细分每个判定就可以得到测试用例。

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

2)用例设计

判定覆盖测试用例如表4-2所示。

3．条件覆盖

1)主要特点

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

(1)优点：条件覆盖比判定覆盖增加了对符合判定情况的测试及测试路径。

(2)缺点：要达到条件覆盖，需要足够多的测试用例，但条件覆盖并不能保证判定覆盖。条件覆盖只能保证每个条件至少有一次为真，而不考虑所有的判定结果。

2)用例设计

条件覆盖测试用例如表4-3所示。

4．判定/条件覆盖

1)主要特点

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

(1)优点：判定/条件覆盖满足判定覆盖准则和条件覆盖准则，弥补了二者的不足。

(2)缺点：判定/条件覆盖准则未考虑条件的组合情况。

2)用例设计

判定/条件覆盖测试用例如表4-4所示。

5．组合覆盖

1)主要特点

组合覆盖也叫做条件组合覆盖，要求设计足够多的测试用例，使得每个判定中条件结果的所有可能组合至少出现一次。

(1)优点：条件组合覆盖能够同时满足判定、条件和判定/条件覆盖，覆盖率较高。

(2)缺点：线性地增加了测试用例的数量。

2)用例设计

组合覆盖测试用例如表4-5所示。

6．路径覆盖

1)主要特点

路径覆盖要求设计足够多的测试用例，以覆盖程序中所有可能的路径。

(1)优点：这种测试方法可以对程序进行彻底的测试，比前面5种的覆盖面都广。

(2)缺点：由于路径覆盖需要对所有可能的路径进行测试(包括循环、条件组合、分支选择等)，那么需要设计大量、复杂的测试用例，使得工作量呈指数级增长。而在有些情况下，一些执行路径是不可能被执行的，如：

2)用例设计

路径覆盖测试用例如表4-6所示。

4.5逻辑覆盖测试用例设计举例

在覆盖率测试中我们将使用一个计算器的程序示例，该程序用C++语言编写，实现整数与浮点数的四则运算功能，其界面如图4.3所示。图4.3计算器的程序示例界面

1．测试环境

1)硬件

普通PC；

CPU：酷睿i3；

内存：2GB；

硬盘：1TB。

2)软件

操作系统：Windows2003Professional中文版；

编译系统：VisualStudio7.0。

2．测试工具

我们使用AppliedMicrosystemsCorporation公司的CodeTest3.5作为测试工具，但由于篇幅所限，将针对其中的一个主要函数“CCacl2Dlg::OnGo()”设计测试用例，该函数响应用户点击按钮“=”的操作，完成计算功能。

4.5.1测试用例设计

测试用例的步骤如下：

1．以源代码为基础，导出程序的控制流图

根据源代码，导出如图4.4所示的控制流图。

图4.4控制流图1

2．计算得到的控制流图G的环路复杂性V(G)

利用在前面给出的计算控制流图环路复杂性的方法，可以算出

V(G) = 22(区域数) = 21(判断节点数) + 1 = 22

3．确定线性无关的路径的基本集

将图4.4中所示的各节点加入对应编号，得到如图4.5所示的控制流图。

图4.5控制流图2

其中节点1、2、4、6、8、11、12、14、16、18、21、23、25、27、29、32、33、35、37、39和41为判断节点，节点编号与判断表达式对应关系如表4-7所示。

由图4-5可知，22条线性无关的基本路径为表4-8所示的路径。

4．生成测试用例，确保基本路径集中每条路径的执行

根据各路径的执行过程，得到各判断节点取值，如表4-9所示。

根据表4-9和图4-5，可以得到各判断节点中各子条件的取值，如表4-10所示(T代表TRUE，F代表FALSE)。

4.5.2测试结果分析

按照表4-10设计测试用例并进行测试后，对其代码覆盖结果进行分析，得出如下结果：当完成100%的路径覆盖时，将同时实现100%的语句判定、逻辑判定、条件判定和条件判定组合覆盖；在测试路径16时，如果将表中所列的4种输入条件都设计出测试用例，还将同时实现100%的多条件覆盖和多条件判定组合覆盖。

4.6基本路径测试法

4.6.1基本路径测试法简介基本路径测试法包括4个步骤，即画出控制流图、计算圈复杂度、导出独立路径和设计测试用例。在程序控制流图的基础上，通过分析程序的环路复杂性，导出基本可执行路径集合，从而设计测试用例。设计出的测试用例要保证在测试中程序的每个可执行路径至少执行一次。

4.6.2基本路径测试法举例

例有下面的C函数，用基本路径测试法进行测试，程序流程图如图4.6所示。图4.6程序流程图

1．画出控制流图

可将流程图映射到一个相应的流图。

程序的控制流图是对程序流程图的简化，它可以更加突出地描述程序控制流的结构。流图只有两种图形符号：圆圈和箭头。圆圈称为流图的节点，代表一个或多个语句，流程图中一个处理方框或一个菱形判断框可被映射为一个节点。箭头称为边或连接，代表控制流，类似于流程图中的箭头。一条边必须终止于一个节点，即使该节点并不代表任何语句。由边和节点限定的范围称为区域，计算区域时应包括图外部的范围，如图4.7所示。图4.7控制流图

如果判断中的条件表达式是由一个或多个逻辑运算符(or、and)连接的复合条件表达式，则要为每个条件创建一个独立的节点，包含条件的节点被称为判定节点，一个判定节点发出两条或多条边。例如：