白盒测试又称结构测试、逻辑驱动测试或基于代码的测试。
白盒测试是一种测试用例设计方法，盒子指的是被测试的软件，白盒指的是盒子是可视的，即清楚盒子内部的东西以及里面是如何运作的。
"白盒"法需要测试者了解程序内部逻辑结构，对所有逻辑路径进行测试，也就是说，"白盒"法是“穷举路径测试”。
二、白盒测试的分类总体上分为静态分析和动态分析两大类。
静态分析：不需要执行程序，就可以进行的测试，例如：代码审查、代码扫描
动态分析：需要执行程序，才可以进行的测试，例如：单元测试、覆盖测试
三、白盒测试的设计方法
静态方法关注代码是否符合已制定的编码规范、发现潜在的bug或漏洞，更强调开发人员的参与。或者直接交给自动化代码检查工具去做，如SonarQube等
如何开展静态方法，可参考：
https://blog.csdn.net/chichichi0813/article/details/80814596
五、白盒测试动态方法动态方法是白盒测试人员主要参与的环节。
1、逻辑覆盖法
原则：以程序内部的逻辑结构为基础设计测试用例。
逻辑覆盖包括语句覆盖、判定覆盖、条件覆盖、判定／条件覆盖、条件组合覆盖和路径覆盖。
以上六种覆盖标准发现错误的能力呈由弱到强变化：
- 语句覆盖每条语句至少执行一次。
- 判定覆盖每个判定的每个分支至少执行一次。
- 条件覆盖每个判定的每个条件应取到各种可能的值。
- 判定条件覆盖同时满足判定覆盖条件覆盖。
- 条件组合覆盖每个判定中各条件的每一种组合至少出现一次。
- 路径覆盖使程序中每一条可能的路径至少执行一次。
之所以六种覆盖标准发现错误的能力有差异，是因为使用每种覆盖标准所设计的测试用例对程序内部逻辑的覆盖率不同。
覆盖率是什么？
覆盖率是用来度量测试完整性的一个指标。
以下图的示例代码为例，分别说明每种覆盖标准的测试覆盖率。
1.1、语句覆盖（SC）
语句覆盖：设计足够多的测试用例，使得运行这些测试用例时，被测程序的每一个语句至少执行一次，其覆盖标准无法发现运算中的逻辑关系错误。
示例代码中共有4条可执行语句
设计测试用例执行了3条，语句覆盖率为3/4=75%
1.2、判定覆盖（DC）
判定覆盖：设计足够多的测试用例，使得程序中的每一个判断至少获得一次“真”和一次“假”，即使得程序流程图中的每一个真假分支至少被执行一次。
但若程序中的判定是有几个条件联合构成时，未必能发现每个条件的错误。
示例代码中有判定2个，判定结果4个
设计测试用例执行了3个分支，分支覆盖率为3/4=75%
1.3、条件覆盖（CC）
条件覆盖：设计足够多的测试用例，使得运行这些测试用例时，使得判定中的每个条件至少有一次取真值，有一次取假值。
但未必能覆盖全部分支。
案例代码中有判定2个，条件3个，条件结果6个
设计测试用例执行了5个条件结果，条件覆盖率为5/6=83%
1.4、判定／条件覆盖（DCC）
判定／条件覆盖：设计足够多的测试用例，使得被测试程序中的每个判断本身的判定结果（真假）至少满足一次，同时，每个逻辑条件的可能值（真假）也至少被满足一次。
即同时满足100%判定覆盖和100%条件覆盖的标准。
示例代码中有判定2个，条件3个，判定结果4个，条件结果6个
设计测试用例执行了3个判定结果，5个条件结果，判定条件覆盖率为：（3 5）/（4 6）=80%
1.5、条件组合覆盖（BCCC）
条件组合覆盖：设计足够多的测试用例，使得被测试程序中的每个判定中条件结果的所有可能组合至少执行一次。
显然，满足“条件组合覆盖”的测试用例是一定满足“判定覆盖”、“条件覆盖”和“判定/条件覆盖”的。
示例代码中有判定2个，条件3个（判定1有2个条件，判定2有1个条件），判定1的条件组合为4个，判定2的条件组合为2个
设计测试用例执行了5个条件组合，条件组合覆盖率为：5/（4 2）=83%
1.6、路径覆盖
路径覆盖：设计足够多的测试用例，覆盖被测试程序中的所有可能路径，是最强的覆盖准则。
案例代码中共有4条路径
设计测试用例执行了3条路径，路径覆盖率为3/4=75%
2、基本路径测试法
理想情况下，路径覆盖需要覆盖程序中所有可能的路径。但在路径数目很大时，真正做到完全覆盖是很困难的，
必须把覆盖路径数目压缩到一定限度。例如程序中的循环体只执行一次。
所以，基本路径测试法可以理解为压缩后的路径覆盖。
基本路径测试法如何操作？
在程序控制流图的基础上，通过分析程序的环路复杂性，导出基本可执行路径集合，从而设计测试用例。
程序的控制流图：描述程序控制流的一种图示方法
程序环路复杂度：McCabe复杂性度量。从程序的环路复杂性可导出程序基本路径集合中的独立路径条数。
导出测试用例：根据圈复杂度和程序结构设计用例数据输入和预期结果。
准备测试用例：确保基本路径集中的每一条路径的执行。
步骤：
展开：
1. 优点
- 可以检测代码中的每条分支和路径
- 揭示隐藏在代码中的错误
- 对代码的测试比较彻底
- 让软件最优化
2. 缺点
- 投入成本高昂
- 覆盖所有代码路径难度大
- 不能替代集成测试
