白盒测试

白盒测试

白盒测试概述

白盒测试又称透明盒测试，逻辑驱动测试

是测试被测单元内部如何工作的一种测试方法

允许测试人员根据程序内部逻辑结构及有关信息来设计和选择测试用例，对程序的逻辑结构进行测试

可覆盖全部代码、分支、条件和路径

目的：

保证程序中所有关键路径的测试，防止由于没有执行的路径在实际投入运行后执行到发生意外的情况

衡量测试完整性

程序内部所有的逻辑值真、假两个分支的覆盖

检查内存泄露

异常处理的分枝语句的执行

解决实验条件下很难搭建真实环境的问题

检查代码符合一定的编码规范，减少由于编码不规范而引入错误白盒测试和黑盒测试比较

联系：白盒测试和黑盒测试都是软件测试的一个方面；两者有时结合起来同时进行测试，称为“灰盒测试”。

区别：白盒，需要源代码；无法检测程序外部特性，无法测试遗漏需求；关心程序内部结构、逻辑以及代码的可维护性；编码、集成测试阶段进行。

黑盒，不需要源代码，需要可执行文件；从用户角度出发进行测试；关心程序的外在功能和非功能表现；确认测试、系统测试阶段进行。

白盒测试的策略

桌前检查

开发人员的自我检查

在指定功能实现后，单元测试前，对代码进行初步检查

重点是代码对编码规范的符合性

单元测试（UNTI TESTING）

单元：函数、过程、类

在桌前检查后进行，大部分由开发人员完成

主要测试功能，并覆盖程序中的语句和分析等达到逻辑覆盖准则。

代码评审（代码审查code review）：源代码的同行评审编码初期或编码过程中有同行参与的一个代码评审活动

重点是代码风格的一致性和对编码规范的遵守程度

可以帮助发现问题，拓展开发人员思路

依据《代码检查单》进行

同行评审（Peer Review）

来源CMM

检查工作产品是否满足了以往工作产品中建立的规范

识别工作产品相对于标准的偏差，包括可能影响软件可维护性的问题

向创建者提出改进意见

促进参与者之间技术交流和学习

代码走查(Walk Through)

由专门的代码走查小组或测试组进行

需要开发人员提交有关的资料文档和源代码，并进行必要的讲解

静态分析(static analyse)

测试小组进行

辅助工具支持

对源代码进行质量评估

生成静态分析报告、代码质量报告

正式审查

坚持标准和规范的原因：可靠性、可读性、可维护性、可

移植性

代码审查单

输入/输出错误数据声明错误、计算错误、数据引用错误、函数参数错误、比较错误、控制流程错误、其他检查

白盒测试对测试人员的要求

了解软件语言

了解软件开发技术

有开发经验最好

掌握白盒测试工具

掌握白盒测试用力设计方法

掌握开发人员编程中容易出现的问题，不断积累经验

代码质量对软件质量的贡献

代码是软件产品中的重要部分

代码质量反映软件质量

其他非代码因素也起着关键作用

文档（设计、帮助、用户手册）

制约程序员编写高质量代码的因素

对需求和设计的理解不透澈

对软件业务流程不熟悉

没有开发经验

对开发工具或开发语言不熟悉

受情绪因素的影响等因素

管理机制不健全

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

静态测试是指测试非运行部分——检查和审查，白盒测试是指访问代码，能够查看和审查

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

进行静态白盒测试的目的：尽早发现软件缺陷，以找出动态黑盒测试难以发现或隔离的软件缺陷，另一个好处是给黑盒测试人员提供

思路。

正式审查（formal review）就是进行静态白盒测试的过程4个基本要素：确定问题、遵守规则、准备、编写报告

编码的规范和标准

可靠性，可读性/可维护性，移植性

代码检查单

用于把代码与标准或规范进行对照补充，并确保代码符合项目的设计要求。

代码检查比动态测试更有效率，能快速找到缺陷，发现30%~70%的逻辑设计错误和编码缺陷

动态白盒测试

由于是动态的，就一定是测试运行中的程序，由于是白盒就一定要检查代码并观察运行状况。生成测试数据、分析测试结果的工作量大，开展测试费时费力费人。

逻辑覆盖方法：以程序内部逻辑结构为基础，有以下6种：

1.语句覆盖

基本思想：设计若干测试用例，运行被测程序，使程序中每个

判定表达式

缺点：由于这种测试方法仅仅针对程序逻辑中显示存在的与句，但对隐藏的条件是无法测试的，是最弱的逻辑覆盖。

2.判定覆盖

基本思想：设计所干测试用例，运行被测程序，使得程序中

和取假分支至少执行一次。

句覆盖一样的简单性，无须细分每个判定就可以得到测试用例缺点：大部分的判定语句是由多个逻辑条件组合而成，若仅仅判断其整个最终结果而忽略每个条件的取值情况必然会遗漏部分

测试路径，也是比较弱的逻辑覆盖。

3.条件覆盖

在在实际程序代码中，一个判定中通常都包含若干条件，条件覆盖的目的是设计若干测试用例，在执行被测程序后，要使每个判定中每个条件的可能值至少满足一次。

所有条件的真假都要覆盖到，不考虑组合

优点：增加了对条件判定情况的测试，增加了测试路径

缺点：条件覆盖不一定包含判定覆盖，条件覆盖只能保证每个条件至少有一次为真，而不考虑所有的判定结果

4.判定——条件覆盖

实际上是将判定覆盖和条件覆盖结合起来的一种方法，使得判定中每个条件的所有可能取值至少满足一次，同是每个判定的可能结果也至少出现一次。

基本思想：设计足够的测试用例，使得判定条件中的所有条件的所有情况至少执行一次取值，同时所有判定的所有情况的取值至少执行一次。

优点：能同时满足判定、条件两种覆盖标注

缺点：从表面上判定-条件覆盖测试了各个判定中的所有条件的取值。实际上，编译器在检查含有多个条件的逻辑表达式时，某些情况下的某些条件将会被其他条件所掩盖，因此判定——条件覆盖也不一定能够完全查出逻辑表达式中的错误。未考虑条件组合。

5.条件组合覆盖

基本思想：设计足够的测试用例，使得所有可能的条件取值组

—条件覆盖

缺点：线性的增加了测试用例数量

6.路径覆盖

基本思想：设计所有的测试用例，来覆盖程序中的所有可能的