白盒测试也称结构测试或逻辑驱动测试，它是按照程序内部的结构测试程序，通过测试来检测产品内部动作是否按照设计规格说明书的规定正常进行，检验程序中的每条通路是否都能按预定要求正确工作。下面介绍静态白盒测试，关于检验代码的一些问题。
1. 说出静态白盒测试的几点好处。
静态白盒测试在开发过程早期发现软件缺陷，使修复的时间和费用大幅度降低。软件测试员可以得到软件如何运作的信息，存在哪些弱点和危险，而且可以与程序员建立良好的伙伴关系。项目状态可以传达给参与测试的所有小组成员。
2. 静态白盒测试可以找出遗漏之处和问题？
对。遗漏的问题比普通的问题更重要，通过静态白盒测试可以发现。当根据公布的标准和规范检查代码，在正式审查中仔细分析时，遗漏的问题就显而易见了。
3. 正式审查由哪些关键要素组成？
过程。按照过程进行是正式检查和两个程序员之间互查代码的区别。
4. 除了更正式外，检验与其他审查类型有什么重大差别？
主要区别是，检验时在场的不是代码的原创者。这迫使另一个人完全理解要检查的软件。这比让其他人只是审查软件寻找软件缺陷更有效。
5. 缓冲区溢出错误作为一个常见的安全问题术语哪一级错误？是由什么原因引起的？
数据引用。它们是由于使用了未正确声明或未进行初始化的变量、常量、数组、字符串或记录。
通用代码审查清单：
在代码审查时，我们可以运用代码审查清单，将以往所有可能发生的常见错误罗列出来，供与会者对照检查，从而提高会审效率。
（1）数据引用错误
数据引用错误是指使用未经正确地初始化的变量、常量、数组、字符串或记录。
＊ 是否引用了未初始化的变量？
＊ 数组和字符串的下标是整数值吗？下标总是在数组和字符串大小范围之内吗？
＊ 在检索操作或者应用数组下标时是否包含“丢掉一个”这样的潜在错误？
＊ 是否在应该使用常量的地方使用了变量？
＊ 变量是否被赋予不同类型的值？
＊ 为引用的指针分配内存了吗？
＊ 一个数据结构是否在多个函数或者子程序中引用，在每一个引用中明确定义结构了吗？
（2）数据声明错误
数据声明错误是指不正确地声明或使用变量和常量。
＊ 所有变量都赋予正确的长度、类型和存储类了吗？
＊ 变量是否在声明的同时进行了初始化？是否正确初始化并与其类型一致？
＊ 变量有相似的名称吗？
＊ 存在声明过、但从未引用或者只引用过一次的变量吗？
＊ 在特定模块中所有变量都显式地声明了吗？
（3）计算错误
计算错误是指基本的数学逻辑问题。
＊ 计算中是否使用了不同数据类型的变量，如整数与浮点数相加？
＊ 计算中是否使用了数据类型相同但字节长度不同的变量？
＊ 计算时是否了解和考虑到编译器对类型或长度不一致的变量的转换规则？
＊ 赋值的目的变量是否小于赋值表达式的值？
＊ 在数值计算过程中是否可能出现溢出？
＊ 除数或模是否可能为零？
＊ 对于整型算术运算或某些计算，特别是除法的代码处理是否会丢失精度？
＊ 变量的值是否超过有意义的范围？
＊ 对于包含多个操作的表达式，求值次序是否混乱，运算优先级对吗？需要加括号使其清晰吗？
（4）比较错误
小于、大于、等于、不等于、真、假、比较和判断错误很可能是边界条件问题。
＊ 比较得正确吗？
＊ 存在分数或者浮点数之间的比较吗？如果有，精度问题会影响比较吗？1.00000001和1.00000002极其接近，它们相等吗？
＊ 每一个逻辑表达式都正确地表达了吗？逻辑计算如期进行了吗？求值次序有疑问吗？
＊ 逻辑表达式的操作数是逻辑值吗？
（5）控制流程错误
控制流程错误是指编程语言中循环等控制结构未按预期方式工作，通常由计算或者比较错误直接或间接造成。
＊ 程序中的语句组是否对应？
＊ 程序、模块、子程序和循环能否终止？如果不能，可以接受吗？
＊ 可能存在永远不停的循环吗？
＊ 循环可能从不执行吗？如果是这样，可能接受吗？
＊ 对于多分支语句，索引变量能超出可能的分支数目吗？如果超出，该情况能正确处理吗？
＊ 是否存在“丢掉一个”错误，导致意外进入循环？
（6）子程序参数错误
子程序参数错误的来源是软件子程序不正确地传递数据。
＊ 子程序接收的参数类型和大小与调用代码发送的匹配吗？次序正确吗？
＊ 如果子程序有多个入口点，引用的参数是否与当前入口点没有关系？
＊ 常量是否当作形参传递，意外在子程序中改动？
＊ 子程序是更改了仅作为输入值的参数？
＊ 每一个参数的单位是否与相应的形参匹配？
＊ 如果存在全局变量，在所有引用子程序中是否有相似的定义和属性？
（7）输入/输出错误
输入/输出错误包括文件读取、接受键盘或鼠标输入以及向输出设备写入错误等。
＊ 软件是否严格遵守外设读写数据的专用格式？
＊ 文件或者外设不存在或者未准备好的错误情况有处理吗？
＊ 软件是否处理外设未连接、不可用、或者读写过程中存储空间占满等情况？
＊ 软件以预期的方式处理预计的错误吗？
＊ 检查错误提示信息的准确性、正确性、语法和拼写了吗？
（8）其他错误
＊ 软件是否使用其他外语？是否处理扩展ASCII字符？是否需用统一编码取代ASCII？
＊ 软件是否需要移植到其他编译器？
＊ 是否考虑了兼容性，以使软件能够运行于不同数量的可用内存、不同的内部硬件、不同的外设等？
＊ 程序编译是否产生“警告”或者“提示”信息？这些信息通常指示语句有疑问。
但在项目小组验证代码时，并不能简单地以这些代码审查清单未标准，因为这只是用做一个通用的示例。其中虽然有谢好的测试用例应该在测试代码时考虑，但是，英爱研读其他公开的标准之后再采用自己的标准。
【编辑推荐】
