编码规范和标准：可以运行并且测试中也表现稳定的代码被称为有问题，令人不易理解。一般有三个重要原因需要坚持标准和规范。
· 可靠性：事实证明按照某种标准或者规范写的代码更加可靠。
· 可读性/维护性：符合设备标准的规范代码容易阅读、理解和维护。
· 移植性：如果代码符合设备标准，移植将很轻松。
静态白盒测试可能遇到的问题类型：
· 数据引用出错
· 数据声明错
· 计算错误
· 比较错误
· 控制流程错误
· 子程序参数错误
· 输入/输出错误
· 其他
动态白盒基本测试内容：
· 直接测试底层功能、过程、子程序和库。
· 以完整程序方式从顶层测试软件，然后根据软件运行了解和调整测试案例。
· 从软件获得读取变量和状态信息的访问权，以便确定测试与预期结果是否相等。
· 估算执行测试时命中的代码量和具体代码，然后调整测试。
动态白盒测试和调试：两者不能混为一谈，虽然会有交叉，调试是程序员做的，目的是修复问题。测试是为了找到缺陷。测试员可能要使用代码级调试器单步执行，观察变量，设置断点等。对于要求合法性检查的独立代码模块，还要编写测试程序进行测试。
黑盒与白盒：进行白盒测试之前，要根据说明书建立黑盒测试案例，这种方法可以真正理解测试用途。否则会偏向模块的工作方式，程序员的说明也许包含错误，所以测试案例可能出现问题。
数据范围：白盒测试合理的方法是把软件分成数据和状态（或者程序流程）。同时可以把白盒信息映射到已经写完的黑盒案例中。
首先考虑数据：包括所有变量、常量、数组、数据结构、键盘鼠标输入、文件、屏幕输入输出。以及调制解调器、网络等其他设备的输入/输出。
数据可以分成如下类型：
· 数据流。观察数据在各个模块甚至整个程序中的各种状态值。
· 次边界。寻找次边界条件。比如2的乘方。
· 公式和等式。比如被0除问题。
· 错误强制。有的错无条件不好模拟，需要制造错误。但是不要制造实际无法出现的错误。
代码覆盖：为了全面，必须测试程序的状态及其中的程序流程，设法进入和退出每一个模块，执行每一行代码，追踪每一条逻辑和决策分支。
最简单的方法是利用编译环境单步执行。大多数程序要用专门的代码范围分析器。需要注意的是，全部语句都执行一遍，不等于走遍了软件的所有路径。所以需要分支覆盖。分支覆盖也不完全，还要考虑条件范围问题。如果测试了所有可能的条件，达到了分支覆盖，顺便达到了语句覆盖。
配置测试：
因为无法保证用户的设备都符合通用的标准，所以需要把软件放在用户使用比较广泛的硬件上进行测试。
测试要点：
· 确定需要测试的硬件类型。
· 明确硬件标准。
· 确定可能的硬件属性，模式和选项。
· 分离配置缺陷。
· 等价分配。
· 只测试各种硬件不交叉的部分。
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系51Testing小编(021-64471599-8017)，我们将立即处理
