白盒测试概念

#1 白盒测试概述

  • 白盒测试又称透明盒测试、逻辑驱动测试;
  • 是测试被测单元内部如何工作的一种测试方法;
  • 根据程序内部逻辑结构及有关信息来设计和选择测试用例,对程序的逻辑结构进行测试;
  • 可覆盖全部代码、分支、条件和路径等;

#2 白盒测试的目的

  • 保证程序中所有关键路径的测试,防止由于没有执行的路径在实际投入运行后执行到发生意外的情况;
  • 衡量测试完整性;
  • 程序内部所有的逻辑值真、假两个分支的覆盖;
  • 检查内存泄漏;
  • 异常处理的分支语句的执行;
  • 解决实验条件下很难搭建真实测试环境的问题;
  • 检查代码符合一定的编码规范,减少由于编码不规范而引入错误。

#3 白盒测试用例设计方法

##3.1逻辑覆盖方法

3.1.1 语句覆盖

基本思想是:设计若干测试用例,运行被测程序,使程序中每个可执行语句至少执行一次。
例:
这里写图片描述 这里写图片描述
在上述例子中:a=2,b=1,c=6;即达到了语句覆盖。
**优点:**可以很直观地从源代码得到测试用例,无须细分每条判定表达式。
**缺点:**由于这种测试方法仅仅针对程序逻辑中显式存在的语句,但对于隐藏的条件是无法测试的。例如在第一个判定((a>0)and(b>0))中把“and”错误的写成了“or”,这时仍可使用该测试用例,语句覆盖是最弱的逻辑覆盖。

###3.1.2 判定覆盖

基本思想是:设计若干测试用例,运行被测程序,使得程序中每个判断的取真分支和取假分支至少经历一次,即判断真假值均曾被满足。
这里写图片描述
那么,根据判定覆盖的思想,设计测试用例,如下所示:
a=2,b=1 ,c=6可覆盖判断M的Y分支和判断Q的Y分支;
a= -2,b= -1 ,c= -3可覆盖判断M的N分支和判断Q的N分支 。
这两组测试用例可覆盖所有判定的真假分支。
测试用例并不是唯一的,如下所示的两组测试用例也可覆盖所有判定的真假分支:
a=1,b=1 ,c= -3 可覆盖判断M的Y分支和判断Q的N分支 ;
a=1,b= -2 ,c=3可覆盖判断M的N分支和判断Q的Y分支 。
优点:判定覆盖具有比语句覆盖强的测试能力。同样判定覆盖也具有和语句覆盖一样的简单性,无须细分每个判定就可以得到测试用例。
缺点:往往大部分的判定语句是由多个逻辑条件组合而成,若仅仅判断其整个最终结果,而忽略每个条件的取值情况,必然会遗漏部分测试路径。判定覆盖仍是弱的逻辑覆盖。

3.1.3 条件覆盖

在实际程序代码中,一个判定中通常都包含若干条件。 条件覆盖的目的是设计若干测试用例,在执行被测程序后,要使每个判定中每个条件的可能值至少满足一次。
这里写图片描述
判断M表达式:
设条件 a>0 取真 记为 T1
假 F1
条件 b>0 取真 记为 T2
假 F2
判断Q表达式:
设条件 a>1 取真 记为 T3
假 F3
条件 c>1 取真 记为 T4
假 F4
测试用例:
这里写图片描述
注意:我们用条件覆盖设计的思想就是让测试用例能覆盖T1、T2、T3、T4、F1、F2、F3、F4。
优点:增加了对条件判定情况的测试,增加了测试路径。
缺点:条件覆盖不一定包含判定覆盖。例如,我们刚才设计的用例就没有覆盖判断M的Y分支和判断Q的N分支。条件覆盖只能保证每个条件可能取值至少执行一次,而不考虑所有的判定结果。

###3.1.4判定-条件覆盖
判定/条件覆盖实际上是将判定覆盖和条件覆盖结合起来的一种方法。基本思想是:设计足够的测试用例,使得判断条件中的所有条件可能至少执行一次取值。同时,所有判断的可能结果至少执行一次。
按照判定-条件覆盖的要求,我们设计的测试用例要满足如下条件:

  • 所有条件可能至少执行一次取值;
  • 所有判断的可能结果至少执行一次;

这里写图片描述
这里写图片描述

判定-条件覆盖总结:
**优点 ** :能同时满足判定、条件两种覆盖标准。
缺点:判定/条件覆盖准则的缺点是未考虑条件的组合情况。

###3.1.5 条件组合覆盖
基本思想是:设计足够的测试用例,使得所有可能的条件取值组合至少执行一次。
这里写图片描述 这里写图片描述 这里写图片描述
条件组合覆盖总结:
优点:条件组合覆盖准则满足判定覆盖、条件覆盖和判定/条件覆盖准则。
缺点:线性地增加了测试用例的数量。

3.1.6 路径覆盖

基本思想是:设计所有的测试用例,来覆盖程序中的所有可能的执行路径 。
这里写图片描述 这里写图片描述
路径覆盖总结:
优点:这种测试方法可以对程序进行彻底的路径测试,比前面五种的覆盖面都广。
缺点:需要设计大量、复杂的测试用例,使得工作量呈指数级增长,而且不见得把所有的条件组合都覆盖。

##3.2 基本路径测试

基本路径测试法是在程序控制流图的基础上,通过分析控制构造的环路复杂性,导出基本可执行路径集合,从而设计测试用例的方法。设计出的测试用例要保证在测试中程序的每个可执行语句至少执行一次。

###3.2.1 基本路径测试法的基本步骤

  1. 程序的控制流图:描述程序控制流的一种图示方法。
  2. 程序圈复杂度:McCabe,复杂性度量。从程序的环路复杂性可导出程序基本路径集合中的独立路径条数,这是确定程序中每个可执行语句至少执行一次所必须的测试用例数目的上界。
  3. 导出测试用例:根据圈复杂度和程序结构设计用例数据输入和预期结果。
  4. 准备测试用例:确保基本路径集中的每一条路径的执行。

###3.2.2 基本路径测试法的工具方法

图形矩阵是在基本路径测试中起辅助作用的软件工具,利用它可以实现自动地确定一个基本路径集。

#4 白盒测试总结

以上就是基本的白盒测试基础概念知识,总结整理,方便日后复习。

  • 2
    点赞
  • 33
    收藏
    觉得还不错? 一键收藏
  • 1
    评论
白盒测试指南 (说明:此白盒测试指南主要给白盒测试人员提供一些基本的白盒测试方法和技术,由于涉及的问题广泛,测试内容中的细节不一定准确和完整,还有待于各位的共同参与和不断完善,欢迎多交流!) 1. 目的 本方案主要实施NC产品程序代码的白盒测试。使界面符合设计规范,适用于用户;保证程序创建的类与接口的完整与正确,以及程序模块单独正常运行。保证局部模块功能完备性,运行正确性与稳定性。 2. 测试项 所要测试的类。如: nc.ui.bd.* nc.bs.bd.* nc.vo.bd.* 3. 测试依据 1. NC产品需求报告; 需求规格说明书、用例描述清单 2. 设计文档;(OOA、OOD、CRC卡) 如:AOM(Analysis Object Model)表示类间的静态关系,是多个相关的用例共用的。 ASD(Analysis Sequence Diagram)是按业务工作的顺序表示每一工作步骤执行时类间的动态关系。一个用例对应一个ASD。 CRC (Collaborators & Responsibilities Card)卡是一个类的完整表述 3. 界面规范 4. 编码规范 5. 开发命名标准 4. 通过的准则 1.界面测试通过的标准:界面的样式、大小、颜色、整体布局的设置;各种标签控件的使用及主题描述以及事件源控件的使用、快捷键使用都应符合《NC系统应用框架需求报告》和《设计文档的相关规范》。 2.程序代码通过的标准:创建的类、接口、方法、属性应与《设计文档》保持一致;程序的各种命名、注释、代码行的格式等应符合《程序开发命名标准》和《编码规范》;程序模块能独立稳定运行。 5. 测试环境配置 1. 测试工具: 2. 软件环境: Client端: 操作系统:中文WINNT/2000 开发环境:VA3.5 专业版 待测试的源码包 Server端: 操作系统:WIN NT4.0 开发环境:VA3.5 专业版 通讯环境: Servlet 3. DB Server端:DBMS:SQL SERVER

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值