浅析白盒测试在软件测试中的应用

田春竹 邢航

白盒测试，是软件功能测试中的重要一环。在当前整个测试业务中，大家主要关注于黑盒测试，由于测试过程比较繁琐、测试成本较高等方面的原因，白盒测试往往被大家直接忽略，所占的比例非常小。本文通过针对某油田系统的一个具体功能点，详细阐述了白盒测试的基本过程，并说明了白盒测试对黑盒测试的有力补充。

一、软件测试概述

随着信息化的快速发展，信息系统的建设速度也越来越快，而且呈现出规模变大，复杂度增高的趋势。在这种情况下，无论是进行系统开发的软件公司，还是最终的系统用户，都开始逐渐重视软件测试，从而进一步推动了软件测试的发展。

软件测试一般可分为两种，即黑盒测试和白盒测试。其中，白盒测试也被称为结构测试，它是按照程序内部的结构测试程序，通过测试来检测产品内部动作是否按照设计规格说明书的规定正常进行，检验程序中的每条通路是否都能按预定要求正确工作。

二、白盒测试的主要方法及测试流程

（一）白盒测试的主要方法

目前的软件测试，通常仍是以黑盒测试为主，但是黑盒测试并不一定能发现所有的问题，在必要情况下，需要使用白盒测试进行补充。

目前比较流行的白盒测试方法包括代码检查法、逻辑覆盖法、基本路径测试法等。其中，逻辑覆盖法又可以包含语句覆盖、判定覆盖、条件覆盖等。本文在此主要介绍逻辑覆盖法的相关应用。

（二）白盒测试的主要流程

进行逻辑覆盖法的主要测试流程如下：

1、制定测试计划。即根据整体测试需求以及被测系统的需求规格说明书、设计文档等来制定测试计划。

2、进行模块分析。在白盒测试过程中，测试人员对被测试程序的内部结构是清楚的，需要从程序的内部逻辑结构入手，按照一定的原则设计测试用例，对软件的逻辑路径进行测试。因此，进行模块分析是非常重要的一个步骤，也是整个测试的重点和难点。模块分析主要包括两个部分，第一是针对被测模块的功能进行分析，了解模块的具体业务和功能，第二是针对代码进行分析，查看源代码中主要的方法、函数等。如果模块分析不准确，则后续的其他工作都将失去意义。代码分析和功能分析工作是相辅相成的，作为软件测试人员，如果对业务细节不懂，就做不好相应的测试。但是要在很短的时间内把所测系统的业务细节完全搞懂，也是一件非常不容易的事情。因此，一边了解功能一边分析代码，在某些情况下是非常必要的。

3、测试用例设计。在完全理解具体业务细节后，根据模块分析结果和测试要求，进行测试用例的设计。

4、测试执行。根据测试用例执行测试，并详细记录测试结果。

5、测试总结。针对测试结果进行分析，确认发现的相关问题，并协助开发人员解决相关错误。

6、回归测试。在开发人员完成修改后，针对模块进行回归测试。

三、白盒测试的具体应用

接下来通过一个实例来讲述白盒测试中逻辑覆盖法的具体应用。

（一）测试背景

某油田的信息中心人员自行开发了一套测井解释系统，在经过开发人员的自行测试后，即开始进行内部试用。但是在使用过程中发现了很多问题，为确保系统功能的正确性，该单位（即委托单位）决定聘请第三方人员进行系统的功能测试。

由于在系统试用过程中，产生了部分正式数据，而委托单位因特殊原因无法提供专用的測试环境，为了尽量避免测试过程中对系统的正常使用造成麻烦，经过和委托单位协商，由委托单位统一提供所有的测试数据。同时，经过与委托单位协商，决定采用逻辑覆盖的方式，对系统中的几个重要功能点进行白盒测试。

（二）测试过程

在测试过程中，“工程测井”模块中含有一个“方位井径校正”的功能。它是在数据库模式下进行方位井径曲线数据的计算，计算完成后自动保存数据。如果之前已经存在曲线数据，可根据系统提示选择是否进行覆盖。

这是一个非常简单而又常见的功能点。测试人员在进行黑盒测试时，录入测试数据，首先点击“计算”按钮。系统弹出是否覆盖数据的提示后，点击“确定”，系统提示已经覆盖数据，点击“取消”后，系统界面未发生任何变化，也无任何提示，功能测试通过。

由于“工程测井”是本系统的一个重点模块，在功能测试完毕后，开始进行白盒测试。具体过程如下：

1、根据“方位井径校正”功能的具体业务，结合系统代码（如图1）及设计文档，进行“计算”功能的流程分析，并标识出所有的判断逻辑（如图2）。

2、根据此流程图，可以判断出需要编写五个测试用例，分别是

（1）TC_C_001曲线名是否为空的逻辑判定

（2）TC_C_002是否覆盖原有数据的逻辑判定

……

其中TC_C_002是否覆盖数据的逻辑判定，便是针对前面所述功能的分析结果。

3、设计测试用例

根据流程图中的分析结果，结合系统设计文档及具体代码，完成了测试用例的设计，如表1所示。

4、执行测试用例

在执行此用例时，我们使用了开发平台中的断点调试，即分别点击“确定”、“取消”按钮后，使用断点逐步查看各变量、参数的变化情况和代码执行情况。

根据对设计文档和系统代码的分析，我们初步判断，点击“取消”按钮后，系统应为option变量赋值为1，然后调用return函数结束当前执行的方法。但是实际测试过程中，点击“取消”按钮后，发现系统为变量option的赋值为2（如图3所示）。之后并没有通过调用return来结束方法的执行，而是继续执行该方法，直到完成了一次覆盖后，才结束当前的操作。

而点击“确定”按钮后，系统为变量option的赋值为0，程序跳过if判断语句，同样继续执行覆盖操作。

也就是说，无论界面上操作时点击的是“确定”还是“取消”按钮，其实后台都执行了一次覆盖操作。

（三）测试总结及回归

为何在功能测试时未能发现这个问题呢？通过总结我们发现，由于該模块只进行校正工作，校正后的数据是供后期其他模块汇总使用。测试人员在测试过程中，对于执行是否成功，通过该模块的界面看不到具体效果，仅能通过系统给出的是否覆盖成功的提示做出简单判断，而委托单位提供的测试数据又非常单一，从而导致功能测试时未能发现此问题。

之后，我们与委托单位负责人，以及模块开发人员共同进行了问题确认。在开发人员完成bug修改后，由业务人员提供了多组数据，并与测试人员一起针对本功能及相关联内容进行了回归测试，最终确认问题得到了解决，bug关闭。

四、结语

在软件测试中，黑盒测试重点在于系统的功能性，而白盒测试则略微偏重于逻辑方面的测试，但是通过本文中的例子可以看出，二者并不冲突，而是互补。虽然通常情况下黑盒测试基本可以发现一个系统的大多数问题，但是在白盒测试过程中也可能会发现一些黑盒测试时未能发现的问题，反之亦然。对于任何一个系统测试来说，要想更好地实现其基本功能，做好后期的具体应用，在其前期测试过程中，白盒测试与黑盒测试都是必不可少的组成部分。