静态白盒测试：检查设计和代码

静态白盒测试是在不执行软件的条件下有条理地仔细审查软件设计、体系结构和代码，从而找出软件缺陷的过程，有时称为结构化分析。

进行静态白盒测试的首要原因是尽早发现软件缺陷，以找出动态黑盒测试难以发现或者隔离的软件缺陷。在开发过程初期让测试小组集中精力进行软件设计的审查非常有价值。

进行静态白盒测试的另一个好处是，为黑盒测试员在接受软件进行测试时设计和应用测试用例提供思路。他们可以不必了解代码的细节，但是通过听审评论，可以确定有问题或者容易产生软件缺陷的特性范围。

注意：开发小组负责静态白盒测试的人员不是固定的。在某些小组中，程序员就是组织和执行审查的人员，软件测试员被被邀请作为独立的观察者。还有一些小组中，软件测试员是该任务的执行人，要求编写代码的程序员和其他同事帮助审查。

正式审查

正式审查就是进行静态白盒测试的过程。正式审查的含义很广，从两个程序员之间的简单交谈，到软件设计和代码的详细、严格检查均属于此过程。

正式审查有4个基本要素：

确定问题  审查的目的是找出软件的问题——不仅是出错的项目，还包括遗漏项目。全部的批评应该直指代码或设计，而不是其设计实现者。

遵守规则  审查要遵守一套固定的规则，规则可能设定要审查的代码量花费多少时间，哪些内容要做评价等。其重要性在于参与者了解自己的角色目标是什么。

准备  每一个参与者都为审查做准备，并尽自己的力量。

编写报告  审查小组必须做出审查结果的书面总结报告，并使报告便于开发小组的成员使用。

如果审查正确地进行，就可以证明这是早期发现软件缺陷的好方法。

除了发现问题，坚持正式审查还有一些间接效果：

交流  正式报告中未包含的信息得以交流。

质量  程序员的代码经过逐个功能、逐行代码仔细复查，常常会使程序员变得更加仔细。

小组同志化  如果审查正确进行，就会建立软件测试员和程序员对双方技艺的相互尊重。

解决方案  尽管是否讨论解决方案取决于审查的规则，但是解决方案应该用于处理严重问题。

同事审查

召集小组成员进行初次正式审查最简单的方法是通过同事审查的方式。这是要求最低的正式方法，有时也称伙伴审查。

走查

走查是比同事审查更正规化的下一步。走查中编写代码的程序员向5人小组或者其他程序员和测试员组成的小组做正式陈述。审查人员应该在审查之前接到软件拷贝，以便检查并编写备注和问题，在审查过程中提问。审查人员之中至少有一位资深程序员是很重要的。

陈述者逐行或者逐个功能地通读代码，解释代码为什么且如何工作。审查人员聆听舒述，提出有疑义的问题。由于公开陈述的参与人数要多于同事审查，因此，为审查做好准备和遵守规则是非常重要的。同样重要的是审查之后，表述者编写报告说明发现了哪些问题，计划如何解决发现的软件缺陷。

检验

检验是最正式的审查类型，具有高度组织化，要求每一个参与者都接受训练。检验与同事审查和走查的不同之处在于表述代码的人——表述者或者宣读者——不是原来的程序员。这就迫使他学习和了解要表述的材料，从而有可能在检验会议上提出不同的看法和解释。

其余的参与者称为检验员，其职责是从不同的角度，例如用户、测试员或者产品支持人员的角度审查代码。这有助于从不同视角来审查产品，通常可以指出不同的软件缺陷。检查员甚至要担负着倒过来审查代码的责任——也就是说，从尾至头——确保材料的彻底和完整。

有些检验员还同时被委任为会议协调员和会议记录员，以保证检验过程遵守规则及审查有效进行。

检验经证实是所有软件交付内容中，特别是设计文档和代码中发现软件缺陷非常有效的方法，随着公司和产品开发小组发现其好处多多而日趋流行。

编码标准和规范

有三个重要的原因要坚持标准或规范：

可靠性  事实证明按照某种标准或者规范编写的代码易于阅读、理解和维护。

可读性/维护性  符合设备标准和规范的代码易于阅读、理解和维护。

移植性  代码经常需要在不同的硬件中运行，或者使用不同的编译器编译。如果代码符合设备要求，迁移到另一个平台就会轻而易举，甚至完全没有障碍。

通用代码审查清单

数据引用错误

数据引用错误是指使用未经正确声明和初始化的变量、常量、数组、字符串或记录而导致的软化缺陷。

数据声明错误

数据声明缺陷产生的原因是不正确地声明或使用变量和常量。

计算错误

计算或者运算错误实质上是糟糕的数学问题。计算无法得到预期结果。

比较错误

比较和判断错误很可能是由于边界条件问题。

控制流程错误

控制流程错误的原因是编程语言中循环等控制结构未按预期方式工作。它们通常由计算或者比较错误直接或间接造成。

子程序参数错误

子程序参数错误的来源是软件子程序不正确地传递数据。

输入/输出错误

输入/输出错误包括文件读取、接受键盘或者鼠标输入以及向打印机或者屏幕等输出设备写入错误。

其他检查