|
|
|
|
知识路径： > 测试技术的分类 > 黑盒测试案例设计技术 > 测试用例设计方法 >
|
|
|
被考次数：4次
|
|
|
被考频率：
中频率
|
|
|
总体答错率：
36%
|
|
知识难度系数：
|
|
|
考试要求：
掌握
|
|
|
相关知识点：30个
|
|
|
|
|
前节介绍的等价类划分方法和边界值分析法都是着重考虑输入条件，并没有考虑到输入情况的各种组合，也没考虑到各个输入情况之间的相互制约关系。如果在测试时必须考虑输入条件的各种组合，可能的组合数将是天文数字。因此必须考虑描述多种条件的组合，相应地产生多个动作的形式来考虑设计测试用例，这就需要利用因果图。在软件工程中，有些程序的功能可以用判定表的形式来表示，并根据输入条件的组合情况规定相应的操作。很自然，应该为判定表中的每一列设计一个测试用例，以便保证测试程序在输入条件的某种组合下，操作是正确的。
|
|
|
|
|
|
因果图法是从用自然语言书写的程序规格说明的描述中找出因（输入条件）和果（输出或程序状态的改变），通过因果图转换为判定表。
|
|
|
|
|
|
①分析程序规格说明的描述中，哪些是原因，哪些是结果。原因常常是输入条件或是输入条件的等价类，而结果是输出条件。
|
|
|
|
②分析程序规格说明的描述中语义的内容，并将其表示成连接各个原因与各个结果的“因果图”。
|
|
|
|
③标明约束条件。由于语法或环境的限制，有些原因和结果的组合情况是不可能出现的。为表明这些特定的情况，在因果图上使用若干个标准的符号标明约束条件。
|
|
|
|
|
|
|
|
因果图生成的测试用例（局部，组合关系下的）包括了所有输入数据的取TRUE与取FALSE的情况，构成的测试用例数目达到最少，且测试用例数目随输入数据数目的增加而增加。
|
|
|
|
事实上，在较为复杂的问题中，这个方法常常是十分有效的，它能有力地帮助我们确定测试用例。当然，如果哪个开发项目在设计阶段就采用了判定表，也就不必再画因果图了，而是可以直接利用判定表设计测试用例了。
|
|
|
|
通常在因果图中，用Ci表示原因，Ei表示结果，其基本符号如下图所示。各结点表示状态，可取“0”或“1”值。“0”表示某状态不出现，“1”表示某状态出现。
|
|
|
|
|
|
|
|
①恒等：若原因出现，则结果出现；若原因不出现，则结果也不出现。
|
|
|
|
②非（~）：若原因出现，则结果不出现；若原因不出现，则结果出现。
|
|
|
|
③或（∨）：若几个原因中有1个出现，则结果出现；若几个原因都不出现，则结果不出现。
|
|
|
|
④与（∧）：若几个原因都出现，结果才出现。若其中有1个原因不出现，则结果不出现。
|
|
|
|
为了表示原因与原因之间、结果与结果之间可能存在的约束条件，在因果图中可以附加一些表示约束条件的符号。从输入（原因）考虑，有4种约束，例如：（a）、（b）、（c）、（d）。从输出（结果）考虑，还有1种约束，例如：（e），如下图所示。
|
|
|
|
|
|
|
|
①E（互斥）：表示a、b两个原因不会同时成立，两个中最多有一个可能成立。
|
|
|
|
②I（包含）：表示a、b、c这3个原因中至少有一个必须成立。
|
|
|
|
③O（惟一）：表示a和b当中必须有一个，且仅有一个成立。
|
|
|
|
④R（要求）：表示当a出现时，b必须也出现。a出现时不可能b不出现。
|
|
|
|
⑤M（屏蔽）：表示当a是1时，b必须是0。而当a为0时，b的值不定。
|
|
|
|
|
|
例如：有一个处理单价为1元5角钱的盒装饮料的自动售货机软件。若投入1元5角硬币，按下“可乐”、“雪碧”或“红茶”按钮，相应的饮料就送出来。若投入的是两元硬币，在送出饮料的同时退还5角硬币。
|
|
|
|
|
|
|
|
③按“可乐”按钮；④按“雪碧”按钮；⑤按“红茶”按钮。
|
|
|
|
|
|
|
|
|
|
根据原因和结果，我们可以设计这样一个因果图（如下图所示。）
|
|
|
|
|
|
|
|
转换为测试用例，如下表所示，每一列可作为确定测试用例的依据。
|
|
|
|
|
|
|
