白盒测试，也称为结构化测试、基于代码的测试，是一种测试用例设计方法，它从程序的控制结构导出测试用例。用白盒测试产生的测试用例能够：测试用例模板
1）保证一个模块中的所有独立路径至少被使用一次；
2）对所有逻辑值均需测试true和false；
3）在上下边界及可操作范围内运行所有循环；
4）检查内部数据结构以确保其有效性。
“我们应该更注重于保证程序需求的实现，为什么要花费时间和精力来担心（和测试）逻辑细节？”答案在于软件自身的缺陷：
· 逻辑错误和不正确假设与一条程序路径被运行的可能性成反比。当我们设计和实现主流之外的功能、条件或控制时，错误往往开始出现在我们工作中。日常处理往往被很好地了解，而“特殊情况”的处理则难于发现。
· 我们经常相信某逻辑路径不可能被执行，而事实上，它可能在正常的基础上被执行。程序的逻辑流有时是违反直觉的，这意味着我们关于控制流和数据流的一些无意识的假设可能导致设计错误，只有路径测试才能发现这些错误。
· 笔误是随机的。当一个程序被翻译为程序设计语言源代码时，有可能产生某些笔误，很多将被语法检查机制发现，但是，其他的会在测试开始时才会被发现。笔误出现在主流上和不明显的逻辑路径上的机率是一样的。
正如Beizer所说的：“错误潜伏在角落里，聚集在边界上”，而白盒测试更可能发现它
国内很少公司花很大的精力去做白盒测试，一般在单元测试过程中，白盒测试全是由开发人员来完成，商业软件所使用到的技术主要是黑盒测试技术，这是其特点所决定的。还有少量的白盒技术，但在实际中很少有公司愿意投入人力来作。
白盒测试的方法：
1.确定软件中的模块（数据计算、校验模块、功能模块）
2.在每一个模块中用常用的覆盖率覆盖方法计算所有满足的路径（覆盖率方法有很多，看软件要求程度，比如航空、医疗软件要求严格，使用Do-178B的MC/DC覆盖率标准）
3.设计测试用例，满足覆盖要求（注：想满足所有路径都覆盖是不可能的，花费也随之上升，没有公司愿意这么做，不现实）。
在经费和时间不足的情况下，应采取对关键点的白盒测试，就是针对重要环节的测试，然后用黑盒测试做补充，目前国内大多数公司采用：先对软件进行黑盒测试，然后查看覆盖率再对未覆盖的代码进行白盒测试，这样做可以节省时间和花费，当然缺点也有，毕竟黑盒测试不能代替白盒测试，即使在正确的输入下得到正确的输出也未必是所设想的路径。
文章来源于领测软件测试网 https://www.ltesting.net/
