(原创)我看黑盒白盒

pt163 · 发表于 2007-12-20 16:34:52

再说说软件测试类型～

什么是黑盒测试、白盒测试？

借用老钱Email中的描述：

黑盒测试又称为功能测试或者数据驱动测试，是把系统看成一个黑盒子，不考虑程序的内在逻辑，只根据需求规格说明书的要求来检查相互的功能是否符合它的功能说明。

白盒测试又称为结构测试或者逻辑驱动，允许测试人员对程序内部逻辑结果及有关信息来设计和选择测试用例。

从概念上我们可以看到黑盒测试与白盒测试是两种用来设计测试用例的方法，进一步分析这两个概念，这两种方法有什么区别呢？

先引入一个概念，叫IPO模型，这是一个测试用例模型，I是输入，P是过程，O是输出，也就是一个测试用例执行过程就是输入，过程变化，得到输出。这里的输入不仅包括执行阶段显式的输入，如登陆界面上输入的用户名密码，同时包括了此时的上下文环境，如此时数据库的数据，配置文件的设置等，过程变化指的被测对象内部的运算活动，输出指的是所有被测试对象以外的可以观测到的现象。

不管使用哪一种测试用例设计方法，最终都是执行这一模型的，那么我们看一下两种方法对应到这一模型时有什么不同？

我们说黑盒测试是不考虑内部逻辑，只通过需求规格说明书的要求检查结果是否符它的功能说明，换句话说，我们通过规格说明书上的功能描述进行测试设计，用例的多少与有效性很大程度上依赖于描述的详细程度，而功能描述会描述到该功能输入的一些限制条件以及相应的输出，此时，我们将会通过这些描述构造出不同的用例，从此处对应到IPO，发现我们通过描述，可以预测到的是输入与输出，而过程就不得而知了～

再说白盒测试，对程序内部逻辑结果及有关信息来设计测试用例，此时，我们通过对被测对象内部执行过程的了解，知道各种各样的计算逻辑，而这些逻辑对我们的输入进行了更细致的分类，从而得到输出，也就是说，在黑盒角度的一个测试用例，从白盒角度进行观察的话，它可能仅仅是在同类输入输出(RS中所描述的)中的一个特例而已，所以，采用白盒测试方法时，我们将会通过分析内部逻辑得到更多的输入和输出，而每一对应的输入，我们都知道它进入被测对象后的数据流与控制流如何变化，最终形成输出。

一大段话说下来，我们发现了，白盒似乎比黑盒更强，因为它强化了逻辑过程的分析，得到的用例覆盖显而易见比黑盒更全面，那是不是直接用白盒就行了，黑盒就不需要了呢，答案显然是否定的，那我们少分析了什么呢？没错，就是被测对象以及软件复杂度。

我们拿最低层的单元测试来分析，在单元测试中，被测对象应该是一些小粒度的东西，如功能简单的模块，类甚至是函数，我们以函数为例子，当我们测试对象是一个函数时，使用黑盒的测试方法，我们的依据是这个函数的说明文档，指出这个函数的输入是什么，对应的输出将是什么，再配合一些黑盒测试用例分析技术（等价类划分，边界值分析等）来产生测试用例。使用白盒的测试方法时，我们则会去分析这个函数的内部逻辑，使用白盒测试技术（语句覆盖、条件覆盖等）针对不同的输入产生的过程覆盖进行测试用例的生成，我们看到，首先两种测试方法的思想是不同的（一种依赖于需求产生用例，一种依赖于逻辑产生用例），同时产生用例的规模也是不一样的。

接着我们转向高层的系统测试，在系统测试中，被测对象将是一个复杂的系统，当我们设计该系统的某一功能的测试用例时，使用黑盒的测试方法和我们测试一个函数的过程基本一致，用例也是同需求文档所描述的详细程度成比例的，而如果此时我们采用白盒的方式，产生出来的用例规模可想而知。

其实以上的分析中有一漏洞，那就是黑盒测试面对被测对象时，不会受到它粒度大小的影响，而白盒测试却一直关注到代码级别的逻辑，当被测对象粒度放大时，复杂度就会随之剧增。那么，我们是否能够使得白盒测试技术也具有黑盒同样的性质呢，我认为是可以的，如果我们再重新审视一下白盒测试的概念，会发现概念中所描述的是“内部逻辑”，而并没有特别指出是代码的逻辑，那么我们是否可以认为这个逻辑是更高粒度上的逻辑，比如说在系统层面下低一层的设计逻辑，我想是可以的，或许白盒测试的本义就是这样的。那到了这里，我们再来关注一个问题，黑盒测试与白盒测试有什么不同的地方？我个人觉得应该有两方面：１、设计思想不同，设计角度不同；２、产生的用例数量非常不同。因此，我认为，在测试的各个阶段，从单元测试到系统测试都可以采用两种测试方法（这里的白盒测试方法指的是会根据被测对象粒度作出调整的），而黑盒测试思维方式上更倾向于用户，白盒测试思维方式上倾向于设计人员。在方法选择上可根据项目具体情况（时间、成本、人员技能）作出适当调整。

也许想法有偏差，希望大家能够一起讨论，让彼此有更多的进步～

陈焕文

2007-12-11

http://blog.163.com/chv_cn