简介

黑盒测试也称功能测试，它是通过测试来检测每个功能是否都能正常使用。从理论上讲，黑盒测试只有采用穷举输入测试，把所有可能的输入都作为测试情况考虑，才能查出程序中所有的错误。实际上测试情况有无穷多个，人们不仅要测试所有合法的输入，而且还要对那些不合法但可能的输入进行测试。这样看来，完全测试是不可能的。

所以我们要进行有针对性的测试，通过制定测试案例指导测试的实施，保证软件测试有组织、按步骤，以及有计划地进行。

黑盒测试行为必须能够加以量化，才能真正保证软件质量，而测试用例就是将测试行为具体量化的方法之一。

等价类

等价类划分就是把被测对象的输入域划分为若干个集合，对于某个集合中的某个元素和该集合中的任一元素的表征一致，然后从每个划分的集合中取出少数的数据作为测试用例。

有效等价类：是指对于程序的规格说明来说是合理的，有意义的输入数据构成的集合.利用有效等价类可检验程序是否实现了规格说明中所规定的功能和性能。无效等价类：与有效等价类的定义恰巧相反。

利用等价类划分法设计测试案例的时候，需要同时考虑到有效等价类和无效等价类这两种数据集合。

确定等价类的原则：

识别输入域分类：

在输入条件规定了输入范围或者个数的情况下，可以确立一个有效等价类和两个无效等价类。如果输入条件规定了某个输入域的集合，或者在必须怎么样的情况下，可以确定一个有效等价类和一个无效等价类。如果输入条件规定了某个输入必须为真或者为假的时候，可以确定一个有效等价类和一个无效等价类。如果需求规定了必须遵循某种规则时，可以确定一个有效等价类和若干个无效等价类。

案例

注册某个网站，要求用户名的长度为 6~12 的数字与字母组合而成的字符，密码长度为8~16位的数字、字母的组合。请写出测试案例。

识别输入域分类：

用户名长度为：6~12用户名只能由字母或数字组成

用户名测试例子

输入

输入域条件

有效等价类

无效等价类

用户名

长度 6～12

[ 6~12 ]

len > 12

用户名

长度 6～12

[ 6~12 ]

0 <= len < 6

用户名

由字母或数字组成

字母

特殊字符 #@$^ 等

用户名

由字母或数字组成

数字

空格

用户名

由字母或数字组成

字母 + 数字

下划线

边界值

边界值分析是指恰好处于等价类边界、或超过边界、或在边界以下的状态。边界值分析法不仅重视输入条件边界，而且也必须考虑输出域边界。它是对等价类划分方法的补充。

根据经验大多数的错误都是来自于对边界值的处理不严谨，所以把边界值作为重点测试数据边界值测试法是对等价类的补充

用边界值测试法补充测试用例

输入

输入域条件

分类

代表值

用户名

长度6～12

无效边界值=5

abcde

用户名

有效边界值=6

abcdef

用户名

有效边界值=7

abcdefg

用户名

有效边界值=11

abcdefghijk

用户名

有效边界值=12

abcdefghijkl

用户名

无效边界值=13

abcdefghijklm

错误推测法

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

用错误推测法补充测试用例，比如通常情况下，输入空格或已注册的用户名都不能进行用户注册：

输入

输入域条件

分类

代表值

用户名

类型

无效 空格

用户名

无效 已注册的用户名

abcde

因果图与判定表

前面介绍的等价类划分方法和边界值分析方法，都是着重考虑输入条件，但未考虑输入条件之间的联系，相互组合等。

考虑输入条件之间的相互组合，可能会产生一些新的情况。但要检查输入条件的组合不是一件容易的事情，即使把所有输入条件划分成等价类，他们之间的组合情况也相当多。因此必须考虑采用一种适合于描述对于多种条件的组合，相应产生多个动作的形式来考虑设计测试用例，这就需要利用因果图（逻辑模型）。

因果图

因果图是有向图，可以将一组原因映射到一组结果。可以将原因视为程序的输入，而可以将结果视为输出。通常，该图在左侧显示代表原因的节点，在右侧显示代表影响的节点。它们之间可能存在中间节点，这些中间节点使用诸如 AND 和 OR 的逻辑运算符组合输入。

画因果图只是一种辅助工具，通过分析最终得到判定表，再通过判定表编写测试用例。但是有时画因果图比较麻烦，影响测试效率，所以在应用熟练之后，可以省略画因果图直接填判定表，进而编写测试用例。

判定表

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

判定表是一种表达因果关系的逻辑表达方式，使用表格分类条件、中间结果、最终结果之间的关系。

判定表通常由条件桩、条件项、动作桩、动作项组成。

条件桩：被测对象的所有输入条件项：被测对象的输入取值动作桩：被测对象可能采取的操作/表现动作项：在各个条件项的组合下，被测对象所采取的动作/表现

案例

条件项的个数是由条件桩的个数决定的。假设条件桩的个数为 n，那么条件项的个数为 $2^n$。

本案例中，条件桩个数为3，那么后面的条件项的个数为 $2^3$，得出的个数为 8。

三个条件桩的真假需要平均分布，让每一种状态都可以被覆盖到。

覆盖完全之后，对于一些重复的状态可以进行合并。比如本例中网络的情况，没有网络是绝对不会注册成功的，所以留下一种组合就可以，标黄色的就可以省略。

合并之后的判定表每一列都用一条测试用例去覆盖。

决策树

判定表也可以用决策树表示，决策树可以比因果图和判定表更好的表示条件和结果之间的关系。在实际操作中，可以用流程图表示决策树。

案例

继续以上文中的注册场景为例，使用流程图可以表示为：

在图中，可以清晰的看出不同条件下的不同结果，从而判断测试用例是否有覆盖不全面的地方，如果有遗漏的场景，可以对测试用例进行一个补充。

因果图、判定表、决策树的关系这三者本质一样用于表达流程关系，只是表现形式不同他们的含义其实就是编程逻辑 if else switch测试过程中可以用流程图去表达探索式测试

探索式测试是一种软件测试风格，简而言之就是同步学习，测试设计和测试执行。

塞姆·坎纳（Cem Kaner）于1984年创造了该术语，将探索式测试定义为“一种软件测试风格，强调个人测试者的个人自由和责任，以通过对待与测试相关的学习来不断优化其工作质量

探索式测试是一种基于上下文质量反馈的测试风格，是基于上下文的反馈，适时调整测试执行。通常被认为是黑盒测试技术。在白盒测试中也可以应用类似的思想去实施（基于实时反馈的精准化测试）

探索式测试成本低，可以不用提前设计大量测试用例，而且可以激发测试工程师的创造性，更快的发现问题。适用于文档不齐全的场景。

但是探索式测试也有明显的缺点，比如对测试的覆盖度无法进行有效保障，测试管理上有局限性、较难协调和控制，对 Bug 的重复利用和重现上作用有限，对测试人员的测试技能和业务知识深度依赖较大。

在实践中可以把探索式测试与脚本式用例结合。脚本式用例就是提前编辑好一套测试流程，根据已经定好的测试流程进行测试。在脚本式用例的每一个技术的细节部分可以采用探索式测试来完成更细节维度的测试，来弥补脚本式用例细节上的不足。

搜索微信公众号：TestingStudio霍格沃兹的干货都很硬核