白盒测试方法

一、白盒测试概念

1、定义

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

2、目的

我们一方面注重软件功能需求的实现，另一方面还要注重程序逻辑细节，主要是因为软件自身的缺陷，具体如下：

1）逻辑错误和不正确假设与一条程序路径被运行的可能性成反比。日常处理往往被很好地了解，而“特殊情况”的处理则难于发现。

2）我们经常相信某逻辑路径不可能被执行，而事实上，它可能在正常的基础上被执行。程序的逻辑流有时是违反直觉的，只有路径测试才能发现这些错误。

3）代码中的笔误是随机且无法杜绝的。笔误出现在主流上和不明显的逻辑路径上的机率是一样的。很多被语法检查机制发现，但是其他的会在测试开始时才会被发现。

4）功能测试本身的局限性。如果程序实现了没有被描述的行为，功能测试是无法发现的，例如病毒，而白盒测试很容易发现它。

3、目标

采用白盒测试必须遵循以下几条原则，才能达到测试的目标：

1）保证一个模块中的所有独立路径至少被测试一次。

2）所有逻辑值均需测试真(true) 和假(false) 两种情况。

3）检查程序的内部数据结构，保证其结构的有效性。

4）在上下边界及可操作范围内运行所有循环。

4、黑白灰区别

黑盒测试技术：也称功能测试或数据驱动测试，只关注规格说明中的功能，测试者在程序接口对软件界面和软件功能进行测试，它只检查实现了的功能是否按照“用户需求说明书”的规定正常使用，程序是否能适当地接收输入数据而产生正确的输出信息，并且保持外部信息（如数据库或文件）的完整性。主要用于软件确认测试，结合兼容、性能测试等方面，但黑盒测试不能保证已经实现的各个部分都被测试到。黑盒测试适用于各阶段测试。

白盒测试技术：只关注软件产品的测试，深入到代码一级的测试，它是知道产品内部结构，通过测试来检测产品内部动作是否按照“设计规格说明书”的规定正常进行，按照程

序内部的结构测试程序，检验程序中的每条通路是否都能按预定要求正确工作，主要用于软件验证，不能够确保产品已经实现了规格说明中的所有功能。白盒测试通常用于单元测试。

灰盒测试技术：在白盒测试中交叉使用黑盒测试、在黑盒测试中交叉使用白盒测试的方法。它结合了白盒测试和黑盒测试的要素，涉及输入和输出，但使用关于代码和程序操作等信息设计测试用例。灰盒测试通常用于集成测试。

测试是从用户需求的角度去对软件的质量进行检测。具体使用黑盒测试、白盒测试、灰盒测试，不需要太明确的来划分，我们应该多角度去设计测试用例，多角度去测试软件、发现bug，才是一个测试工程师应该具备的思想。总之，建议测试人员在测试过程中，可以考虑先使用黑盒测试，然后统计相应的覆盖率，再设计适当的白盒测试用例作为补充，以保证测试的完整性。

二、白盒测试方法

1、简介

白盒测试主要是检查程序的内部结构、逻辑、循环和路径。测试是基于覆盖全部代码、分支、路径、条件。根据测试程序是否运行，白盒测试分静态白盒测试和动态白盒测试两种。

静态白盒测试也称为结构分析，是在不执行程序的条件下审查软件设计、体系结构和代码，从而找出软件缺陷的过程。测试对象是文档、代码等非计算机执行的部分。在项目中使用静态白盒测试是基于这样的原则：错误发现得越早，改正错误的成本越低，正确改正错误的可能性越大，改正错误时可能引发的其他错误的数量也越少。静态白盒测试方法包括代码检查法、静态结构分析法、静态质量度量法。常用的是代码检查法，这些方法在程序开始编码之后、基于计算机的动态测试开始之前使用。

动态白盒测试也称为结构化测试，是在使用和运行程序的条件下，软件测试员查看代码内部结构和实现方式来确定哪些要测试，哪些不要测试，如何开展测试，怎样设计和执行测试用例。白盒测试的覆盖标准有逻辑覆盖、循环覆盖和基本路径测试。动态白盒测试常用的测试用例设计方法有逻辑覆盖法（逻辑驱动测试）和基本路径测试法两种。

下面具体介绍一下三种常用的白盒测试方法：

2、代码检查法

2.1简介

代码检查法主要检查代码和程序设计的一致性，代码结构的合理性，代码编写的标准性、可读性，代码逻辑表达的正确性等方面。检查方式包括桌面检查、代码走查、代码审查三种方式。

目的：检查程序是不是按照某种标准或规范编写的。

目标：发现程序缺陷，改进软件的质量。

需要的文档：程序设计文档、程序的源代码清单、编码规范、代码缺陷检查表等。在进行代码检查时，代码缺陷检查表就是测试用例，检查表中一般包括容易出错的地方和在以往的工作中遇到的典型错误。

优缺点：代码检查法能快速找到缺陷，一旦发现错误，能够在代码中对其进行精确定位，从而降低了错误修正的成本。代码检查看到的是问题本身而非问题的征兆。但是代码检查非常耗费时间，而且代码检查需要知识和经验的积累。

2.2代码审查和走查

两种方法的形成、流程一样，规程、方法不一样。具体来说：

代码审查和走查都是以小组为单位阅读代码，它是一系列规程和错误检查方法的集合。审查或走查小组通常由不需要对程序细节很了解的协调人员、程序的编码人员、程序的设计人员、测试专家四人组成。都是以会议的形式进行。会议理想时间为90-120分钟之间，按照每小时阅读150行代码的速度进行。对大型软件应安排多个会议同时进行，每个会议处理一个或几个模块或子程序。

代码审查规程和方法：在代码审查会议上，程序作者逐条语句讲述程序的逻辑结构，参与人根据“代码缺陷检查表”分析程序，检查内容包括编码标准规范和错误列表。编码规范是指团队根据自己的经验和风格进行设置的一些规范。错误列表一般是代码潜在的bug，由于某种代码写法虽然没有语法错误，但是可能存在错误，比如会导致线程死锁，这些都是错误列表应该检查的。程序员之间可以隔一定的时间抽取代码进行审查。结束会议后，把这些经验汇成列表，作为下次代码审查的依据，并针对错误修正进行跟踪。输出文档是“代码检查记录表”，此表主要内容日期、住持人、参与人员、范围、发现的问题、问题处理、跟踪检查等。

代码走查规程和方法：在代码走查会议上，参与者参考“设计规格书”使用计算机来执行代码。测试人员准备一些简单的测试用例，它的作用是提供启动代码走查和质疑程序员逻辑思路及其他设想的手段。在会议期间，把测试数据沿程序的逻辑结构走一遍，程序的状态记录在纸或白板上以供监视。在大多数的代码走查中，很多问题是在向程序员提问的过程中发现的，而不是由测试用例本身直接发现的。

2.3桌面检查

桌面检查是一种传统的检查方法，由程序员检查自己编写的程序。程序员在程序通过编译之后，对源程序代码进行分析、检验，并补充相关文档，由于程序员熟悉自己的程序及其程序设计风格，桌面检查由程序员自己进行可以节省时间，但应避免主观片面性。桌面检查的效果逊色于代码检查和走查，但桌面检查胜过没有检查。

3、逻辑覆盖测试

3.1简介

测试覆盖率：用于确定测试所执行到的覆盖项的百分比。其中的覆盖项是指作为测试基础的一个入口或属性，比如语句、分支、条件等。测试覆盖率可以表示出测试的充分性，在测试分析报告中可以作为量化指标的依据，测试覆盖率越高效果越好。但覆盖率不是目标，只是一种手段。测试覆盖率包括功能点覆盖率和结构覆盖率，功能点覆盖率大致用于表示