用一句话来概括，动态白盒测试是指利用查看代码功能和实现方式得到的信息来确定哪些要测试，哪些不要测试，如何开展测试。动态白盒测试的另一个常用名称是结构化测试，因为软件测试员可以查看并使用代码的内部结构，从而设计和执行测试。
动态白盒测试不仅仅是查看代码，还包括直接参数和控制软件。它包括四部分：
1.直接测试底层功能、过程、子程序和库。即应用程序接口（API）
2.以完整程序的方式从顶层测试软件，但是要根据对软件运行的了解调整测试案例。
3.从软件获得读取变量和状态信息的访问权，以便确定测试与预期结果是否相符，同时，强制软件以正常测试难以实现的方式运行。
4. 估算执行测试时“命中”的代码量和具体代码，然后调整测试，去掉多余的，补充遗漏的。
二、动态白盒子测试和调试
测试和调试是不同的。白盒测试的目标是寻找软件缺陷，调试的目的是修复它们。然而它们在隔离软件缺陷的位置和原因上确实存在交叉现象。测试员应该把问题缩减为能够演示软件缺陷的最简化测试案例。在白盒测试中，甚至要包含那些值得怀疑的代码行信息。进行调试的程序员从这里继续，判断到底是什么导致的软件缺陷，并设法修复。
一定要分清软件测试员和程序员的工作。程序员编写代码，测试员寻找软件缺陷，可能还要编写一些代码来驱动测试，然后程序员修复软件缺陷。要进行这样的底层测试，就要使用与程序员相同的工具。如果程序已经编译过，就要使用同样的编辑器，但是采用不同的设置，以加强错误检测功能。
软件测试员可能会使用代码级的调试器来单步跟踪程序，观察变量，设置断点，等等。对于要求合法性检查的独立代码模块，还有编写测试程序进行测试。
三.分段测试
从测试的角度看，产生高额费用有两个原因：
A.难以甚至不可能找出导致问题的原因
B.某些软件缺陷掩盖了其他软件缺陷。
1.单元和集成测试
独立代码段分别建立和测试，然后集成并重新测试。以最小模块为单位的测试叫单元测试或者模块测试。等到经过单元测试，底层的软件缺陷被找出并修复之后，就集成在一起，对模块组进行集成测试。这个不断增加的测试过程继续进行，加入的软件片段逐渐增多，直至整个产品-至少是产品的主要部分--在称为系统测试的过程中一起测试。
采取这种测试策略很容易隔离软件缺陷。在单元级发现问题时，问题肯定就在那个单元中。如果多个单元集成发现软件缺陷，那么它一定与模块之间的交互有关。当然这个也有例外。
这种递增测试有两种方法：
A.自底向上：要编写测试驱动模块，测试驱动模块以将来真正模块同样的方式挂接，向处于测试的模块发送测试案例数据，接受返回结果，验证结果是否正确。采取这种方式，可以对整个软件进行测试，为它提供全部类型和数量的数据，甚至高层难以发送的数据。
B.自顶向下：有点像小规模的大棒测试，先测试高层的软件，然后测试它们下一层的。
注意：在进行白盒子测试之前，一定要根据说明书建立黑盒子测试案例。用这种方式可以看出真正测试模块的用意。如果先从模块的白盒子角度建立测试案例，检查代码，就会偏向模块工作方式建立测试案例。程序员或许错误地解释说明，于是测试案例会不对。虽然仔细测试了模块，但是可能不准确，因为没有测试预期的操作。
四.数据覆盖
看了下笔记，发现很乱，取精华，去糟粕，为了不继续误‘倒’大家，我把网上流行的经典白盒测试用例设计方法COPY过来~
白盒测试的方法：总体上分为静态方法和动态方法两大类。
静态分析是一种不通过执行程序而进行测试的技术。静态分析的关键功能是检查软件的表示和描述是否一致,没有冲突或者没有歧义。
动态分析的主要特点是当软件系统在模拟的或真实的环境中执行之前、之中和之后 , 对软件系统行为的分析。动态分析包含了程序在受控的环境下使用特定的期望结果进行正式的运行。它显示了一个系统在检查状态下是正确还是不正确。在动态分析技术中,最重要的技术是路径和分支测试。下面要介绍的六种覆盖测试方法属于动态分析方法。
1.语句覆盖：语句覆盖是最起码的结构覆盖要求，语句覆盖要求设计足够多的测试用例，使得程序中每条语句至少被执行一次。
2.判定覆盖：判定覆盖又称为分支覆盖，它要求设计足够多的测试用例，使得程序中每个判定至少有一次为真值，有一次为假值，即：程序中的每个分支至少执行一次。每个判断的取真、取假至少执行一次。
3.条件覆盖：条件覆盖要求设计足够多的测试用例，使得判定中的每个条件获得各种可能的结果，即每个条件至少有一次为真值，有一次为假值。
4.判定/条件覆盖：设计足够多的测试用例，使得判定中每个条件的所有可能结果至少出现一次，每个判定本身所有可能结果也至少出现一次。
5.条件组合覆盖：要求设计足够多的测试用例，使得每个判定中条件结果的所有可能组合至少出现一次。
6.路径覆盖：设计足够的测试用例，覆盖程序中所有可能的路径。
（具体例子请看我写的测试试卷一答案整理的大题和白盒子测试方法举例）
总结：白盒测试是一种被广泛使用的逻辑测试方法，是由程序内部逻辑驱动的一种单元测试方法。只有对程序内部十分了解才能进行适度有效的白盒测试。但是贯穿在程序内部的逻辑存在着不确定性和无穷性，尤其对于大规模复杂软件。因此我们不能穷举所有的逻辑路径，即使穷举也未必会带来好运（穷举不能查出程序逻辑规则错误，不能查出数据相关错误，不能查出程序遗漏的路径）。
那么正确使用白盒测试，就要先从代码分析入手，根据不同的代码逻辑规则、语句执行情况，选用适合的覆盖方法。任何一个高效的测试用例，都是针对具体测试场景的。逻辑测试不是片面的测试正确的结果或是测试错误的结果，而是尽可能全面地覆盖每一个逻辑路径。