测试专家谈如何构建白盒测试体系
什么是白盒测试？很多人都听说过白盒测试。通常的说法是，白盒测试是能看到全部产品源代码的测试。常常，白盒测试都是和牛人绑在一起的。个人认为这是一种比较狭隘的说法。然而究竟什么是白盒测试呢？可能有很多的人在做了很长时间的白盒测试以后发现，自己其实不是在做白盒测试，而是在做灰盒测试，原因是不够“ 白”，因为他没有看到全部的产品代码。其实，我个人认为，这是做白盒测试的误区。
从广义来说，个人认为，白盒测试是代码级的测试，是软件半成品的测试，不存在所谓的灰盒测试。所谓的灰盒测试，只不过是因为代码的暴露程度不同而已，从本质上来说，都是白盒测试。其实，无论是作为一个测试者，还是作为一个开发者，谁也不能保证通晓所有的代码，尤其是在现代软件企业中工程师的职责和分工越来越细，第二、三方库越来越丰富了以后。
然而，我们该如何构建白盒测试体系呢？由前面的讨论，我们可以知道，产品代码的暴露程度在白盒测试体系中有着十分重要的作用。
在代码暴露量等于零的时候，测试的粒度和广度不是等于零的，这里代表的是黑盒测试。随着代码暴露量的增加，测试的粒度和广度并不是线性上升的，这里主要体现了一个含义，代码暴露量的边际效应该是递减的。也是说，代码暴露量的增加给测试带来的难度是增加的。当代码暴露量达到的时候，我们也很难做到测试覆盖率达到。
由此分析，我们可以将白盒测试体系按照代码暴露量由多到少做如下的划分：深度测试，单元测试，接口测试，集成测试，压力测试与性能分析。这是一个完整的白盒测试体系，可以适用于各种系统的测试。深度测试，是指深入到系统中的每一个函数进行测试；单元测试，是指对系统中的各子业务单元进行测试，需要完成业务单元的开发以后进行；接口测试，包含两个方面的内容，即系统内部接口和外部接口，内部接口测试需要考虑系统内部多态的实现，外部接口则需要测试系统提供服务的有效性；集成测试，常常是系统的所有代码开发完成以后，可以对系统中所有业务单元进行集成，对各种业务逻辑进行测试，需要深入了解系统的需求；压力测试与性能分析，这个部分其实也许不能算是白盒测试的范畴，然而，我依然把这一部分纳入到白盒测试体系考虑的范畴，这也许是一个很有效的考察系统性能的途径，因为通过白盒测试的方法，我们可以对系统进行精确施压，对于这个问题，我在后面的分析中还会继续谈到。
然而，我们该如何做白盒测试呢？经过个人的实践与总结，系统切分是白盒测试应用的一个很重要的方法。我们需要像庖丁解牛一样，将系统进行有效的切分，对切分出来的系统进行逐个测试。大型复杂系统可以切分成若干个小系统，小系统又可以切分成若干子系统等等。例如，某应用系统，用户终端是终产品，在终端的下面我们可能有业务层的动态库，在业务层的动态库下面，我们可能有很多的基本功能动态库等等。对于淘宝的J2EE架构，我们也可以进行同样的系统拆分。对于切分的粒度，我们需要深入考虑投入产出比。切的过细，会导致投入过多，可能得到的效果不一定明显，也存在着边际效用递减的可能；而切的过粗则可能产出达不到要求。因此，在做系统切分的时候，需要掌握一个平衡点，对现有的资源和产品的测试需求做仔细的权衡。由于系统的切分，同时由于精确施压，我们可以对单一子系统的性能做很好的分析与衡量，这将对系统的整体性能分析有非常大的帮助。
根据个人做白盒测试成功与失败的经验总结，在做白盒测试的时候，有一些重要的原则可能是决定白盒测试成败的关键。原则一：在做系统切分的时候，我们要找到正确的系统边界；在测试的时候，我们需要站在正确的角度来看待系统，找到正确的系统接口，并对其进行测试；原则二：直接面对产品代码或者接口进行测试，不要使用中间件进行转换；原则三：在做白盒测试之前需要先做好业务逻辑的抽象与设计，提高测试代码的重用性，避免大量的粘贴与复制；原则四：测试脚本语言好与产品开发语言一致，例如，C++开发的产品好用C++来测试，当然，这会增加一定的技术难度。
