下载掌阅APP，畅读海量书库
立即打开
（1）能够依据需求分析原因和结果。
（2）能够绘制因果图，标注相应的关系符号。
（3）能够将因果图转化成判定表。
（4）能够使用因果图法进行测试用例设计。
需求 ：某旅馆住宿系统可办理房间选定、房款支付及房间管理相关业务。其需求描述如下：游客的情况分为支付全部房款（即预期入住天数内所有房款）和支付部分房款（仅支付定金）。可选择“单人间”“双人间”或“豪华间”，若某类型房间有空房，则相应类型的房间被开启；若某类型房间无空房，则“房间已满”提示灯亮。无空房时，支付部分房款的游客选择该类型的房间，则该类型房间不被开启且提示办理退款。若此期间，该类型房间有客人退房，则“房间已满”提示灯灭，该类型房间的某间房被开启的同时提示房款不足。
界面原型 ：旅馆住宿系统业务办理页面如图3.1所示。
图3.1 旅馆住宿系统业务办理页面
首先，基于上述需求，思考采用等价类划分法如何进行测试用例设计。读者采用等价类划分法进行上述需求的测试用例设计时，不难发现设计出的测试用例存在如下特点。其一，数量甚少。其二，仅着重考虑了各项输入条件，并未考虑输入条件的各种组合情况。例如，选择不同的房款支付方式及房间类型，在“房间已满”和“房间空余”的不同前提下，产生的结果会有所差异，此情况在等价类划分法中并未涉及和考虑。其三，未考虑各输入情况之间的相互制约关系。例如，“支付房款”与“支付定金”不能同时选择，最多只能选择一个；“单人间”“双人间”和“豪华间”不能同时选择，最多仅能选择一个等，上述列举的两种情况在等价类划分法中也并未涉及和考虑。
再如某保险公司的预约投保系统，界面原型如图3.2所示。读者针对此界面原型采用等价类划分法进行测试用例设计时，同样会忽略多种关系不能同时存在的情况。例如，“称谓”字段中“先生”与“女士”不能同时成立，最多仅能成立两者之一；“所在地”字段中，当选择某市时，该市所属省份必须同步出现，不能有选择某市后该市所属省份不出现的情况发生；“联系电话”字段中，“固定电话”“小灵通”及“手机号”至少填写一个即可。
图3.2 预约投保系统界面原型
读者充分理解了上述两实例后，则不难理解仅采用等价类划分法并不能很好地处理“当系统中输入项之间以及输入项与输出之间存在多种关系”时的测试用例设计问题，这正是引入因果图法的主要原因。
因果图法是从需求中找出因（输入条件）和果（输出或程序状态的改变），通过分析输入条件之间的关系（组合关系、约束关系等）以及输入和输出之间的关系绘制出因果图，再转化成判定表，从而设计出测试用例的方法，如图3.3所示。不难理解，该方法主要适用于各种输入条件之间存在某种相互制约关系或输出结果依赖于各种输入条件的组合时的情况。
图3.3 因果图法介绍
下面以图3.4为例，对因果图进行初步介绍。
通过观察可以发现，图3.4中无法识别的符号较多，如E、∨等。下面结合图3.5，对因果图中的常用符号含义进行介绍。
图3.4 因果图初识
图3.5 因果图符号
因果图符号的种类繁多，常用符号介绍如下。
（1）CI：原因。I取“0”表示状态不出现，“1”表示状态出现，若有多状态，可用大于1的多个值表示。
（2）EI：结果。I取“0”表示状态不出现，“1”表示状态出现，若有多状态，可用大于1的多个值表示。
（3）恒等：原因结果同时出现。
（4）非：原因出现，结果不出现；原因不出现，结果出现。
（5）或：只要有一个原因出现，结果就出现；原因都不出现，结果就不出现。
（6）且：原因都出现，结果才出现。
注意 ： 图3.5所示的每个结点表示一个状态。
为了表示原因与原因之间、结果与结果之间可能存在的约束条件，因果图中通常还附加一些表示约束条件的符号，如图3.6所示。
图3.6 带约束条件的因果图符号
约束符号也包含多种类型，分别从输入考虑和从输出考虑两方面进行归类如下。
（1）从输入考虑。
①E（互斥／异或）：表示a、b两个原因不会同时成立，最多只有一个成立。
②I（包含）：a、b、c三个原因中至少有一个必须成立。
③O（唯一）：a、b两个原因中必须有一个，且仅有一个成立。
④R（要求）：当a出现时，b必须也出现，不可能出现a而不出现b。
（2）从输出考虑。
M（强制或屏蔽）：a是1时，b必须是0；a是0时，b的值不确定。
下面再次对某保险公司的预约投保系统的“预约投保”页面进行分析，结果如图3.7所示。
图3.7 预约投保页面各字段关系分析
到目前为止，已经强调了因果图中各符号的含义，究竟如何使用因果图法进行测试用例设计呢？可参照如下步骤。
（1）分析需求，提取原因和结果，并赋予标识符；
（2）分析需求，提取因果关系，并表示成因果图；
（3）标明因果图中的约束条件；
（4）将因果图转换成判定表；
（5）为判定表中每一列表示的情况设计测试用例。
注意 ： 原因常常是输入条件或输入条件的等价类；结果常常是输出条件。
下面以旅馆住宿系统为例，针对忽略房间状态和考虑房间状态两种不同的需求情况，采用因果图法进行测试用例设计。
【 任务3.1 】 旅馆住宿系统测试用例设计（忽略房间状态）。
需求 ：某旅馆住宿系统可办理房间选定、房款支付及房间管理相关业务，系统默认房间资源始终保持充足的状态。其需求描述如下：游客的情况分为支付全部房款（即预期入住天数内所有房款）和支付部分房款（仅支付定金）。选择“单人间”“双人间”或“豪华间”，则相应类型的房间被开启。若游客支付的房款不足，则在开启房间的同时系统提示房款不足。
界面原型 ：旅馆住宿系统业务办理页面（忽略房间状态）如图3.8所示。
图3.8 旅馆住宿系统业务办理页面（忽略房间状态）
问题 ：采用因果图法进行测试用例设计。
前提条件：对需求进行分析后可发现，该需求的输入项与输入项之间以及输入项与结果之间存在多种关系，此时采用因果图法进行测试用例设计更为合适。
第1步，分析需求，找出原因和结果，即输入和输出。
原因：
（1）游客支付全部房款。
（2）游客支付部分房款。
（3）游客选择“单人间”。
（4）游客选择“双人间”。
（5）游客选择“豪华间”。
结果：
（21）该类型房间被打开且提示房款支付不足。
（22）某单人间被打开。
（23）某双人间被打开。
（24）某豪华间被打开。
第2步，绘制因果图，并标注相应的关系符号，如图3.9所示。图3.9中，所有原因结点显示于左侧，所有结果结点显示于右侧，中间结点表示处理的中间状态。
图3.9 业务办理_因果图（忽略房间状态）
中间结点：
（11）已支付房款。
（12）已选择房间类型。
注意 ： 中间结点的设立并非必须要完成的工作，但是它的设立可使绘制出的因果图更简单和美观，阅读起来也较为方便。
第3步，转换成判定表，如表3.1所示。
表3.1 业务办理_判定表（忽略房间状态）
第4步，可将表3.1作为确定测试用例的依据。设计测试用例如表3.2所示。
表3.2 业务办理_测试用例设计（忽略房间状态）
【 任务3.2 】 旅馆住宿系统测试用例设计（考虑房间状态）。
需求 ：某旅馆住宿系统可办理房间选定、房款支付及房间管理相关业务。其需求描述如下：游客的情况分为支付全部房款（即预期入住天数内所有房款）和支付部分房款不足（仅支付定金）。可选择“单人间”“双人间”或“豪华间”，若某类型房间有空房，则相应类型的房间被开启；若某类型房间无空房，则“房间已满”提示灯亮。无空房时，支付部分房款的游客选择该类型的房间，则该类型房间不被开启且提示办理退款。若此期间，该类型房间有客人退房，则“房间已满”提示灯灭，该类型房间的某间房被开启的同时提示房款不足。
界面原型 ：旅馆住宿系统业务办理页面（考虑房间状态）如图3.10所示。
图3.10 旅馆住宿系统业务办理页面（考虑房间状态）
问题 ：采用因果图法进行测试用例设计。
前提条件：对需求进行分析后可发现，该需求的输入项与输入项之间以及输入项与结果之间存在多种关系，此时采用因果图法进行测试用例设计更为合适。
第1步，分析需求说明，找出原因和结果，即输入和输出。
原因：
（1）该类型房间有空房。
（2）游客支付部分房款。
（3）游客支付全部房款。
（4）游客选择“单人间”。
（5）游客选择“双人间”。
（6）游客选择“豪华间”。
结果：
（21）该类型房间“房间已满”灯亮。
（22）提示办理退款。
（23）提示房款不足。
（24）某单人间被打开。
（25）某双人间被打开。
（26）某豪华间被打开。
第2步，绘制因果图，并标注相应关系符号，如图3.11所示。图3.11中，所有原因结点显示于左侧，所有结果结点显示于右侧，中间结点表示处理的中间状态。
图3.11 业务办理_因果图（考虑房间状态）
中间结点：
（11）支付房款不足且已选择房间类型。
（12）已选择房间类型。
（13）该类型房间有空房并且提示房款支付不足。
（14）房款已支付。
注意 ： 中间结点的设置并非必须要完成的工作，但是设立中间结点可使绘制出的因果图更简单和美观，阅读起来也较为方便。
第3步，转换成判定表，如表3.3和表3.4所示。
表3.3 业务办理_判定表一（考虑房间状态）
表3.4 业务办理_判定表二（考虑房间状态）
注意 ：
①转化判定表时，通过分析，可先将违反约束条件的组合省略，再列出判定表，则可大大减少工作量。本任务组合项较多，为避免讲解不充分，特列举出所有组合。
②表3.3和表3.4中未列出中间结点的取值情况，读者可自行列举。
第4步，在判定表中，空白部分表示因违反约束条件而不可能出现的情况，故不对此进行测试用例设计。将表3.3和表3.4作为确定测试用例的依据。设计测试用例如表3.5所示。
表3.5 业务办理_测试用例设计（考虑房间状态）
注意 ： 需求中描述当房间没有空余时，“房间已满”灯亮。但是，读者会发现界面原型中并未显示“灯”。在此，值得一提的是，实际项目中界面原型可能会采用其他方式来实现需求说明中的要求，所采取的表现方式或许更加易于理解和使用。建议开发人员确定界面原型后，及时与客户进行沟通并确认，便于后续工作在此基础上顺利开展。
思考： 若此处采用等价类划分法设计测试用例，又该如何考虑呢？
【 练习3.1 】 采用因果图法针对以下需求进行测试用例设计。
需求 ：输入的第一个字符必须是#或∗，第二个字符必须是一个数字，此情况下进行文件的修改。若第一个字符不是#或∗，则给出信息N；若第二个字符不是数字，则给出信息M。
【 练习3.2 】 采用因果图法针对以下需求进行测试用例设计。
需求 ：有一个自动售货机，若投入5角或1元的硬币，按下“橙汁”或“啤酒”按钮，则相应的饮料就送出来。若售货机没有零钱，则显示“零钱找完”的红灯亮，这时再投入1元硬币并按下按钮后，饮料不送出来而且1元硬币也退出来；若售货机有零钱，则显示“零钱找完”的红灯灭，投入1元硬币并按下按钮后，在送出饮料的同时退还5角硬币。