静态白盒测试

一.静态白盒子测试：检查设计和代码
     静态测试是指测试非运行部分——检查和审查。白盒测试是指访

问代码，能够查看和审查。静态白盒测试实在不执行的条件下有条理地

仔细审查软件设计、体系结构和代码，从而找出软件缺陷的过程。有时

也称为结构分析。
     进行静态白盒子测试的首要原因就是尽早发现软件缺陷，以找出

动态黑盒子测试难以揭示或遇到的软件缺陷；另一个好处是为接受该软

件测试的黑盒测试员的测试案例提供思路，他们不必了解代码细节，但

是根据审查备注，可以确定似乎有问题或者存在软件缺陷的特性范围。

二.正式审查
    正式审查就是进行静态白盒子测试的过程。正式审查含义广泛，从

程序员之间的交谈，到代码的严格检查均属于此过程。            

有4个基本要素：
1.确定问题。审查的目标是找出软件的问题，不仅是出错的项目，还包

括遗漏的项目。全部的批评应直指代码，而不是其创建者。合作者不应

该互相指责。个人情绪化感觉要保留。
2.遵守规则。 审查要遵守一套固定的规则，规则可能设定要审查的代

码量、花费多少时间、哪些内容要做备注等等。其重要性在于合作者了

解自己的作用和目标，这有助于使审查进展的更加顺利。
3. 准备。每个合作者需要了解自己的责任和义务，并积极参与审查。

在审查过程中找出问题大部分的缺陷是在准备期间发现的，而不是实际

审查期间。
4.编写报告。审查小组必须做出总结审查结果的书面报告，并使报告便

于开发小组使用。审查结果必须尽快告诉别人，比如发现多少问题，在

哪发现的。

正式审查有三种类型：
1.同事审查：召集小组成员进行初次正式审查是最简单的方法就是同时

审查。类似于“各抒己见”类型的讨论。常常仅在编写代码的程序员和

充当审查者的其他一两个程序员和测试员之间进行；
2.公开陈述：公开陈述是使同事审查正规化的下一步。编写代码的程序

员像5人小组或其它类似的程序员或测试员正式表述。审查人员应该在

审查之前接到软件拷贝，以便检查并编写备注和问题，在审查过程中提

问。
3.检验：检验是最正式的审查类型，具有高度组织化，要求每一个参与

者都接受训练。检验与同事审查不同之处在于，表述代码的人不是原来

的程序员。这就迫使他学习和了解要表述的材料，从而有可能在检验会

议上提出不同的看法和解释。另外的参与者称为检验员，职责是从不同

的角度（如用户、测试员或产品支持人员）的角度审查代码。检验会议

后，检验员可能再次碰头讨论他们发现的不足之处，并与会议主席共同

准备一份书面报告，明确解决问题所必须重做的工作。然后程序员进行

修改，由会议验证修改结果，可能要要进行重新检验，以便找到其余的

软件缺陷。

三.编码标准和规范

3个坚持标准和规范的重要原因：
1.可靠性。事实证明按照按规范编写的代码更可靠，软件缺陷将更少。
2.可读性/维护性。符合标准和规范的代码易于阅读，理解和维护。
3.移植性。如果代码符合设备标准，迁移到另一个平台就会容易，甚至

没有任何障碍。

标准由4个主要部分组成：
1.标题。描述标准包含的主题。
2.标准（或规范）。描述标准（或规范）内容，解释哪些允许，哪些不

允许。
3.解释说明。给出标准背后的原因，让人理解这为什么是好的编程习惯
4.示例。给出如何使用此种标准的简单程序示例，这不是必需的。
    但是，对软件进行正式审查时，测试和注解的对象仅限于错误和缺

漏，而不管是否坚持标准或者规范！

四.通用代码审查清单
1.数据引用错误
数据引用错误是指使用未经正确地初始化的变量、常量、数组、字符串或记录。
A. 是否引用了未初始化的变量？
B. 数组和字符串的下标是整数值吗？下标总是在数组和字符串大小范围之内吗？
C.在检索操作或者应用数组下标时是否包含"丢掉一个"这样的潜在错误？
D.是否在应该使用常量的地方使用了变量？
E.变量是否被赋予不同类型的值？
F.为引用的指针分配内存了吗？
G.一个数据结构是否在多个函数或者子程序中引用，在每一个引用中明确定义结构了吗？
2.数据声明错误
数据声明错误是指不正确地声明或使用变量和常量。
A.所有变量都赋予正确的长度、类型和存储类了吗？
B. 变量是否在声明的同时进行了初始化？是否正确初始化并与其类型一致？
C.变量有相似的名称吗？
D.存在声明过、但从未引用或者只引用过一次的变量吗？
E.在特定模块中所有变量都显式地声明了吗？
3.计算错误
计算错误是指基本的数学逻辑问题。
A.计算中是否使用了不同数据类型的变量，如整数与浮点数相加？
B.计算中是否使用了数据类型相同但字节长度不同的变量？
C.计算时是否了解和考虑到编译器对类型或长度不一致的变量的转换规则？
D.赋值的目的变量是否小于赋值表达式的值？
E.在数值计算过程中是否可能出现溢出？
F.除数或模是否可能为零？
G.对于整型算术运算或某些计算，特别是除法的代码处理是否会丢失精度？
H. 变量的值是否超过有意义的范围？
I. 对于包含多个操作的表达式，求值次序是否混乱，运算优先级对吗？需要加括号使其清晰吗？
4.比较错误
小于、大于、等于、不等于、真、假、比较和判断错误很可能是边界条件问题。
A.比较得正确吗？
B.存在分数或者浮点数之间的比较吗？如果有，精度问题会影响比较吗？1.00000001和1.00000002极其接近，它们相等吗？
C.每一个逻辑表达式都正确地表达了吗？逻辑计算如期进行了吗？求值次序有疑问吗？
D.逻辑表达式的操作数是逻辑值吗？
5.控制流程错误
控制流程错误是指编程语言中循环等控制结构未按预期方式工作，通常由计算或者比较错误直接或间接造成。
A.程序中的语句组是否对应？
B.程序、模块、子程序和循环能否终止？如果不能，可以接受吗？
C.可能存在永远不停的循环吗？
D.循环可能从不执行吗？如果是这样，可能接受吗？
E.对于多分支语句，索引变量能超出可能的分支数目吗？如果超出，该情况能正确处理吗？
F.是否存在"丢掉一个"错误，导致意外进入循环？
6.子程序参数错误
子程序参数错误的来源是软件子程序不正确地传递数据。
A.子程序接收的参数类型和大小与调用代码发送的匹配吗？次序正确吗？
B.如果子程序有多个入口点，引用的参数是否与当前入口点没有关系？
C.常量是否当作形参传递，意外在子程序中改动？
D. 子程序是更改了仅作为输入值的参数？
E.每一个参数的单位是否与相应的形参匹配？
F.如果存在全局变量，在所有引用子程序中是否有相似的定义和属性？
7.输入/输出错误
输入/输出错误包括文件读取、接受键盘或鼠标输入以及向输出设备写入错误等。
A.软件是否严格遵守外设读写数据的专用格式？
C. 软件是否处理外设未连接、不可用、或者读写过程中存储空间占满等情况？
D.软件以预期的方式处理预计的错误吗？
E.检查错误提示信息的准确性、正确性、语法和拼写了吗？
8.其他错误
A.软件是否使用其他外语？是否处理扩展ASCII字符？是否需用统一编码取代ASCII？
B. 软件是否需要移植到其他编译器？
C.是否考虑了兼容性，以使软件能够运行于不同数量的可用内存、不同的内部硬件、不同的外设等？
D.程序编译是否产生"警告"或者"提示"信息？这些信息通常指示语句有疑问。