黑盒测试

黑盒测试又称为功能测试或数据驱动测试。是把测试对象看作一个黑盒子。利用黑盒测试法进行动态测试时,需要测试软件产品的功能,不需要测试软件产品的内部结构和处理过程。
采用黑盒技术设计测试用例的方法有:等价类划分、边界值分析、错误推测、因果图和综合策略

黑盒测试注重于测试软件的功能性需求,也即黑盒测试使软件工程师派生出执行程序所有功能需求的输入条件。黑盒测试并不是白盒测试的替代品,而是用于辅助白盒测试发现其他类型的错误。

黑盒测试发现以下类型的错误:

  • 功能错误或遗漏
  • 界面错误
  • 数据结构或外部数据库访问错误
  • 性能错误
  • 初始化和终止错误

黑盒测试的测试用例设计方法:

  • 等价类划分方法

是把所有可能的输入数据,即程序的输入域划分为若干部分,然后从每个子集中选取少数具有代表性的数据,作为测试用例。该方法是一种重要的,常用的黑盒测试用例设计方法。

  • 边界值分析方法

是对等价类划分方法的补充。

边界值分析方法的考虑:长期的测试工作经验告诉我们,大量的错误是发生在输入或输出范围的边界上,而不是发生在输入输出范围的内部。因此针对各种边界情况设计测试用例,可以查出更多的错误

  • 错误推测方法

基于经验和直觉推测程序中所有可能存在的各种错误,从而有针对性的设计测试用例的方法

错误推测方法的基本思想:列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例。例如,在单元测试时曾列出的许多在模块中常见的错误,以前产品测试中曾经发现的错误等,这些都是经验的总结。

  • 因果图方法

等价类划分法和边界值分析法都是着重考虑输入条件,但未考虑输入条件之前的联系,相互组合等。考虑输入条件之间的相互组合,可能会产生一些新的情况,但要检查输入条件的组合不是一件容易的事情,即使把所有的输入条件划分为等价类,他们之间的组合情况也相当多。因此必须考虑采用一种适合于描述对于多种条件的组合,相应产生多个动作的形式来考虑设计测试用例。

因果图最终生成的是判定表,它适合于检查程序输入条件的各种组合情况

  • 判定表驱动分析方法

条件桩(ConDItion STub):列出了问题得所有条件.通常认为列出得条件的次序无关紧要
       动作桩(Action Stub):列出了问题规定可能采取的操作.这些操作的排列顺序没有约束
       条件项(Condition Entry):列出针对它左列条件的取值.在所有可能情况下的真假值
       动作项(Action Entry):列出在条件项的各种取值情况下应该采取的动作

规则:任何一个条件组合的特定取值及其相应要执行的操作.在判定表中贯穿条件项和动作项的一列就是一条规则.显然,判定表中列出多少组条件取值,也就有多少条规则,既条件项和动作项有多少列

  • 正交实验设计方法
  • 功能图分析方法

 

黑盒测试的缺点
  1. 结果取决于测试例的设计,测试例的设计部分来势来源于经验
  2. 没有状态转换的概念,目前一些成功的例子基本上都是针对PDU来做的,还做不到针对被测试程序的状态转换来作
  3. 就没有状态概念的测试来说,寻找和确定造成程序crash的测试例是个麻烦事情,必须把周围可能的测试例单独确认一遍。而就有状态的测试来说,就更麻烦了,尤其不是一个单独的testcase造成的问题。这些在堆的问题中表现的更为突出

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值