目录
1. 静态白盒测试：检查设计和代码
静态测试是指测试非运行部分--检查和审查。白盒测试是指访问代码，能够查看和审查。
静态白盒测试是在不执行软件的条件下有条理的审查软件设计、体系结构和代码，从而找出软件缺陷的过程，有时候称为结构化分析。
进行静态白盒测试的主要原因是尽早发现软件缺陷，以找出动态黑盒测试难以发现或者隔离的软件缺陷。
在开发过程初期让测试小组集中精力进行软件设计的审查非常有价值。
2. 正式审查
4要素：
确定问题：审查的目的是找出软件的问题。
遵守规则：审查要遵守一套固定的规则，规则可能设定要审查的代码量，，通常有数百行。
准备：每个参与者都为审查做准备，并尽自己的力量。在审查过程中找出的问题大部分是在准备期间发现的，而不是实际审查期间。
编写报告：审查小组必须做出审查结果的书面总结报告，并使报告便于开发小组的成员使用。诸如发现了多少问题，在哪里发现的。
同事审查
有时又叫伙伴审查。
走查
走查比同事审查更正规的下一步
走查人员中至少有一位是资深程序员。
检验
检验是最正式的审查类型，具有高度组织化，要求每一个参与者必须都接收训练。
编码标准和规范
如何使用某种语言如C++编程规范的示例
3. 通用代码审查清单
数据引用错误
数据引用错误是指使用未经正确声明和初始化的变量、常量、数组、字符串或记录而导致的软件缺陷。
- 是否引用了未初始化的变量？查找遗漏之处与查找错误同等重要
- 数组和字符串的下标是整数值吗？下标总是在数组和字符串长度范围之内吗？
- 在检索操作或者引用数组下标时是否包含“丢掉一个"这样的潜在错误？
- 是否在应该使用常量的地方使用了变量．一一例如在检查数组边界时？
- 变量是否被赋予不同类型的值？例如，无意中使代码为整形变量赋予一个浮点数值？
- 为引用的指针分配内存了吗？
- 一个数据结构是否在多个函数或者子程序中引用，在每一个引用中明确定义结构了吗？
数据声明错误
数据声明缺陷产生的原因是不正确地声明或使用变量和常量。
- 所有变量都赋予正确的长度、类型和存储类了吗？例如，本应声明为字符串的变量声明为字符数组了吗？。
- 变量是否在声明的同时进行了初始化？是否正确初始化并与其类型一致？
- 变量有相似的名称吗？这基本上不算软件缺陷，但有可能是程序中其他地方出现名称混淆的信息。
- 存在声明过、但从未引用或者只引用过一次的变量吗？
- 所有变量在特定模块中都显式声明了吗？如果没有，是否可以理解为该变量与更高级别的模块共享？
计算错误
计算或者运算错误实质上是糟糕的数学问题。计算无法得到预期结果。
- 计算中是否使用了不同数据类型的变量，例如将计算中是否使用了类型相同但长度不同的变量一一例如，将字节与字相加？
- 计算时是否了解和考虑到编译器对类型或长度不一致的变量的转换规则？
- 赋值的目的变量是否小于赋值表达式的值？在数值计算过程中是否可能出现溢出？除数/模是否可能为零？
- 对于整型算术运算，处理某些计算（特别是除法）的代码是否会导致精度丢失？
- 变量的值是否超过有意义的范围？例如，可能性的计算结果是否小于0％或者大于100％？
- 对于包含多个操作数的表达式，求值的次序是否混乱，运算优先级对吗？需要加括号使其清晰吗？
比较错误
小于、大于、等于、不等于、真、假。比较和判断错误很可能是由于边界条件问题。
- ·比较得正确吗？虽然听起来简单，但是比较应该是小于还是小于或等于常常发生混淆。
- 存在分数或者浮点值之间的比较吗？如果有，精度问题会影响比较吗？1.00000001和1.00000002极其接近，它们相等吗？
- 每一个逻辑表达式都正确表达了吗？逻辑计算按预计的进行了吗？求值次序有疑问吗？
- 逻辑表达式的操作数是逻辑值吗？例如，是否包含整数值的整型变量用于逻辑计算中？
控制流错误
控制流程错误的原因是编程语言中循环等控制结构未按预期方式工作。它们通常由计算或者比较错误直接或间接造成。
- 若果程序包含being...end和do···while等语句组，end是否明确给出并与语句组．如果程序包含egn·对应？
- 程序、模块、子程序和循环能否终止？如果不能，可以接受吗？
- 可能存在永远不停的循环吗？
- 循环是否可能永不执行？如果是这样，可以接受吗？
- 如果程序包含像swich...case语句这样的多个分支，索引变量能超出可能的分支数目吗？如果超出，该情况能正确处理吗？
- 是否存在“丢掉一个”错误，导致循环意外的流程？
子程序参数错误
- 子程序参数错误的来源是软件子程序不正确地传递数据。
- 子程序接收的参数类型和大小与调用代码发送的匹配吗？次序正确吗？
- 如果子程序有多个人口点，引用的参数是否与当前人口点没有关联？
- 常量是否当做形参传递，在子程序中被意外改动？
- 子程序更改了仅作为输人值的参数吗？
- 每一个参数的单位是否与相应的形参匹配一一例如，英尺对米？中是否有相同的定义和属性？
输入/输出错误
输入/输出错误包括文件读取、接受键盘或者鼠标输入以及向打印机或者屏幕等输出设备写人错误。下列条目非常简单、通用，应该在使用时补充，以涵盖所测试的软件。
- 软件是否严格遵守外部设备读写数据的专用格式？
- 文件或者外设不存在或者未准备好的错误情况有处理吗？
- 软件是否处理外部设备未连接、不可用，或者读写过程中存储空间占满等情况？
- 软件以预期方式处理预计的错误吗？
- 检查错误提示信息的准确性、正确性、语法和拼写了吗？
其他检查
这个压轴清单定义了一些不适合放在其他类别的条目。这不是为了完整，而是提示为定制软件项目清单应该加人的内容。
- 软件是否使用其他外语？是否处理扩展ASCII字符？是否需要用统一编码取代ASCII？
- 软件是否要移植到其他编译器和CPU，具有这样做的许可吗？如果没有计划或者测试，那么，移植性可能成为一个大难题。
- 是否考虑了兼容性，以使软件能够运行于不同数量的可用内存、不同的内部硬件（例如图形和声卡）、不同的外设（例如打印机和调制解调器）？
- 程序编译是否产生“警告”或者“提示”信息？这些信息通常指示进行了有疑问的处理。纯粹主义者可能认为警告信息是不可接受的。
4.总结
检查代码一一静态白盒测试一一被证实是早期发现软件缺陷最有效的方法。虽然这是一项需要大量准备工作才能有成效的任务，但是许多研究表明花费的时间与得到的好处相比是值得的。为了使这项任务更有吸引力，现在有了能自动执行大量静态白盒测试工作的商业软件，即静态分析程序。该程序读人程序的源文件，并根据公开标准和自定义规范进行检查。编译器也提高了能力，如果启用所有等级的错误检查，它将捕捉到前面通用代码审查清单列出的许多问题，有些编译器甚至不允许使用具有安全问题的函数。这些工具不是取消代码审查或者检查任务一一只是使任务更容易完成，并给软件测试员更多时间来挖掘更深的软件缺陷。
如果开发小组没有在这一级进行测试，而你具有一些编程经验的话，就可以把测试想像为调查过程。程序员和经理开始可能有顾虑，不知道好处有多大一一这很难说出来，比如在检验期间发现一个软件缺陷比一个月之后在黑盒测试期间发现它可以为项目节省5天时间。然而，静态白盒测试正在受到重视，而在某些开发过程中，没有它，项目就无法得到可靠的软件。
扫一扫
2364
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
