常用的四种黑盒测试用例设计方法
1.
等价划分。所谓等价类划分是指一套被选择的值，这些值分别代表了许多众多
的可能输入值，程序对其处理的方式都是一样的。等价类划分的方法作为继边
界值分析方法之后补充的测试用例设计试用的一种方法。划分等价类、确定测
试用例。
等价类划分是一种典型的黑盒测试方法，使用这一方法时，完全不考虑程序的
内部结构，只依据程序的规格说明来设计测试用例。等价类划分方法把所有可
能的输入数据，即程序的输入域划分成若干部分，然后从每一部分中选取少数
有代表性的数据做为测试用例。
等价类的划分有两种不同的情况：有效等价类：是指对于程序的规格说明来说，
是合理的，有意义的输入数据构成的集合。无效等价类：是指对于程序的规格
说明来说，是不合理的，无意义的输入数据构成的集合。在设计测试用例时，
要同时考虑有效等价类和无效等价类的设计。
2.
边界值分析。在设计测试用例确定输入和输出参数时，大多数情况下都是用边
界值分析方法，采用边界值分析设计的测试用例发现程序错误能力最强。边界
值分析也是一种黑盒测试方法，是对等价类划分方法的补充。人们从长期的测
试工作经验得知，大量的错误是发生在输入或输出范围的边界上，而不是在输
入范围的内部。因此针对各种边界情况设计测试用例，可以查出更多的错误。
3.
错误推测法。人们也可以靠经验和直觉推测程序中可能存在的各种错误，从而
有针对性地编写检查这些错误的例子。这就是错误推测法。错误推测法的基本
想法是：列举出程序中所有可能有的错误和容易发生错误的特殊情况，根据它
们选择测试用例。
4.
因果图。如果程序的功能说明中含有输入条件的组合情况，则一开始就可以选
用因果图法。如果在测试时必须考虑输入条件的各种组合，可使用一种适合于
描述对于多种条件的组合，相应产生多个动作的形式来设计测试用例，这就需
要利用因果图。因果图方法最终生成的就是判定表。它适合于检查程序输入条
件的各种组合情况。
用黑盒技术设计测试用例的方法之一为
1. 等价类划分 如下图所示
2. 边界值：应选取正好等于、刚刚大于、刚刚小于边界值作为测试数据
3. 错误推测法：进行错误的操作，验证程序是否对出错的场 景和情况有应对能力。
4. 因果图法/判定表法：适合于检查程序输入条件的各种组合情况。
5. 场景法：场景描述的业务流程
基本流：主要是功能的正常操作流程
分支流：需要程序做非法判断处理
黑盒测试-用例设计(下)
用黑盒技术设计测试用例的方法之一为因果图法。
黑盒技术
黑盒测试用例设计方法通常包括：
黑盒技术
等价类测试用例设计方法、边界值测试用例设计方法、场景法测试用例设计方法、因果图测试用例设计方法、判定表测试用例设计方法、正交试验测试用例设计方法、状态迁移图测试用例设计方法、输入域测试用例设计方法、输出域测试用例设计方法、异常分析测试用例设计方法和错误猜测测试用例设计方法等方法。
等价类测试用例设计方法是一种典型的黑盒测试设计方法，使用该方法主要对测试子项进行测试规格分析，进而得到测试用例，不需要对系统内部处理进行深入了解，它也是目前测试设计过程中使用最普遍的一种方法。
采用等价类设计方法是将系统的输入域划分为若干部分，然后从每个部分选取少数代表性数据进行测试，这样可以避免穷举产生的大量用例。
上篇主要记录了等价类划分、边界值分析、错误推测法，下面接着来学习黑盒测试其他常见的：因果图&判定表、场景法等。
因果图法是一种适合于描述对于多种输入条件组合的测试方法，根据输入条件的组合、约束关系和输出条件的因果关系，分析输入条件的各种组合情况，从而设计测试用例的方法，它适合于检查程序输入条件涉及的各种组合情况。
因果图法一般和判定表结合使用，通过映射同时发生相互影响的多个输入来确定判定条件。因果图法最终生成的就是判定表，它适合于检查程序输入条件的各种组合情况。采用因果图法能帮助我们按照一定的步骤选择一组高效的测试用例。
因（原因）：输入条件
果（结果）：输出结果
因果图：就是通过画图的方式来表示输入条件（因）和输出结果（果）之间的关系。
1.关系
①恒等 – ：若ci是1，则ei也是1；否则ei为0。
②非 ~ ：若ci是1，则ei是0；否则ei是1。
③或 V ：若c1或c2或c3是1，则ei是1；否则ei为0。“或”可有任意个输入。
④与 ^ ：若c1和c2都是1，则ei为1；否则ei为0。“与”也可有任意个输入。
2.约束
输入状态相互之间还可能存在某些依赖关系，称为约束。例如，某些输入条件本身不可能同时出现。输出状态之间也往往存在约束。在因果图中，用特定的符号标明这些约束。
A.输入条件的约束有以下4类：
① E 互斥（异）：a和b不能同时成立。
② I 包含（或）：a、b和c中至少有一个成立。
③ O 唯一；a,b条件中有且仅有一个成立。
④R 约束（要求）：表示当a出现时b也必须出现
B.输出条件约束类型
输出条件的约束只有M约束（强制）：若结果a是1，则结果b强制为0。
原因：
1：第一列字符是A；
2：第一列字符是B；
3：第二列字符是一数字。
结果：
21：修改文件；
22：给出信息L；
23：给出信息M。
其对应的因果图如下：11为中间节点；考虑到原因1和原因2不可能同时为1，因此在因果图上施加E约束，如图所示:
判定表(Decision table)是另一种表达逻辑判断的工具。与结构化语言和判断树相比，判断表的优点是能把所有条件组合充分地表达出来。其缺点是判定表的建立过程较烦杂，且表达方式不如前两种简便。判定表在用于知识表达中，有许多其他方式所达不到的作用。
表中8种情况的左面两列情况中，原因①和原因②同时为1，这是不可能出现的，故应排除这两种情况。把判定表的每一列拿出来作为依据，设计测试用例。我们把表的最下一栏给出了6种情况的测试用例，这是我们所需要的数据。
优点
缺点
判定表优点：
能够将复杂的问题按照各种可能的情况全部列举出来，简明并避免遗漏。因此，利用判定表能够设计出完整的测试用例集合。在一些数据处理问题当中，某些操作的实施依赖于多个逻辑条件的组合，即：针对不同逻辑条件的组合值，分别执行不同的操作。判定表很适合于处理这类问题。
通过运用场景来对系统的功能点或业务流程的描述，从而提高测试效果的一种方法。用例场景来测试需求是指模拟特定场景边界发生的事情，通过事件来触发某个动作的发生，观察事件的最终结果，从而用来发现需求中存在的问题。
我们通常以正常的用例场景分析开始，然后再着手其他的场景分析。场景法一般包含基本流和备用流，从一个流程开始，通过描述判定表的优点：
软件几乎都是用事件触发来控制流程的，事件触发时的情景便形成了场景，而同一事件不同的触发顺序和处理结果就形成事件流。 这种在软件设计方面的思想也可以引入到软件测试中，可以比较生动地描绘出事件触发时的情景，有利于测试设计者设计测试用例，同时使测试用例更容易理解和执行。
场景法一般包括基本流和备选流。
业务层面（业务理解更重要）：
测试人员要熟悉所测软件的业务逻辑，成为该行业 \”业务专家\”。
技术层面：
基本流： 经过用例的每条路径都用基本流和备选流来表示，绿色主线表示基本流，是经过用例的最简单的路径，即无任何差错，程序从开始直接执行到结束的流程。通常，一个业务仅存在一个基本流，且基本流仅有一个起点和一个终点。
备选流： 表示通过业务流程时输入错误（或者操作错误）导致流程存在反复，但是经过纠正后仍能达到目标的流程。备选流为除了基本流之外的各支流，包含多种不同情况。
场景法的核心就是“场景”二字，你所需要的就是要找出场景，场景找出来了，测试用例也就水到渠成。当你找到基本流和备选流之后，需要通过构造场景矩阵将场景表示出来。矩阵一旦生成，用例也就一目了然。说起来比较简单，但在使用的过程中会遇到不少的问题。在很多流程图中，有不少备选流其实是隐藏的。
希望读者能深入理解两个流的概念，为什么会有这两个流，两个流的特点是什么，为什么要构造矩阵，矩阵的纵向和横向代表什么，V, I又代表什么？。
以上表中，是把每个场景成立的条件进行了分析，基本上已经明确了测试用例的数量，现在只要把真实数据填充上，那么整个测试用例就完成了。
以上写到的测试用例只是购物的一部分测试用例。其他测试用例，感兴趣的可以再进行补充和扩展，想要达到比较好的覆盖。那么只能不断迭代进行优化用例设计。
以上主要记录学习了平时比较常用的一些方法，当然还有一些其他的测试方法。如：Pairwise 、 正交实验法(allpairspy) 、决策表等等，如果感兴趣的可以自行去了解学习。对以上有疑惑的可以 关注+留言+点赞 进行互动讨论。
以上就是关于主要的黑盒测试用例设计方法有哪些全部的内容，如果了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！
