白盒测试

百科名片

  

白盒测试

白盒测试也称结构测试或逻辑驱动测试，它是按照程序 内部的结构测试程序 ，通过测试来检测产品内部动作是否按照设计规格说明书的规定正常进行，检验程序中的每条通路是否都能按预定要求正确工作。 这一方法是把测试对象 看作一个打开的盒子，测试人员依据程序内部逻辑结构相关信息，设计或选择测试用例 ，对程序所有逻辑路径进行测试，通过在不同点检查程序的状态，确定实际的状态是否与预期的状态一致。

目录

概述

如何挑选工具

基本路径测试法

三步法

与黑盒测试区别

展开

概述

　　采用什么方法对软件 进行测试呢？常用的软件测试 方法有两大类：静态测试 方法和动态测试 方法。其中软件的静态测试不要求在计算机上实际执行所测程序 ，主要以一些人工的模拟技术对软件进行分析和测试；而软件的动态测试是通过输入一组预先按照一定的测试准则构造的实例数据来动态运行程序，而达到发现程序错误 的过程。 　　白盒测试的测试方法有代码 检查法、静态结构分析法、静态质量度量法、逻辑覆盖 法、基本路径测试法、域测试、符号测试、Z路径覆盖、程序变异。 　　白盒测试法的覆盖标准有逻辑覆盖、循环覆盖和基本路径测试。其中逻辑覆盖包括语句覆盖、判定覆盖 、条件覆盖、判定/条件覆盖、条件组合覆盖 和路径覆盖。 　　六种覆盖标准：语句覆盖、判定覆盖、条件覆盖 、 判定/条件覆盖、条件组合覆盖和路径覆盖发现错误的能力呈由弱至强的变化。语句覆盖每条语句至少执行一次。判定覆盖每个判定的每个分支至少执行一次。条件 覆盖每个判定的每个条件应取到各种可能的值。判定/条件覆盖同时满足判定覆盖条件覆盖。条件组合覆盖每个判定中各条件的每一种组合至少出现一次。路径覆盖 使程序中每一条可能的路径至少执行一次。 　　"白盒"法全面了解程序内部逻辑结构、对所有逻辑路径进行测试。"白盒"法是穷举路径测试。在 使用这一方案时，测试者必须检查程序的内部结构，从检查程序的逻辑着手，得出测试数据。贯穿程序的独立路径数是天文数字。但即使每条路径都测试了仍然可能 有错误。第一，穷举路径测试决不能查出程序违反了设计规范，即程序本身是个错误的程序。第二，穷举路径测试不可能查出程序中因遗漏路径而出错。第三，穷举 路径测试可能发现不了一些与数据相关的错误。 　　白盒测试，有时称为玻璃盒测试，是一种测试用例设计方法，它使用程 　　序设计的控制结构导出测试用例。使用白盒测试方法，软件工程师能够产生 　　测试用例(1)保证一个模块中的所有独立路径至少被使用一次；(2)对所有逻 　　辑值均需测试true 和 false；(3)在上下边界及可操作范围内运行所有循 　　环；(4)检查内部数据结构以确保其有效性。

如何挑选工具

  

白盒测试

白盒测试目前主要用在具有高可靠性要求的软件领域，例如：军工软件、航天航空软件、工业控制软件等等。白盒测试工具在选购时应当主要是对开发语言的支持、代码覆盖的深度、嵌入式软件 的测试、测试的可视化等。

对开发语言的支持

　　白盒测试工具是对源代码 进行的测试，测试的主要内容包括词法分析 与语法分析、静态错误分析 、动态检测等。但是对于不同的开发语言，测试工具实现的方式和内容差别是较大的。目前测试工具主要支持的开发语言包括：标准C、C＋＋、Visual C＋＋、Java、Visual J＋+等。

代码的覆盖深度

　　从覆盖源程序语句的详尽程度分析，逻辑覆盖标准包括以下不同的覆盖标准：语句覆盖、判定覆盖、条件覆盖、条件判定组合覆盖、多条件覆盖和修正判定条件覆盖 。 　　·语句覆盖 为了暴露程序中的错误，程序中的每条语句至少应该执行一次。因此语句覆盖（Statement Coverage）的含义是：选择足够多的测试数据，使被测程序中每条语句至少执行一次。语句覆盖是很弱的逻辑覆盖。 　　·判定覆盖 比语句覆盖稍强的覆盖标准是判定覆盖（Decision Coverage）。判定覆盖的含义是：设计足够的测试用例 ，使得程序中的每个判定至少都获得一次“真值”或“假值”，或者说使得程序中的每一个取“真”分支和取“假”分支至少经历一次，因此判定覆盖又称为分支覆盖。 　　·条件覆盖 在设计程序 中，一个判定语句是由多个条件组合而成的复合判定。为了更彻底地实现逻辑覆盖，可以采用条件覆盖（Condition Coverage）的标准。条件覆盖的含义是：构造一组测试用例，使得每一判定语句中每个逻辑条件的可能值至少满足一次。 　　·多条件覆盖 多条件覆盖也称条件组合覆盖，它的含义是：设计足够的测试用例，使得每个判定中条件的各种可能组合都至少出现一次。显然满足多条件覆盖的测试用例是一定满足判定覆盖、条件覆盖和条件判定组合覆盖的。 　　·修正条件判定覆盖 修正条件判定覆盖是由欧美的航空/航天制造厂商和使用单位联合制定的“航空运输和装备系统软件认证标准”，目前在国外的国防、航空航天领域应用广泛。这个 覆盖度量需要足够的测试用例来确定各个条件能够影响到包含的判定的结果。它要求满足两个条件：首先，每一个程序模块 的入口和出口点都要考虑至少要被调用一次，每个程序的判定到所有可能的结果值要至少转换一次；其次，程序的判定被分解为通过逻辑操作符（and、or）连接的布尔 条件，每个条件对于判定的结果值是独立的。 　　不同的测试工具对于代码的覆盖能力也是不同的，通常能够支持修正条件判定覆盖的测试工具价格是极其昂贵的。

嵌入式软件的测试

　　对于嵌入式软件的测试，我们还需要一方面进一步考虑测试工具对于嵌入式操作系统 的支持能力，例如DOS、Vxworks、Neculeus、Linux和Windows CE等；另一方面还需要考虑测试工具对于硬件平台的支持能力，包括是否支持所有64/32/16位CPU 和 MCU，是否可以支持 PCI/VME/CPCI 总线。

测试的可视化

　　白盒测试是工作量巨大并且枯燥的工作，可视化的设计对于测试来说是十分重要的。在选购白盒测试工具时，应当考虑该款测试工具的可视化是否良好，例如：测试过程 中是否可以显示覆盖率的函数 分布图和上升趋势图，是否使用不同的颜色区分已执行和未执行的代码段 显示分配内存情况实时图表等，这些对于测试效率和测试质量的提高是具有很大的作用的。

编辑本段 基本路径测试法

　　白盒测试的测试方法有代码检查法、静态结构分析法、静态质量度量法、逻辑覆盖法、基本路径测试法、域测试、符号测试、Z路径覆盖、程序变异。 　　其中运用最为广泛的是基本路径测试法。

简介

　　基本路径测试法是在程序控制流图的基础上，通过分析控制构造的环路复杂性，导出基本可执行路径集合，从而设计测试用例 的方法。 　　设计出的测试用例要保证在测试中程序的每个可执行语句至少执行一次。 　　在程序控制流图的基础上，通过分析控制构造的环路复杂性，导出基本可执行路径集合，从而设计测试用例。包括以下4个步骤和一个工具方法： 　　1. 程序的控制流图：描述程序控制流的一种图示方法。 　　2. 程序圈复杂度：McCabe复杂性度量。从程序的环路复杂性可导出程序基本路径集合中的独立路径条数，这是确定程序中每个可执行语句至少执行一次所必须的测试用例数目的上界 。 　　3. 导出测试用例：根据圈复杂度和程序结构设计用例数据输入和预期结果。 　　4. 准备测试用例：确保基本路径集中的每一条路径的执行。

工具方法

　　图形矩阵 ：是在基本路径测试中起辅助作用的软件工具，利用它可以实现自动地确定一个基本路径集。 　　程序的控制流图：描述程序控制流的一种图示方法。 　　圆圈称为控制流图的一个结点，表示一个或多个无分支的语句或源程序语句 　　流图只有二种图形符号： 　　图中的每一个圆称为流图的结点，代表一条或多条语句。 　　流图中的箭头称为边或连接，代表控制流 　　任何过程设计都要被翻译成控制流图。 　　如何根据程序流程图 画出控制流程图? 　　在将程序流程图简化成控制流图时，应注意： 　　在选择或多分支结构中，分支的汇聚处应有一个汇聚结点。 　　边和结点圈定的区域叫做区域，当对区域计数时，图形外的区域也应记为一个区域。

步骤

　　基本路径测试法的步骤： 　　第一步：画出控制流图 　　流程图用来描述程序控制结构。可将流程图映射到一个相应的流图(假设流程图的菱形决定框中不包 含复合条件)。在流图中，每一个圆，称为流图的结点，代表一个或多个语句。一个处理方框序列和一个菱形决测框可被映射为一个结点，流图中的箭头，称为边或 连接，代表控制流，类似于流程图中的箭头。一条边必须终止于一个结点，即使该结点并不代表任何语句(例如：if-else-then结构)。由边和结点限 定的范围称为区域。计算区域时应包括图外部的范围。 　　第二步：计算圈复杂度 　　圈复杂度是一种为程序逻辑复杂性提供定量测度的软件度量 ，将该度量用于计算程序的基本的独立路径数目，为确保所有语句至少执行一次的测试数量的上界。独立路径必须包含一条在定义之前不曾用到的边。 　　有以下三种方法计算圈复杂度： 　　流图中区域的数量对应于环型的复杂性; 　　给定流图G的圈复杂度V(G)，定义为V(G)=E-N+2，E是流图中边的数量，N是流图中结点的数量; 　　给定流图G的圈复杂度V(G)，定义为V(G)=P+1，P是流图G中判定结点的数量。 　　第三步：导出测试用例　根据上面的计算方法，可得出四个独立的路径。(一条独立路径是指，和其他的独立路径相比，至少引入一个新处理语句或一个新判断的程序通路。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 　　根据上面的独立路径，去设计输入数据，使程序分别执行到上面四条路径。

三步法

　　1） 根据代码的功能，人工设计测试用例进行基本功能测试 ； 　　2） 统计白盒覆盖率，为未覆盖的白盒单位设计测试用例，实现完整的白盒覆盖，比较理想的覆盖率是实现100%语句、条件、分支、路径覆盖； 　　3） 自动生成大量的测试用例，捕捉"程序员未处理某些特殊输入"形成的错误。 　　第1步的测试用例通常是现成的，因为详细设计文档会规定程序的基本功能，没有文档的，程序员在编程时也要想清楚程序的功能，这些基本功能就是基本测试用例； 　　第2步是在第1步的基础上，检查未覆盖的白盒单位，由于未覆盖的逻辑单位通常对应未测试的等价类，因此第2步可以找出第1步所遗漏的测试用例； 　　第3步用自动动态测试弥补第2步的固有缺陷 。 　　"三步法"尽量避免重复工作，白盒方法和黑盒 方法相结合，人工方法和自动方法相补充，如果第2步的覆盖率比较理想，那么基本上可以保证找出所有等价类。在开发过程允许的限度内，"三步法"已接近极限，当得起"彻底测试"四个字。

与黑盒测试区别

黑盒测试

　　黑盒测试 也称功能测试或数据驱动测试 ，它是在已知产品所应具有的功能，通过测试来检测每个功能是否都能正常使用，在测试时，把程序看作一个不能打开的黑盒子，在完全不考虑程序内部结构和内部特性的情况下，测试者在程序接口 进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数锯而产生正确的输出信息，并且保持外部信息（如数据库 或文件）的完整性。黑盒测试方法主要有等价类划分、边值分析、因—果图、错误推测等，主要用于软件确认测试 。 “黑盒”法着眼于程序外部结构、不考虑内部逻辑结构、针对软件界面 和软件功能进行测试。“黑盒”法是穷举输入测试，只有把所有可能的输入都作为测试情况使用，才能以这种方法查出程序中所有的错误。实际上测试情况有无穷多个，人们不仅要测试所有合法的输入，而且还要对那些不合法但是可能的输入进行测试。

白盒测试

　　白盒测试也称结构测试或逻辑驱动测试，它是知道产品内部工作过程，可通过测试来检测产品内部动作是否按照规格说明书的规定正常进行，按照程序内部的结构测试程序 ，检验程序中的每条通路是否都有能按预定要求正确工作，而不顾它的功能，白盒测试的主要方法有逻辑驱动、基路测试等，主要用于软件验证。 　　“白盒”法全面了解程序内部逻辑结构、对所有逻辑路径进行测试。“白盒”法是穷举路径测试。在 使用这一方案时，测试者必须检查程序的内部结构，从检查程序的逻辑着手，得出测试数据。贯穿程序的独立路径数是天文数字。但即使每条路径都测试了仍然可能 有错误。第一，穷举路径测试决不能查出程序违反了设计规范，即程序本身是个错误的程序。第二，穷举路径测试不可能查出程序中因遗漏路径而出错。第三，穷举 路径测试可能发现不了一些与数据相关的错误。 　　软件人员使用白盒测试方法，主要想对程序模块进行如下的检查： 　　– 对程序模块的所有独立的执行路径至少测试一次； 　　– 对所有的逻辑判定，取 “ 真 ” 与取 “ 假 ” 的两种情况都至少测试一次； 　　– 在循环的边界和运行界限内执行循环体； 　　– 测试内部数据结构 的有效性，等。 　　具体包含的逻辑覆盖有： – 语句覆盖 – 判定覆盖 – 条件覆盖 – 判定－条件覆盖 – 条件组合覆盖 – 路径覆盖。

区别

　　白盒测试技术 (White Box Testing) ： 深入到代码一级的测试，使用这种技术发现问题最早，效果也是最好的。该技术主要的特征是测试对象 进入了代码内部，根据开发人员对代码和对程序的熟悉程度，对有需要的部分进行在软件编码 阶段，开发人员根据自己对代码的理解和接触所进行的软件测试叫做白盒测试。这一阶段测试以软件开发 人员为主，在 JAVA 平台使用 Xunit 系列工具进行测试， Xunit 测试工具是类一级的测试工具对每一个类和该类的方法进行测试。 　　黑盒测试技术（ Black Box Testing ）：黑盒测试的内容主要有以下几个方面，但是主要还是功能部分。主要是覆盖全部的功能，可以结合兼容，性能测试 等方面进行，根据软件需求 ，设计文档，模拟客户 场景随系统进行实际的测试，这种测试技术是使用最多的测试技术涵盖了测试的方方面面，可以考虑以下方面 　　c正确性 (Correctness) ：计算结果，命名等方面。 　　d可用性 (Usability) ：是否可以满足软件的需求说明。 　　e边界条件 (Boundary Condition) ：输入部分的边界值，就是使用一般书中说的等价类划分，试试最大最小和非法数据等等。 　　f性能 (Performance) ： 正常使用的时间内系统完成一个任务需要的时间，多人同时使用的时候响应时间在可以接受范围内。 J2EE 技术实现的系统在性能方面更是需要照顾的，一般原则是 3 秒以下接受， 3-5 秒可以接受， 5 秒以上就影响易用性了。如果在测试过程中发现性能问题，修复起来是非常艰难的，因为这常常意味着程序的算法不好，结构不好，或者设计有问题。因此在产品开 发的开始阶段，就要考虑到软件的性能问题 　　g压力测试 (Stress) ： 多用户情况可以考虑使用压力测试工具，建议将压力和性能测试结合起来进行。如果有负载平衡的话还要在服务器端打开监测工具 , 查看服务器 CPU 使用率 ，内存占用情况，如果有必要可以模拟大量数据输入，对硬盘的影响等等信息。如果有必要的话必须进行性能优化 ( 软硬件都可以 ) 。这里的压力测试针对的是某几项功能。 　　h错误恢复 (Error Recovery) ：错误处理，页面数据验证 ，包括突然间断电，输入脏数据 等。 　　i安全性测试 (Security) ：这个领域正在研究中，防火墙 、补丁包、杀毒软件 等的就不必说了，不过可以考虑。破坏性测试时任意看了一些资料 后得知 , 这里面涉及到的知识、内容可以写本书了 , 不是一两句可以说清的，特别是一些商务网站，或者跟钱有关，或者和公司秘密有关的 web 更是需要这方面的测试，在外国有一种专门干这一行的人叫安全顾问，可以审核代码，提出安全建议，出现紧急事件 时的处理办法等，在国内没有听说哪里有专门搞安全技术测试的内容。 　　j 兼容性 (Compatibility) ：不同浏览器 ，不同应用程序版本在实现功能时的表现不同的上网方式，如果你测试的是一个公共网站的话。

 

引用路径：http://baike.baidu.com/view/51297.htm