上篇主要记录了等价类划分、边界值分析、错误推测法，下面接着来学习黑盒测试其他常见的：因果图&判定表、场景法等。
因果图&判定表
因果图法是一种适合于描述对于多种输入条件组合的测试方法，根据输入条件的组合、约束关系和输出条件的因果关系，分析输入条件的各种组合情况，从而设计测试用例的方法，它适合于检查程序输入条件涉及的各种组合情况。
因果图法一般和判定表结合使用，通过映射同时发生相互影响的多个输入来确定判定条件。因果图法最终生成的就是判定表，它适合于检查程序输入条件的各种组合情况。采用因果图法能帮助我们按照一定的步骤选择一组高效的测试用例。
因（原因）：输入条件
果（结果）：输出结果
因果图：就是通过画图的方式来表示输入条件（因）和输出结果（果）之间的关系。
1. 因果图转化判定表步骤：
- 找出所有的原因，原因即输入条件或输入条件的等价类
- 找出所有的结果，结果即输出条件
- 明确所有输出条件之间的制约关系以及组合关系。哪些条件不能组合到一起，哪些条件可以组合到一起
- 明确所有输出条件之间的制约关系以及组合关系。那些输出结果不能同时输出，那些输出结果可以同时输出
- 找出什么样的输入条件组合或产生那种输出结果
- 把因果转换成判定表/决策表
- 为判定表/决策表中的每一列表示的情况设计测试用例
2.因果图概念
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。
案例
某软件规格说明书包含这样的要求：第一列字符必须是A或B，第二列字符必须是一个数字，在此情况下进行文件的修改，但如果第一列字符不正确，则给出信息L；如果第二列字符不是数字，则给出信息M。
- 对说明进行分析，得到原因和结果：
原因：
1：第一列字符是A；
2：第一列字符是B；
3：第二列字符是一数字。
结果：
21：修改文件；
22：给出信息L；
23：给出信息M。
其对应的因果图如下：11为中间节点；考虑到原因1和原因2不可能同时为1，因此在因果图上施加E约束，如图所示:
根据因果图建立判定表
判定表(Decision table)是另一种表达逻辑判断的工具。与结构化语言和判断树相比，判断表的优点是能把所有条件组合充分地表达出来。其缺点是判定表的建立过程较烦杂，且表达方式不如前两种简便。判定表在用于知识表达中，有许多其他方式所达不到的作用。
表中8种情况的左面两列情况中，原因①和原因②同时为1，这是不可能出现的，故应排除这两种情况。把判定表的每一列拿出来作为依据，设计测试用例。我们把表的最下一栏给出了6种情况的测试用例，这是我们所需要的数据。
优缺点
优点
- 因果图法能够帮助我们按照一定步骤，高效的选择测试用例，设计多个输入条件组合用例
- 因果图分析还能为我们指出，软件规格说明描述中存在的问题
缺点
- 输入条件与输出结果的因果关系，有时难以从软件需求规格说明书得到。
- 即时得到了这些因果关系，也会因为因果关系复杂导致因果图非常庞大，测试用例数目及其庞大。
判定表优点：
能够将复杂的问题按照各种可能的情况全部列举出来，简明并避免遗漏。因此，利用判定表能够设计出完整的测试用例集合。在一些数据处理问题当中，某些操作的实施依赖于多个逻辑条件的组合，即：针对不同逻辑条件的组合值，分别执行不同的操作。判定表很适合于处理这类问题。
场景法
通过运用场景来对系统的功能点或业务流程的描述，从而提高测试效果的一种方法。用例场景来测试需求是指模拟特定场景边界发生的事情，通过事件来触发某个动作的发生，观察事件的最终结果，从而用来发现需求中存在的问题。
我们通常以正常的用例场景分析开始，然后再着手其他的场景分析。场景法一般包含基本流和备用流，从一个流程开始，通过描述判定表的优点：
-
能够将复杂的问题按照各种可能的情况全部列举出来，简明并避免遗漏。因此，利用判定表能够设计出完整的测试用例集合。在一些数据处理问题当中，
-
某些操作的实施依赖于多个逻辑条件的组合，即：针对不同逻辑条件的组合值，分别执行不同的操作。判定表很适合于处理这类问题。经过的路径来确定的过程，经过遍历所有的基本流和备用流来完成整个场景。场景主要包括4种主要的类型：正常的用例场景，备选的用例场景，异常的用例场景，假定推测的场景。
软件几乎都是用事件触发来控制流程的，事件触发时的情景便形成了场景，而同一事件不同的触发顺序和处理结果就形成事件流。这种在软件设计方面的思想也可以引入到软件测试中，可以比较生动地描绘出事件触发时的情景，有利于测试设计者设计测试用例，同时使测试用例更容易理解和执行。
场景法一般包括基本流和备选流。
业务层面（业务理解更重要）：
测试人员要熟悉所测软件的业务逻辑，成为该行业 "业务专家"。
技术层面：
- 基本流：也叫有效流或正确流，模拟用户正确的业务操作流程
- 备选流：也叫无效流或错误流，模拟用户错误的业务操作流程
基本流：经过用例的每条路径都用基本流和备选流来表示，绿色主线表示基本流，是经过用例的最简单的路径，即无任何差错，程序从开始直接执行到结束的流程。通常，一个业务仅存在一个基本流，且基本流仅有一个起点和一个终点。
备选流：表示通过业务流程时输入错误（或者操作错误）导致流程存在反复，但是经过纠正后仍能达到目标的流程。备选流为除了基本流之外的各支流，包含多种不同情况。
基本流和备选流的识别原则
- 基本流只有一个起点，一个终点。
- 基本流是主流，备选流是支流。
- 备选流可以始于基本流，也可以始于其它备选流。
- 备选流的终点，可以是一个流程的出口，也可以是回到基本流，还可以是汇入其它的备选流。
- 备选流汇合时，谁汇合到谁，取决于流量大小也即该流程出现的可能性大小，小汇入大。
- 如果在流程图中出现了两个不相上下的基本流，一般需要把它们分别当做一个业务看待。
场景法设计的步骤（How）
- 分析需求，确定业务流程（基本流、备选流）；
- 依据基本流、备选流，生成不同的场景；
- 针对生成的各场景，设计相应的测试用例。可以采用矩阵或者判定表来确定和管理测试用例。每个测试用例包含：ID、条件（或说明）、数据元素、预期结果。通过从确定执行用例场景所需的数据元素入手构建矩阵，矩阵中可用V VALID（有效的）才可执行基本流，而 I（无效）用于表明这种条件下将激活所需备选流。使用的 “N/A”（不适用）表明这个条件不适用于测试用例。一旦确定了所有的测试用例，则应对这些测试用例进行复审和验证以确保其准确且适度.
- 测试用例一经认可，就可以确定实际数据值（在测试用例实施矩阵中）并且设定数据。
场景法的核心就是“场景”二字，你所需要的就是要找出场景，场景找出来了，测试用例也就水到渠成。当你找到基本流和备选流之后，需要通过构造场景矩阵将场景表示出来。矩阵一旦生成，用例也就一目了然。说起来比较简单，但在使用的过程中会遇到不少的问题。在很多流程图中，有不少备选流其实是隐藏的。
希望读者能深入理解两个流的概念，为什么会有这两个流，两个流的特点是什么，为什么要构造矩阵，矩阵的纵向和横向代表什么，V, I又代表什么？。
使用场景法设计测试用例应该注意什么？
- 注意主题化，要明白这个场景用例是要测试什么功能，切忌将API中的测试点自己任意组合，想到哪里写到哪里。为了达到测试点的主题化，我们可以在写用例之前先构想出一个用户使用的场景故事，也就是保证这个场景在用户使用的过程中是会出现的。
- 注意上下文，场景用例本身就是模拟用户使用，测试基本功能（BVT）连接起来是否有bug，一定要具备用户使用时的逻辑性。
- 只测试简单的基本功能，而诸如密码的合法性，内存，带宽的越界这样的问题在场景中不需要出现，也就是场景中只出现主流程（密码错误属于副流程）
- 步骤要简洁明了，没有歧义，数字要说明单位。写出来的测试用例要做到让别人一下子就可以看懂，没有歧义。
- 尽量不要使得不同的场景覆盖同样的测试点。
案例
我们都在当当网订购过书籍，整个订购过程为：用户登录到网站后，进行书籍的选择，当选好自己心仪的书籍后进行订购，这时把所需图书放进购物车，等进行结帐的时候，用户需要登录自己注册的帐号，登录成功后，进行结帐并生成订单，整个购物过程结束。
- Step1.基本流和备选流
- Step2.根据基本流和备选流来确定场景：
- Step3.设计用例如下：
以上表中，是把每个场景成立的条件进行了分析，基本上已经明确了测试用例的数量，现在只要把真实数据填充上，那么整个测试用例就完成了。
- Step4.测试用例和测试数据如下：
以上写到的测试用例只是购物的一部分测试用例。其他测试用例，感兴趣的可以再进行补充和扩展，想要达到比较好的覆盖。那么只能不断迭代进行优化用例设计。
最后
以上主要记录学习了平时比较常用的一些方法，当然还有一些其他的测试方法。如：Pairwise 、 正交实验法(allpairspy) 、决策表等等，如果感兴趣的可以自行去了解学习。对以上有疑惑的可以关注+留言+点赞进行互动讨论。
网友评论