白盒测试：为什么要做白盒测试

2016-08-25

目录

1 预备知识
 2 白盒测试的认识误区
   2.1 从一个比喻开始
   2.2 误区之一：白盒测试太耗时间，不值得一做
   2.3 误区之二：系统测试可以发现所有问题，不必做白盒测试
   2.4 误区之三：白盒测试必须在真实环境下进行
   2.5 误区之四：个人能力强的不必做白盒测试
   2.6 误区之五：白盒测试仅证明该怎么跑的代码是这样跑了，测不出什么问题！
 3 参考

1 预备知识

返回

软件测试技术不同分类：

• 按是否关注软件结构和算法可分为：黑盒测试、白盒测试
• 按测试过程中软件是否被执行可分为：为静态测试、动态测试
• 按测试阶段可分为：单元测试、集成测试、系统测试、验收测试
• 按目标/特性客分为：功能测试、安全性测试、兼容性测试、可靠性测试、性能测试、易用性测试等。

白盒测试包含静态测试和动态测试。白盒测试也常在单元测试与集成测试阶段进行，但这是相对的，与当前项目遵循的研发流程有关，某些流程把白盒测试划分为单元测试与集成测试，而另一些流程，把白盒测试划分为模块单元测试、模块系统测试、多模块集成测试，还有一些流程把单元测试与集成测试混为一体，统称为持续集成测试。

2 白盒测试的认识误区

返回

白盒测试作为软件质量保证中的重要一环，但由于以下认识误区，导致白盒测试被忽视：

• 误区之一：白盒测试太耗时间，不值得一做
• 误区之二：系统测试可以发现所有问题，不必做白盒测试
• 误区之三：白盒测试必须在真实环境下进行
• 误区之四：个人能力强的不必做白盒测试
• 误区之五：白盒测试仅证明该怎么跑的代码是这样跑了

本篇总结实施白盒测试的几个主要误区，我们先从认识上端正对白盒测试的看法：

2.1 从一个比喻开始

前两个认识误区可以从从一个比喻开始讲起。

假设有一台的面包机，从上面倒入面粉与水，开动机器后从下面出来的就是烤好了的面包，这个机器的功能比较单一，接口很清晰，输入是面粉与水，输出是面包。现在假定这个面包机多年未用，内部都生锈了，现在要清洗它，类似于我们开发的软件，软件有Bug，那得通过测试来清理。

图1 面包机

那如何更快速的清洗这台面包机呢？有两种洗法：

• 一种是拿水从上往下灌，这是系统测试的方法；
• 另一种是拆开来洗，拆开机器后，拿抺布沾点清洁剂，把各零件的坑坑槽槽擦洗一遍。

无疑，上面第二种方法是正确的，我们的前提是：清洗多年未用的面包机，铁锈够多，如果洗不干净，造出的面包都是致癌物质。当然，清洗面包机还只能算简单劳动，清理软件中的Bug要复杂得多，一个if语句有两条分支，一个while循环判断也是两条分支，还有break、continue、return等，想想看，一个1万行规模的软件能有多少个分支！一个分支就是一条坑坑槽槽，而且软件Bug还具备动态特性，不是静止的明摆在哪儿。

所以，软件的白盒测试不可或缺，因为遗留Bug的影响很大，就像面包机没洗净留铁锈会致癌，还因为软件系统远比面包机复杂，不拆开来怎么能洗干净！

2.2 误区之一：白盒测试太耗时间，不值得一做

白盒测试是高效测试

尽管白盒测试如此重要，为什么还有许多企业不愿做白盒测试，有一个很重要的原因是：认为白盒测试太低效，不值得去做。

这种观点主要有两种误解导致：

• 决策者评估各阶段测试的有效性，往往仅以发现问题的数量为依据，这好比锈蚀斑斑的面包机，第一次冲水下去，看到大量浊水流出就很有成就感，其实这只是表象。
• 把发现问题与解决问题割裂开来了

实际上：

• 只做系统测试的结果是：第一次冲水，很有成效，第二次冲水，还能冲出点铁锈，第三次就没什么效果了。采用该手段并不能有效的达成既定质量目标。
• 研发质量改善，不只发现问题，还要定位问题、解决问题。白盒测试是拆开来洗，发现、定位与解决问题不仅是彻底的，也是直接的，效率非常高，所以，单以发现问题数评估一个测试过程是否有效不尽准确，我们应该综合评估一个问题从被发现，到定位、解决，以及针对它完成回归测试的总效率。

下图来源于Capers Jones与McGraw-Hill的“Applied Software Measurement”文章，从该统计数据可看出，针对一个功能点的测试，若将问题发现、定位与解决都计算进去，单元测试效率最高，是集成测试的2倍，是系统测试的3倍。

图2 各阶段测试效率

而且，经验数据表明，编码阶段的一个问题遗留到验收测试去解决，所须费用将增加5倍，如下图，一个问题越遗留到后面阶段解决，付出代价就越高，而且是成倍递增关系。

图3 各阶段解决问题代价

依据上述原因，我们评估白盒测试效率时，通常将发现问题总数乘上一个系数K，以此为据再与其它测试方段的发现问题效率做对比，来权衡白盒测试值不值得去做。系数K取值与产品形态相关，按照实际经验，系数K取值区间为1.5~2.5，产品越复杂，出现问题越不容易解决的，K值要往大调。

2.3 误区之二：系统测试可以发现所有问题，不必做白盒测试

白盒测试能彻底解决编码阶段引入的问题

不同阶段的测试发现问题的特点各不相同，比如：

• 单元测试阶段，容易发现逻辑问题、边界条件、变量未初始化、内存越界等问题，
• 集成测试容易发现接口错误、任务配合问题等，
• 系统测试容易发现业务流程问题、界面操作问题等。

如果某阶段的测试没做，把问题遗留后面阶段，又如何能保证查错的彻底性。比如使用非法内存，出问题是否表现出来是随机的，如果操作非法内存当前被系统还认为是有效的，系统并不死机，但某些情况下，操作非法内存会死机，而另一些情况，非法内存操作将不期望变化的变量改写了，会导致其它莫名其妙的问题。类似这样的问题，在白盒测试阶段很容易发现，也容易定位解决，但遗留系统测试阶段，就很难去发现、去定位。

在V模型中，软件开发过程与测试行为具有不同层次的对应关系，如下图：

图4 V模型

单元测试针对编码阶段引入的问题，集成测试与功能测试针对软件设计中引入的问题，验收测试针对需求与规格。

单元测试不要或缺的重要原因是：编码阶段引入的问题占很高比例，不进行单元测试就难以保证系统最终的稳定性。

2.4 误区之三：白盒测试必须在真实环境下进行

有的时候真实环境很难搭建，或搭建了也很难测试，这导致测试无法顺利进行。

近代量子力学有一个海森堡测不准原理，讲的是某个粒子的位置与动量不能同时被测量出来，由测量存在干扰，对其中一个参数测量越准确，另一个参数就越不准确。测不准原理在我们日常生活中很常见，比如要测试某物质的导电性，我们串联接上一个安培计来观察电流，但是，安培计本身也带电阻，导致测不准，测量值会偏小。

在软件测试领域也存在类似情况，比如要测试系统的CPU占用，于是添加代码统计CPU占用率，但添加的代码运行时，它本身也会消耗CPU。再如，为了实施白盒测试，必然追加测试代码，比如：构造特定运行环境、替换桩函数使之在特定情况下返回特定值，这些都改变了被测对象自身的特性，追求完全准确的测试非常困难。

所以，我们并不是一定要追求在真实环境下做测试，而是要评估非真实环境（或仿真环境）下的测试对最终结果能产生多大偏离。

2.5 误区之四：个人能力强的不必做白盒测试

能力强者不必做白盒测试，这显然是谬论。一个人能力再强，软件开发中都会犯错误，只不过能力强的，犯错误少些而已。

2.6 误区之五：白盒测试仅证明该怎么跑的代码是这样跑了，测不出什么问题！

白盒测试针对的是规格，而非可见代码，通过可见代码做测试只是手段，最终目的是要测规格，所以我们白盒测试不仅要测可见代码，也测试不可见代码，如缺失的else分支、default分支，甚至漏写的处理过程都在测试范围之内。

3 参考

[1] 第4代白盒测试方法之“为什么要做白盒测试”

[2] 第4代白盒测试方法之“实施白盒测试的几个误区”