白盒测试策略
目 录
1 白盒测试 .................................................................................................................3
概念...........................................................................................................................................3
描述...........................................................................................................................................3
目的...........................................................................................................................................3
2 白盒测试策略 .........................................................................................................3
桌前检查...................................................................................................................................3
单元测试...................................................................................................................................3
代码评审...................................................................................................................................4
同行评审...................................................................................................................................4
代码走查...................................................................................................................................5
静态分析...................................................................................................................................5
1 白盒测试
概念
白盒测试又称结构测试，透明盒测试、逻辑驱动测试或基于代码的测试。
描述
白盒测试是测试被测单元内部如何工作的一种方法。
目的
通过检查软件内部的逻辑结构，对软件中的逻辑路径进行覆盖测试；在程序
不同地方设立检查点，检查程序的状态，以确定实际运行状态与预期状态是否一
致。它允许测试人员对程序内部逻辑结构及有关信息来设计和选择测试用例，对
程序的逻辑进行测试，提高代码质量。
2 白盒测试策略
在软件过程的不同阶段，研发组都可能需要进行白盒测试。根据团队实际情
况的不同，有选择的使用下面的策略：
桌前检查
简述：程序员实现制定功能后，进行单元测试之前，对源代码进行的初步检
查。
重点：编码规范、语句的使用等是否符合编码规范，并根据《编码规范》调
整自己的代码以符合编码规范的要求。
参与人员：开发人员。
单元测试
简述：又称模块测试。传统结构化编程中，以一个函数、过程为一个单元；
在面向对象的编程中一般把类作为单元进行测试。
重点：采用白盒测试和黑盒测试方法相结合。
参与人员：专门的白盒测试人员。
代码评审
简述：在编码初期或编写过程中采用一种有同行参与的评审活动。
重点：通过组织或其他程序员共同查看程序，可以找出问题，使大家的代码
风格一致或遵守编码规范。
方法：通过大家共同阅读代码或由程序编写者讲解代码，其他同行边听边分
析问题的方法。
参与人员：全体开发小组。
同行评审
简述：引用 CMM（能力成熟度模型）中的术语，如用在评审源代码上，就
使代码评审；在同行评审中，由软件工作产品创建者的同行们检查该工作的
产品，识别产品的缺陷，改进产品的不足。
目的：
1. 检验工作产品是否正确的满足了以往的工作产品中建立的规范，如需求
或设计文档；
2. 识别工作产品相对于标准的偏差，包括可能影响软件可维护性的问题；
3. 向创建者提出改进建议；
4. 促进参与者之间的技术交流和学习。
参与人员：程序员、设计师、单元测试工程师、维护者、需求分析师、编码
标准专家（此为 CMM 标准中提出的参与角色，可根据实际情况调整，至少
需要开发人员、测试人员、设计师参与）。
代码走查
简述：由测试小组组织或者专门的代码走查小组进行代码走查，这时需要开
发人员提交有关的资料文档和源代码给走查人员，并进行必要的讲解。
代码走查往往根据《代码检查单》来进行，代码检查单常常是根据
《编码规范》总结出来的一些条目，目的是检查代码是否按照《编码规范》
来编写的。当然，代码走查的最终目的还是为了发现代码中潜在的错误和缺
陷。
重点：
1. 把材料（《需求描述文档》、《程序设计文档》、《程序的源代码清单》、
《代码编码标准》、《代码缺陷检查表》等）发给走查小组每个成员，让
他们认真研究程序；
2. 开会，让与会者“充当”计算机，让测试用例沿程序的逻辑运行一遍，随
时记录程序的踪迹，供分析和讨论，发现更多的问题。
参与人员：测试人员（一般不让代码的创建者参与）。
代码检查速度建议：汇编代码与 C 代码 150 行/小时，C++/Java 200-300 行/
小时。
静态分析
简述：由测试小组来进行，静态分析通常需要辅助工具支持，通过提取代码
信息，进行统计，根据统计结果对源代码进行质量评估。代码规则检查也是
静态分析的一个方面。
人员：测试小组。
工具介绍：
1. PC-Lint：
支持 C/C++语言；
优点：工具简单实用，可以选择编码规范标准，数据检查技术；
缺点：不是图形用户界面，危险的用法，C/C++的兼容性问题。
2. CodeWizard：
支持 C/C++语言；
优点：图形用户界面，方便规则定制；
缺点：分析速度慢。
3. Logiscope：
支持 C/C++语言；
优点：图形界面，可以生成代码质量报告；
缺点：规则不是特别多；
Logiscope 是面向源代码进行工作的，贯穿于软件开发、代码评审、单元
测试、集成测试、系统测试、以及软件维护阶段。也是中小型公司常用的代
码静态分析工具。
4. Testbed：
支持 C 语言；
优点：规则特别多；
缺点：规则定制比较麻烦，时常可能误报，需要人工判断。
5. QAC/QAC++：
版本决定支持那种语言，一般以 C/C++为主；
优点：规则检查自动化，规则多，速度快，可以定制规则。
6. C++Test：
支持 C++；
优点：C++Test 主要是对指针的保护、越界，数组的越界，变量的越界
等很有用，对于数学运算等函数，可以明确知道返回值的，可以设置预
期的返回值，来检查算法是否正确。
C++Test 测试用例可以控制 7 种类型的变量条件（取决于被测函数用了
多少）：
. 参数（Arguments）: 函数的入口参数。
. 参数出口条件（Arguments Post）: 函数执行完成时入口参数的状态。
. 返回值（Return）: 函数的返回值。
. 对象前置条件（Pre Conditions> This）: 测试开始前对象的条件。
. 对象后置条件（Post Conditions> This）: 测试执行后对象的条件。
. 前置条件（Pre Conditions> Externals）: 测试开始前全局变量的条件。
. 后置条件（Post Conditions> Externals）: 测试执行后全局变量的条件。
缺点：速度慢，耗系统资源，测试执行效率低。
关于 java 代码的质量相关，和静态工具使用，请先参照：
《Java 代码质量专题》；
《追求代码质量 监视圈复杂度》；
《追求代码质量 软件架构的代码质量》；
《追求代码质量 用代码度量进行重构》；
《初用 FindBugs - 耐心愉悦 - CSDNBlog》；
《FindBugs，第 1 部分 提高代码质量》。
这里面 FindBugs 是 java 静态分析工具。
桌面检查、代码走查、代码审查同时属于代码检查的方式。代码检查是发现
错误缺陷最有效的手段之一，通常能发现 30%-70%的逻辑设计和编码缺陷。可
以发现的问题：声明或引用错误、函数/方法参数错误、语句不可达错误、数组
越界错误、控制流错误、界面错误和输入/输出流错误等。
以上的测试策略，可能会因为项目不同导致取舍不同，组织形式和参加人员
也可能不同，但白盒测试不会超出这些范畴。
