由此分析，我们可以将白盒测试体系按照代码暴露量由多到少做如下的划分：深度测试，单元测试，接口测试，集成测试，压力测试与性能分析。这是一个完整的白盒测试体系，可以适用于各种系统的测试。深度测试，是指深入到系统中的每一个函数进行测试；单元测试，是指对系统中的各子业务单元进行测试，需要完成业务单元的开发以后进行；接口测试，包含两个方面的内容，即系统内部接口和外部接口，内部接口测试需要考虑系统内部多态的实现，外部接口则需要测试系统提供服务的有效性；集成测试，常常是系统的所有代码开发完成以后，可以对系统中所有业务单元进行集成，对各种业务逻辑进行测试，需要深入了解系统的需求；压力测试与性能分析，这个部分其实也许不能算是白盒测试的范畴，然而，我依然把这一部分纳入到白盒测试体系考虑的范畴，这也许是一个很有效的考察系统性能的途径，因为通过白盒测试的方法，我们可以对系统进行精确施压，对于这个问题，我在后面的分析中还会继续谈到。

然而，我们该如何做白盒测试呢？经过个人的实践与总结，系统切分是白盒测试应用的一个很重要的方法。我们需要像庖丁解牛一样，将系统进行有效的切分，对切分出来的系统进行逐个测试。大型复杂系统可以切分成若干个小系统，小系统又可以切分成若干子系统等等。例如，某应用系统，用户终端是终产品，在终端的下面我们可能有业务层的动态库，在业务层的动态库下面，我们可能有很多的基本功能动态库等等。对于淘宝的J2EE架构，我们也可以进行同样的系统拆分。对于切分的粒度，我们需要深入考虑投入产出比。切的过细，会导致投入过多，可能得到的效果不一定明显，也存在着边际效用递减的可能；而切的过粗则可能产出达不到要求。因此，在做系统切分的时候，需要掌握一个平衡点，对现有的资源和产品的测试需求做仔细的权衡。由于系统的切分，同时由于精确施压，我们可以对单一子系统的性能做很好的分析与衡量，这将对系统的整体性能分析有非常大的帮助。

根据个人做白盒测试成功与失败的经验总结，在做白盒测试的时候，有一些重要的原则可能是决定白盒测试成败的关键。原则一：在做系统切分的时候，我们要找到正确的系统边界；在测试的时候，我们需要站在正确的角度来看待系统，找到正确的系统接口，并对其进行测试；原则二：直接面对产品代码或者接口进行测试，不要使用中间件进行转换；原则三：在做白盒测试之前需要先做好业务逻辑的抽象与设计，提高测试代码的重用性，避免大量的粘贴与复制；原则四：测试脚本语言好与产品开发语言一致，例如，C++开发的产品好用C++来测试，当然，这会增加一定的技术难度。