白盒（或者称透明盒）测试是指访问代码，能够查看和审查。

　　静态白盒测试是在不执行软件的条件下有条理地仔细审查软件设计、体系结构和代码，从而找出软件缺陷的过程，有时称为结构化分析。

　　进行静态白盒测试的首要原因是尽早发现软件缺陷，以找出动态黑盒测试难以发现或隔离的软件缺陷。静态白盒测试的另一个好处是，为黑盒测试员在接受软件进行测试时设计和应用测试用例提供思路。他们可能不必了解代码的细节，但是通过听审查评论，可以确定有问题或者容易产生软件缺陷的特性范围。

　　正式审查(formal review)

　　就是进行静态白盒测试的过程。正式审查的含义很广，从两个程序员之间的简单交谈，到软件设计和代码的详细、严格检查均属于此过程。正式审查有四个基本要素：

　　确定问题：找出软件的问题--不仅是出错的项目，还包括遗漏项目。

　　遵守规则：审查要遵守一套固定的规则，规则可能设定要审查的代码的代码量（通常有数百行）、花费多少时间，那些内容要做评价等。

　　准备：每一个参与者都要为审查做准备，并尽自己的力量。

　　编写报告：审查小组必须作出审查结果的书面总结报告，并使报告便于开发小组的成员使用。审查会议结果必须尽快告诉别人--诸如发现了什么问题，在哪里发现的，等等。

　　正式审查的基本方法：

　　同事审查：召集小组成员进行初次正式审查最简单的方法。

　　走查：walkthrough,比同事审查更正规划。走查中编写代码的程序员向5人小组或其他程序员和测试员组成的小组做正式陈述。陈述着逐行或者逐个功能地通读代码，解释代码为什么且如何工作。审查人员聆听叙述，提出有疑议的问题。

　　检验：inspections,是最正式的审查类型，具有高度组织化，要求每一个参与者都接受训练。检验与同事审查和走查的不同之处在于表述代码的人---表述着（presenter）或者宣读者（reader）--不是原来的程序员。这就迫使他学习和了解要表述的材料，从而可能在检验会议上提出不同的看法和解释。其余的参与者称为检验员（inspector）。

　　动态白盒测试的另一个名称是结构化测试（structural testing）,因为软件测试元可以查看并使用代码的内部结构，从而设计和执行测试。动态白盒测试不仅仅是查看代码的运行情况，还包括直接测试和控制软件。动态白盒测试包括以下4个部分：

　　直接测试底层函数、过程、子程序和库。在Microsoft Windows中这称为应用程序编程接口（API）。

　　以完整程序的方式从顶层测试软件，但是根据对软件运行的了解调整测试程序。

　　从软件获得读取变量和状态信息的访问权，以便确定测试与预期结果是否相符，同时，强制软件以正常测试难以实现的方式运行。

　　估算执行测试时“命中”的代码量和具体代码，然后调整测试，去掉多余的测试用例，补充遗漏的用例。

　　动态白盒测试和调试

　　一定不要把动态白盒测试和调试（debugging）弄混了。做过编程的人可能会花大量时间调试自己编写的代码。这两项技术表面上很相似，因为他们都包括处理软件缺陷和查看代码的过程，但是他们的目标大不相同。动态白盒测试的目标是寻找软件缺陷，调试的目的是修复缺陷。然而，两者在隔离软件缺陷的位置和原因尚确实存在交叉。

　　分段测试

　　单元测试和集成测试

　　在底层进行的测试称为单元测试（unit testing）或者模块测试（module testing）。单元经过测试，底层软件缺陷被找出并修复之后，就集成在一起，对模块组合进行集成测试（integration testing）。这个不断增加的测试过程继续进行，加入越来越多的软件片段，直至整个产品----至少是产品的主要部分----在称为系统测试（system testing）的过程中一起测试。

　　采用这种测试策略很容易隔离软件缺陷。在单元级发现问题时，问题肯定就在那个单元中。如果在多个软件集成时发现软件缺陷，那么它一定与模块之间的交互有关。当然也有例外，但是总的说来，测试和调试比一起测试所有内容要有效得多。