#软件测试基本概念-黑盒测试

##1 测试用例设计概念

###1.1 测试用例的定义与特征

####1.1.1 定义

  • 测试用例是为特定的目的而设计的一组测试输入、执行条件和预期的结果。
  • 测试用例是执行的最小实体。

####1.1.2 特征

  • 最有可能抓住错误的;
  • 不是重复的、多余的;
  • 一组相似测试用例中最有效的;
  • 既不是太简单,也不是太复杂。

###1.2 设计测试用例的基本准则

####1.2.1 测试用例的代表性 能够代表并覆盖各种合理的和不合理的、合法的和非法的、边界的和越界的以及极限的输入数据、操作和环境设置等。

####1.2.2 测试结果的可判定性 即测试执行结果的正确性是可判定的,每一个测试用例都应有相应的期望结果。

####测试结果的可再现性 即对同样的测试用例,系统的执行结果应当是相同的。

##2 黑盒测试用例设计的几种方法

###2.1 等价类划分法

####2.1.1 弱一般等价类测试 特点: 不考虑无效数据,测试用例使用每个等价类中的一个值 弱一般等价类测试

####2.1.2 强一般等价类测试 特点:每一个有效等价类要选择至少一个测试用例 强一般等价类测试

####2.1.3 弱健壮等价类测试 对于有效输入: 使用每个有效类的一个值 对于无效输入: 测试用例只使用一个无效值,其余值都是有效的 弱健壮等价类测试

####2.1.3 强健壮等价类测试 每个有效等价类和无效等价类都至少要选择一个测试用例 弱健壮等价类测试

###2.2 边界值分析法 边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法。通常边界值分析法是作为对等价类划分法的补充,这种情况下,其测试用例来自等价类的边界。
无数的测试实践表明,大量的故障往往发生在输入定义域或输出值域的边界上,而不是在其内部。因此,针对各种边界情况设计测试用例,通常会取得很好的测试效果。

####2.2.1 标准性(一般性)测试 经过测试,符合设计要求,确认系统功能和其他特性均不再做任何改变。 标准性测

####2.2.2 健壮性测试 边界值分析测试的一种扩展,除了取5个边界值外,还需要考虑采用一个略超过最大值(max+)及略小于最小值(min-)的取值,检查超过极限值时系统的情况 健壮性测试

####2.2.3 最坏情况测试 边界值分析采用可靠性理论中的单缺陷假设,如果不考虑这种假设,那么,应该关心当多个变量取极值时会出现什么情况。首先对每个变量进行包含最小值min,略高于最小值min+,正常值nom,略低于最大值max-和最大值max五个元素集合的测试,然后对这些集合进行笛卡儿积计算,以生成测试用例。 最坏情况测试

####2.2.4 健壮最坏情况测试 考虑略超过极限的测试。首先对每个变量进行包含略小于最小值min-,最小值min,略高于最小值min+,正常值nom,略低于最大值max-,最大值max,和略大于最大值max+,七个元素集合的测试,然后对这些集合进行笛卡儿积计算,以生成测试用例。 健壮最坏情况测试

###2.3 决策表法 决策表的概念:决策表是分析和表达多逻辑条件下执行不同操作情况的工具。
在一些数据处理问题当中,某些操作的实施依赖于多个逻辑条件的组合,即:针对不同逻辑条件的组合值,分别执行不同的操作。决策表很适合于处理这类问题。

####2.3.1 优点 能够将复杂的问题按照各种可能的情况全部列举出来,简明并避免遗漏。因此,利用决策表能够设计出完整的测试用例集合。

####2.3.2 决策表通常由以下4部分组成

  • 条件桩—列出问题的所有条件
  • 条件项—针对条件桩给出的条件列出所有可能的取值
  • 动作桩—列出问题规定的可能采取的操作
  • 动作项—指出在条件项的各组取值情况下应采取的动作
    规则:将任何一个条件组合的特定取值及相应要执行的动作称为一条规则。在决策表中贯穿条件项和动作项的一列就是一条规则。

####2.3.3 生成决策表的步骤

  1. 确定规则的个数。有n个条件的决策表有2n个规则(每个条件取真、假值)。
  2. 列出所有的条件桩和动作桩。
  3. 填入条件项。
  4. 填入动作项,得到初始决策表。
  5. 简化决策表,合并相似规则。

###2.4 因果图法 等价类划分法和边界值分析方法都是着重考虑输入条件,但没有考虑输入条件的各种组合、输入条件之间的相互制约关系。这样虽然各种输入条件可能出错的情况已经测试到了,但多个输入条件组合起来可能出错的情况却被忽视了。

####2.4.1 定义 是一种利用图解法分析输入的各种组合情况,从而设计测试用例的方法,它适合于检查程序输入条件的各种组合情况。

####2.4.2 设计用例的方法 首先从程序规格说明书的描述中,找出因(输入条件)和果(输出结果或者程序状态的改变), 然后通过因果图转换为判定表,最后为判定表中的每一列设计一个测试用例.

####2.4.3 具体细节(略) 有兴趣联系我。

###2.5 场景法

####基于状态的测试

  • 基于状态的测试一般是用状态图来描述事件序列,或称为用例场景,并由此产生测试用例。
  • 基于状态的测试评价标准是状态、转移覆盖及对不正常、不相关事件的考虑,并以此决定测试用例产生的数量和测试的结束条件
  • 基于状态的测试广泛地用于实时系统和嵌入式系统的测试
  • 由状态图产生测试用例,实际上是遍历一个有向图,从起始点到终点的每一条路径代表一个测试场景,从每个测试场景可以产生一个或多个测试用例。 细节(略)

###2.6 小结

  1. 测试用例的设计方法不是孤立的,具体到每个测试项目里都会综合运用多种方法
  2. 在任何情况下都必须使用边界值分析方法。经验表明用这种方法设计出测试用例发现程序错误的能力最强
  3. 必要时用等价类划分法,包括输入条件和输出条件,将无限测试变成有限测试
  4. 对照程序逻辑,检查、补充测试用例,以达到逻辑覆盖程度的要求。
  5. 如果程序的功能说明中含有输入条件的组合情况,则一开始可选用因果图法。
  6. 对于业务流清晰的系统,可以利用场景法贯穿整个测试案例过程。
转载请注明出处 http://www.xiangguo.li/software_test/2014/08/05/software_test4

Categories: Tags:

相国 walter

一个热爱coding的青年

blog comments powered by Disqus