通过代码审查清单

　　1. 数据引用错误

　　是指使用未经正确初始化用法和引用方式的变量、常量、数组、字符串或记录而导致的软件缺陷。如：变量未初始化、数组和字符串下标越界、对数组的下标操作遗漏[0]、变量与赋值类型不一致、引用的指针未分配内存……

　　2. 数据声明错误

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

　　3. 计算错误

　　计算或者运算错误是基本的数学逻辑问题。计算无法得到预期结果。如：不同数据类型 或 数据类型相同但长度不同的变量计算、计算过程中或计算结果溢出、赋值的目的变量上界小于赋值表达式的值、除数/模为0、变量的值超过有意义的范围（如概率的计算结果不在0－1范围内）……

　　4. 比较错误

　　小于、大于、等于、不等于、真、假。比较和判断错误很可能是边界条件问题。如：混淆小于和小于等于、逻辑表达式中的操作数不是逻辑值……

　　5. 控制流程错误

　　控制流程错误的原因是编程语言中循环等控制结构未按预期方式工作。通常由计算或者比较错误直接或间接造成。如：模块或循环无法终止、存在从未执行的代码、由于变量赋值错误而意外进入循环……

　　6. 子程序参数错误

　　子程序参数错误的来源是软件子程序不正确的传递数据。如：实际传送的参数类型或次序与定义不一致、更改了仅作为输入值的参数……

　　7. 输入/输出错误

　　包括文件读取、接受键盘或者鼠标输入以及向打印机或者屏幕等输出设备写入错误。如：软件没有严格遵守外部设备读写数据的专用格式、文件或外设不存在或者为准备好的错误情况发生时没有相应处理、未以预期的方式处理预计错误、错误提示信息不正确/不准确……

　　8. 其他检查

　　软件是否使用其他外语？处理字符集的范围（ASCII或Unicode）？是否需要移植？是否考虑兼容性？编译时是否产生警告或提示信息？

　　动态白盒测试

　　动态白盒测试是指利用查看代码功能和实现方式得到的信息来确定哪些要测试，哪些不要测试，如何开展测试。动态白盒测试的另一个常用名称是结构测试，因为软件测试员可以查看并使用代码的内部结构，从而设计和执行测试。

　　动态白盒测试不仅仅是查看代码，还包括直接参数和控制软件。动态白盒测试包括以下4个部分：

　　－ 直接测试底层功能、过程、子程序和库。即应用程序接口（API）

　　－ 以完整程序的方式从顶层测试软件，但是要根据对软件运行的了解调整测试案例。

　　－ 从软件获得读取变量和状态信息的访问权，以便确定测试与预期结果是否相符，同时，强制软件以

　　正常测试难以实现的方式运行。

　　－ 估算执行测试时“命中”的代码量和具体代码，然后调整测试，去掉多余的，补充遗漏的。

　　动态白盒测试 vs 调试

　　白盒测试的目标是寻找软件缺陷，调试的目的是修复它们。但是二者又有交叉的现象。测试员应该把问题缩减为能够演示软件缺陷的简化测试案例。在白盒测试中，甚至要包含那些值得怀疑的代码行信息，以方便程序员有针对性的分析、判断进而修复。

　　一定要分清软件测试员和程序员的工作。程序员编写代码，测试员寻找软件缺陷，可能还要编写一些代码来驱

　　动测试，然后程序员修复软件缺陷。

　　要进行这样的底层测试，要使用与程序员相同的工具。如果程序已经编译过，要使用同样的编辑器，但是

　　采用不同的设置，以加强错误检测功能。

　　分段测试

　　从测试的角度看，产生高额费用有两个原因：

　　－ 难以甚至不可能找出导致问题的原因

　　－ 某些软件缺陷掩盖了其他软件缺陷。造成核心错误很难弄清。

　　单元测试和集成测试

　　在底层进行的测试称为单元测试或者模块测试。等到单元测试后，底层软件缺陷被找出并修复之后，集成在一起，对模块组进行集成测试。后直到整个产品（至少是主要部分）集成到一起进行系统测试。

　　这种测试策略很容易隔离软件缺陷。主要有两条途径：

　　－ 自底向上

　　需要编写测试驱动模块来测试对象模块。测试驱动模块以将来真正模块同样的方式挂接，向处于测试底案例发送测试案例数据，接受返回结果，验证结果是否正确。

　　－ 自顶向下

　　这种情况下，可以使用测试存根代码的编写，充当下层接口模块，从文件中直接将参数提供给上层模块。这样，可以从头到尾试验各种测试值，验证上层模块的操作。

　　示例：C语言中，将ASCII字符转换为整数值的函数atoi()。

　　－ 首先，确定该模块在程序中的位置——底层模块，可以由高层模块调用，但是自己不能调用其他模块。通过查看内部代码可以确认这一点。

　　－ 由上一步判定，确定应编写一个测试驱动以独立于程序其他不分的形式测验该模块。该测试驱动提

　　供测试字符串，读取返回值，与预期结果相比较。编写测试驱动的语言可以与函数的语言相同也可以不同；形式上，可以是简单的对话框（交互性和灵活性强），也可以是独立的程序（可快速的从文件读写测试用例）。

　　－ 分析说明书，确定应该采用的黑盒测试案例，然后运用等价分配技术参少测试案例集合。

　　－ 研究代码看函数是如何实现的，利用模块的白盒知识增减测试用例。

　　注意：在进行白盒测试之前，一定么根据说明书建立黑盒测试案例。这样才能够保证真正测试模块的用意，完成测试预期的操作，而避免白盒测试中受代码的影响而偏向模块工作方式建立测试案例。

　　白盒测试时，合理的做法也是把软件分成数据和状态（或者程序流程）。从同样的角度看待软件，可以很轻松的把白盒信息映射到已经写完的黑盒测试案例上。

　　数据范围

　　数据包括所有的变量、常量、数组、数据结构、键盘和鼠标输入、文件、屏幕输入/输出，以及调制解调器、网络等其他设备的输入/输出。

　　1. 数据流

　　数据流范围主要是指在整个软件中跟踪一批数据。在单元测试级，数据仅仅通过了一个模块或者函数。如果在底层测试，会使用调试器和观察变量在程序运行时查看代码，检查中间值，从而保证质量。

　　2. 次边界

　　白盒测试要仔细检查代码，找到次边界条件，并建立测试他们的案例。除了ASCII码表和2的乘方之外，常见的例子比如：运算时可能由使用数据表转向使用公式；数据可能由RAM转向硬盘；数值分析程序可能根据数字大小采用不同的方程式……

　　3. 公式和等式

　　公式和等式通常深藏于代码中，从外部看，表现和影响不是很明显。但是，在某些公式中，比如：

　　A=P(1+r/n)，白盒测试员在看到这个公式之后，知道选择n=0作为测试案例将导致除零错，这样不需运行测试用例即可预知缺陷。

　　然而，如果n是计算的结果（即可能会有很多种可能值），那么测试员应该考虑有没有n为零值的情形，并指出什么样的程序输入会导致它出现。

　　4. 错误强制

　　在执行测试用例时，不能或不方便使某一变量达到设定值，可通过强制赋值的方式达到目的。

　　在使用错误强制时，小心不要设立现实世界中不可能出现的情况。比如，上例中，如果函数开头有判断n值必须大于0，而且n只存在于该公式中，那么将n值强制设为零的测试案例是不合理的。使用错误强制是迫使软件中所有错误提示信息显示出来的好方法。因为许多错误情况是难以建立的，比如挂接2049台打印机。如果只是想测试错误提示信息是否正确，那么使用错误强制是有效的。

　　代码范围

　　测试程序的状态以及其中的程序流程，必须设法进入和退出每一个模块，执行每一行代码，追踪每一条逻辑和决策分支。按级别详细检查软件称为代码范围分析。代码范围分析要求通过完全访问代码查看运行测试案例时经过哪些部分。其简单的形式是利用编译环境的调试器通过单步执行程序查看代码。对于大程序，需要用到称为代码范围分析器的专用工具。从的得到的数据中可以很容易的获知：测试案例没有覆盖软件的哪些部分、哪些测试案例是多余的（增加该案例却未增加代码覆盖比例）等，从而判定还需要建立哪些新的测试案例。

　　程序语句和代码行范围

　　代码范围直接的形式称为语句范围或者代码行范围。如果在测试软件的同时监视语句范围，目标是保证程序中每一条语句少执行一次。但是，从某种程度上说，语句范围是一种误导，因为即使全部语句被执行了，并不代表走遍了软件的所有路径。

　　分支范围

　　试图覆盖软件中的所有路径称为路径测试。路径测试简单的形式称为分支范围测试。注意每一个判断条件（组合）都会产生分支，即每个判断条件（条件组合）的结果取真或假，都应该执行一次。

　　条件范围

　　条件范围测试将分支语句的附加条件考虑在内。与分支范围不同的地方主要体现在多重条件的组合上。分支范围把条件组合看作一个整体，而条件范围把这种组合拆开，而对每个具体条件进行分析。保证每个具体条件的真假取值都做一遍。