实验3因果图法与用例设计
1. 实验目标
(1) 能够依据需求分析原因和结果。
(2) 能够绘制因果图，标注相应的关系符号。
(3) 能够将因果图转化成判定表。
(4) 能够使用因果图法进行测试用例设计。
2. 背景知识
需求: 某旅馆住宿系统可办理房间选定、房款支付及房间管理相关业务。其需求描述如下: 游客的情况分为支付全部房款（即预期入住天数内所有房款）和支付部分房款（仅支付定金）。可选择“单人间”“双人间”或“豪华间”，若某类型房间有空房，则相应类型的房间被开启；若某类型房间无空房，则“房间已满”提示灯亮。无空房时，支付部分房款的游客选择该类型的房间，则该类型房间不被开启且提示办理退款。若此期间，该类型房间有客人退房，则“房间已满”提示灯灭，该类型房间的某间房被开启的同时提示房款不足。
界面原型: 旅馆住宿系统业务办理页面如图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. 实验任务
【任务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业务办理_判定表（忽略房间状态）输入
条件游客支付全部房款（1）11110000000游客支付部分房款（2）00001111000游客选择“单人间”（3）10001000100游客选择“双人间”（4）01000100010游客选择“豪华间”（5）00100010001中间
结果已支付房款（11）11111111000已选择房间类型（12）11101110111输出
结果该类型房间被打开且提示房款支付不足（21）00001110000某单人间被打开（22）10001000000某双人间被打开 （23）01000100000某豪华间被打开（24）00100010000测 试 用 例YYYYYYYYYYY第4步，可将表3.1作为确定测试用例的依据。设计测试用例如表3.2所示。表3.2业务办理_测试用例设计（忽略房间状态）编号输入预 期 结 果1游客支付全部房款，选择“单人间”某单人间被打开2游客支付全部房款，选择“双人间” 某双人间被打开3游客支付全部房款，选择“豪华间” 某豪华间被打开4游客支付全部房款，未选择任何类型的房间所有房间均不被打开5游客支付部分房款，选择“单人间”某单人间被打开且系统提示房款支付不足6游客支付部分房款，选择“双人间”某双人间被打开且系统提示房款支付不足7游客支付部分房款，选择“豪华间”某豪华间被打开且系统提示房款支付不足8游客支付部分房款，未选择任何类型的房间所有房间均不被打开9游客不进行支付，选择“单人间” 所有房间均不被打开10游客不进行支付，选择“双人间” 所有房间均不被打开11游客不进行支付，选择“豪华间” 所有房间均不被打开【任务3.2】旅馆住宿系统测试用例设计（考虑房间状态）。 
需求: 某旅馆住宿系统可办理房间选定、房款支付及房间管理相关业务。其需求描述如下: 游客的情况分为支付全部房款（即预期入住天数内所有房款）和支付部分房款不足（仅支付定金）。可选择“单人间”“双人间”或“豪华间”，若某类型房间有空房，则相应类型的房间被开启；若某类型房间无空房，则“房间已满”提示灯亮。无空房时，支付部分房款的游客选择该类型的房间，则该类型房间不被开启且提示办理退款。若此期间，该类型房间有客人退房，则“房间已满”提示灯灭，该类型房间的某间房被开启的同时提示房款不足。
界面原型: 旅馆住宿系统业务办理页面（考虑房间状态）如图3.10所示。
图3.10旅馆住宿系统业务办理页面（考虑房间状态）
问题: 采用因果图法进行测试用例设计。
前提条件: 对需求进行分析后可发现，该需求的输入项与输入项之间以及输入项与结果之间存在多种关系，此时采用因果图法进行测试用例设计更为合适。
第1步，分析需求说明，找出原因和结果，即输入和输出。
原因: 
(1) 该类型房间有空房。
(2) 游客支付部分房款。
(3) 游客支付全部房款。
(4) 游客选择“单人间”。
(5) 游客选择“双人间”。
(6) 游客选择“豪华间”。
结果:
（21） 该类型房间“房间已满”灯亮。
（22） 提示办理退款。
（23） 提示房款不足。
（24） 某单人间被打开。
（25） 某双人间被打开。
（26） 某豪华间被打开。
第2步，绘制因果图，并标注相应关系符号，如图3.11所示。图3.11中，所有原因结点显示于左侧，所有结果结点显示于右侧，中间结点表示处理的中间状态。
中间结点: 
(11) 支付房款不足且已选择房间类型。
(12) 已选择房间类型。
(13) 该类型房间有空房并且提示房款支付不足。
(14) 房款已支付。
注意: 中间结点的设置并非必须要完成的工作，但是设立中间结点可使绘制出的因果图更简单和美观，阅读起来也较为方便。
图3.11业务办理_因果图（考虑房间状态）
第3步，转换成判定表，如表3.3和表3.4所示。表3.3业务办理_判定表一（考虑房间状态）输入条件(1)11111111111111111111111111111111(2)11111111111111110000000000000000(3)11111111000000001111111100000000(4)11001100110011001100110011001100(5)10101010101010101010101010101010(6)00001111000011110000111100001111输出结果（21）000000000000（22）000000000000（23）110100000000（24）100010000000（25）010001000000（26）000100010000测试用例YYYYYYYYYYYY表3.4业务办理_判定表二（考虑房间状态）输入条件(1)00000000000000000000000000000000(2)11111111111111110000000000000000(3)11111111000000001111111100000000(4)11001100110011001100110011001100(5)10101010101010101010101010101010(6)00001111000011110000111100001111输出结果（21）111111111111（22）110111110000（23）000000000000（24）000000000000（25）000000000000（26）000000000000测试用例YYYYYYYYYYYY注意: 
① 转化判定表时，通过分析，可先将违反约束条件的组合省略，再列出判定表，则可大大减少工作量。本任务组合项较多，为避免讲解不充分，特列举出所有组合。
② 表3.3和表3.4中未列出中间结点的取值情况，读者可自行列举。
第4步，在判定表中，空白部分表示因违反约束条件而不可能出现的情况，故不对此进行测试用例设计。将表3.3和表3.4作为确定测试用例的依据。设计测试用例如表3.5所示。续表表3.5业务办理_测试用例设计（考虑房间状态）编号输入预 期 结 果1游客支付部分房款，选择“单人间”且有空房某单人间被打开且系统提示房款不足2游客支付部分房款，选择“双人间”且有空房某双人间被打开且系统提示房款不足3游客支付部分房款，未选择任何类型的房间所有房间均不被打开且“房间已满”灯为灭的状态4游客支付部分房款，选择“豪华间”且有空房某豪华间被打开且系统提示房款不足5游客支付全部房款，选择“单人间”且有空房某单人间被打开6游客支付全部房款，选择“双人间”且有空房某双人间被打开7游客支付全部房款，未选择任何类型的房间所有房间均不被打开且“房间已满”灯为灭的状态8游客支付全部房款，选择“豪华间”且有空房某豪华间被打开9游客不进行支付，选择“单人间”且有空房所有房间均不被打开且“房间已满”灯为灭的状态10游客不进行支付，选择“双人间”且有空房所有房间均不被打开且“房间已满”灯为灭的状态11游客不进行支付，未选择任何类型的房间且有空房所有房间均不被打开且“房间已满”灯为灭的状态12游客不进行支付，选择“豪华间”且有空房所有房间均不被打开且“房间已满”灯为灭的状态13游客支付部分房款，选择“单人间”且没有空房“房间已满”灯为亮的状态且系统提示办理退款14游客支付部分房款，选择“双人间”且没有空房“房间已满”灯为亮的状态且系统提示办理退款15游客支付部分房款，未选择任何类型的房间“房间已满”灯为亮的状态16游客支付部分房款，选择“豪华间”且没有空房“房间已满”灯为亮的状态且系统提示办理退款17游客支付全部房款，选择“单人间”且没有空房“房间已满”灯为亮的状态且系统提示办理退款18游客支付全部房款，选择“双人间”且没有空房“房间已满”灯为亮的状态且系统提示办理退款19游客支付全部房款，未选择任何类型的房间“房间已满”灯为亮的状态20游客支付全部房款，选择“豪华间”且没有空房“房间已满”灯为亮的状态且系统提示办理退款21游客不进行支付，选择“单人间”且没有空房所有房间均不被打开且“房间已满”灯为亮的状态22游客不进行支付，选择“双人间”且没有空房所有房间均不被打开且“房间已满”灯为亮的状态23游客不进行支付，未选择任何类型的房间且没有空房所有房间均不被打开且“房间已满”灯为亮的状态24游客不进行支付，选择“豪华间”且没有空房所有房间均不被打开且“房间已满”灯为亮的状态注意: 需求中描述当房间没有空余时，“房间已满”灯亮。但是，读者会发现界面原型中并未显示“灯”。在此，值得一提的是，实际项目中界面原型可能会采用其他方式来实现需求说明中的要求，所采取的表现方式或许更加易于理解和使用。建议开发人员确定界面原型后，及时与客户进行沟通并确认，便于后续工作在此基础上顺利开展。
思考: 若此处采用等价类划分法设计测试用例，又该如何考虑呢？
4. 拓展练习
【练习3.1】采用因果图法针对以下需求进行测试用例设计。 
需求: 输入的第一个字符必须是#或，第二个字符必须是一个数字，此情况下进行文件的修改。若第一个字符不是#或，则给出信息N;若第二个字符不是数字，则给出信息M。
【练习3.2】采用因果图法针对以下需求进行测试用例设计。
需求: 有一个自动售货机，若投入5角或1元的硬币，按下“橙汁”或“啤酒”按钮，则相应的饮料就送出来。若售货机没有零钱，则显示“零钱找完”的红灯亮，这时再投入1元硬币并按下按钮后，饮料不送出来而且1元硬币也退出来；若售货机有零钱，则显示“零钱找完”的红灯灭，投入1元硬币并按下按钮后，在送出饮料的同时退还5角硬币。实验4决策表法与用例设计
1. 实验目标
(1) 理解决策表法的原理。
(2) 能够使用决策表法进行测试用例设计。
(3) 能够在真实项目中灵活运用决策表法。
2. 背景知识
在使用因果图法进行测试用例设计的过程中用到了判定表。判定表又称决策表，是使用决策表法进行测试用例设计的核心，是分析和表达多逻辑条件下执行不同操作的情况的有效工具。因此，决策表法是一种能够将复杂逻辑关系和多条件组合情况表达得较为明确的方法，适用于程序中输入、输出较多或输入与输出之间相互制约条件较多的情况。在所有黑盒测试方法中，基于决策表法的测试是最严格、最具有逻辑性的。
下面通过表4.1所示实例加以说明。表4.1决策表实例问题与建议12345678问题是否劳累YYYYNNNN是否喜欢YYNNYYNN是否难理解YNYNYNYN建议重听一遍√继续进行√进行下一题√√休息√√√√图4.1决策表模型图不难理解，决策表能够依据各种可能的情况将看似复杂的问题全部罗列出来，简明且无遗漏。同理可得，在软件测试中，利用决策表法也能够设计出完整的测试用例集合。
图4.1所示为决策表模型图。
决策表模型图中包含条件桩、条件项、动作桩和动作项四项元素，简要解释如下。
(1) 条件桩: 问题的所有条件的集合，包含各种条件，其中各条件次序无严格限制。
(2) 条件项: 问题的所有条件的各种取值的集合，包含条件桩中各种条件的各种取值的组合，其中各条件次序无严格限制。
(3) 动作桩: 问题的所有可采取操作的集合，包含各种可采取的操作，其中各操作次序无严格限制。
(4) 动作项: 针对条件项的各种组合的取值情况下，应该采取的对应操作。 
需要提醒的是，决策表中任何一个条件组合的特定取值及其相应要执行的操作称为规则。 
不难理解，决策表法实质为直接把测试输入中所有可能的情况进行组合，并汇总所对应的操作结果，这也是决策表法的优势所在。显然，利用决策表法能够设计出各种组合类型的完整测试用例集合。但不得不承认，决策表法并非十全十美，它不能表达重复执行的动作，如循环结构等。因此，读者应辩证地看待该方法。
至此，读者已对决策表法有了相关见解，如何使用决策表法成为下一步要研究的重点。读者可参照以下步骤进行测试用例设计。
(1) 列出所有的条件桩和动作桩。
(2) 确定规则的个数。
(3) 填入条件项。
(4) 填入动作项。
(5) 简化决策表，合并类似规则或相同动作。
注意: 
① 针对“确定规则的个数”，需要提醒的是，若某决策表中有n个条件，且每个条件可取真、假两种值，则共有2n条规则；若某决策表中有n个条件，且每个条件可取1、2、3、…、m，则共有mn条规则。
② 针对决策表的简化过程，提醒以下两点: 其一，若表中有两条或两条以上的规则具有相同的操作，且在条件项之间存在较为类似的关系，则可进行规则合并；其二，规则合并后得到的条件项用符合“—”表示，代表执行的动作与该条件的取值无关，即成为无关条件。
读者已从理论层面上认识了决策表法，下面将以旅馆住宿系统及经典的NextDate函数为例，从实践角度进一步介绍决策表法的应用。
3. 实验任务
【任务4.1】旅馆住宿系统测试用例设计。
需求: 为了进一步扩大业务和提升营业额，旅馆住宿系统支持房间预订、定金支付及会员卡办理功能，且规定在旅游旺季客房紧张的情况下，优先为进行了房间预订且已支付定金或持有会员卡的游客办理房间入住。
问题: 采用决策表法进行测试用例设计。
前提条件: 需求中输入与输出之间相互制约的条件较多，故适合采用决策表法设计测试用例。
第1步，分析需求，列出所有的条件桩和动作桩。
条件桩: 
(1) 是否进行房间预订。
(2) 是否已支付定金。
(3) 是否为旅馆会员。
动作桩:
(1) 优先办理房间入住。
(2) 做其他处理。 
第2步，确定规则的个数。在此有3个条件，且每个条件有两种取值（是或否），故应有2×2×2=8种规则。此步骤得出表4.2所示的决策表。表4.2旅馆住宿系统_决策表_确定规则个数条件和动作规则12345678条件是否进行房间预订是否已支付定金是否为旅馆会员动作优先办理房间入住做其他处理第3步，填入条件项。条件项即条件桩中各种条件的各种取值的组合，其中各条件次序无严格限制。此步骤得出表4.3所示的决策表。表4.3旅馆住宿系统_决策表_填入条件项条件和动作规则12345678条件是否进行房间预订YYYYNNNN是否已支付定金YYNNYYNN是否为旅馆会员YNYNYNYN动作优先办理房间入住做其他处理第4步，填入动作项。此步骤得出表4.4所示的决策表。表4.4旅馆住宿系统_决策表_填入动作项条件和动作规则12345678条件是否进行房间预订YYYYNNNN是否已支付定金YYNNYYNN是否为旅馆会员YNYNYNYN动作优先办理房间入住XXXXX做其他处理XXX第5步，简化决策表，合并类似规则或相同动作。经分析可知，规则1与规则2、规则5与规则7、规则6与规则8可进行合并，此步骤得出表4.5所示的决策表。表4.5旅馆住宿系统_简化后的决策表条件和动作规则12345条件是否进行房间预订YYYNN是否已支付定金YNN——是否为旅馆会员—YNYN动作优先办理房间入住XXX做其他处理XX至此，依据表4.5所示的所有规则可得出最终测试用例，如表4.6所示。表4.6旅馆住宿系统_最终测试用例编号输 入 条 件输 入 数 据预 期 结 果1已进行房间预订且已支付定金房间编号、类型、定金金额优先办理入住2已进行房间预订、未支付定金，是旅馆会员房间编号、类型、会员卡卡号优先办理入住3已进行房间预订、未支付定金，不是旅馆会员房间编号、类型做其他处理4未进行房间预订，是旅馆会员会员卡卡号优先办理入住5未进行房间预订，不是旅馆会员做其他处理注意: 
① 实际使用决策表时，常常优先进行化简。
② 体会因果图法与决策表法的不同。
【任务4.2】NextDate函数测试用例设计。
需求: NextDate函数包含了三个输入变量，分别为Month(月份)、Day(日期)和Year(年)；函数输出为输入日期的后一天的日期。例如输入为2010年10月10日，则输出为2010年10月11日。其中，输入变量Month、Day和Year都为整数，且取值范围满足1≤Month≤12，1≤Day≤31，1980≤Year≤2020。
问题: 采用决策表法进行测试用例设计。
前提条件: 需求中存在输入、输出较多或输入与输出之间相互制约条件较多的情况，故适合采用决策表法进行测试用例设计。
第1步，分析需求，列出所有的条件桩和动作桩。
条件桩: 
(1) Month。
(2) Day。
(3) Year。
动作桩:
(1) Day变量值加1。
(2) Day变量值复位为1。
(3) Month变量值加1。
(4) Month变量值复位为1。
(5) Year变量值加1。
注意: 为获得输入日期的后一天的日期，NextDate函数仅须执行上述5种类型的操作。
第2步，确定规则的个数。依据“若某决策表中有n个条件，且每个条件可取真、假两种值，则共有2n条规则；若某决策表中有n个条件，且每个条件可取1、2、3、…、m，则共有mn条规则。”可知，在此有3个条件，且每个条件的具体取值如下。
(1) Month可有以下4种取值: 
① M1={Month有30天}。
② M2={Month有31天，12月除外}。
③ M3={Month为12月}。
④ M4={Month为2月}。
(2) Day可有以下5种取值: 
① D1={1≤Day≤27}。
② D2={Day=28}。
③ D3={Day=29}。 
④ D4={Day=30}。 
⑤ D5={Day=31}。
(3) Year可有以下2种取值: 
① Y1={Year为是闰年}。
② Y2={Year为非闰年}。
综上所述，应有4×5×2=40种规则。
第3步，填入条件项。条件项即条件桩中各种条件的各种取值的组合，其中各条件次序无严格限制。实际使用决策表时，常常优先进行化简，在此，填入条件项时即可结合实际情况进行适当化简。
填入条件项的过程中，以Day为填写基准（以条件中取值情况最多的条件项为基准），进行四组数据的填入（因为Month有4种取值），而Year仅对“Month=M4，且Day=D2或D3”时的情况有影响。此步骤得出表4.7所示的决策表。续表表4.7NextDate函数_决策表_填入条件项条件和动作规则12345678910111213141516171819202122条件MonthM1M1M1M1M1M2M2M2M2M2M3M3M3M3M3M4M4M4M4M4M4M4DayD1D2D3D4D5D1D2D3D4D5D1D2D3D4D5D1D2D2D3D3D4D5Year————————————————Y1Y2Y1Y2——动作无效Day加1Day复位Month加1Month复位Year加1第4步，填入动作项。此步骤得出表4.8所示的决策表。表4.8NextDate函数_决策表_填入动作项条件和动作规则12345678910111213141516171819202122条件MonthM1M1M1M1M1M2M2M2M2M2M3M3M3M3M3M4M4M4M4M4M4M4DayD1D2D3D4D5D1D2D3D4D5D1D2D3D4D5D1D2D2D3D3D4D5Year————————————————Y1Y2Y1Y2——动作无效√√√√Day加1√√√√√√√√√√√√√Day复位√√√√√Month加1√√√√Month复位√Year加1√第5步，简化决策表，合并类似规则或相同动作。经分析可知，规则1、规则2与规则3，规则6、规则7、规则8与规则9，规则11、规则12、规则13与规则14，以及规则21与规则22可进行合并，此步骤得出表4.9所示的决策表。续表表4.9NextDate函数_简化后决策表 条件和动作规则1～3456～91011～141516171819202122条件MonthM1M1M1M2M2M3M3M4M4M4M4M4M4DayD1～D3D4D5D1～D4D5D1～D4D5D1D2D2D3D3D4D5Year————————Y1Y2Y1Y2——动作无效√√√√Day加1√√√√√Day复位√√√√√动作Month加1√√√√Month复位√Year加1√至此，依据表4.9所示的所有规则可得出最终测试用例，如表4.10所示。表4.10NextDate函数_最终测试用例编号输 入 条 件输 入 数 据预 期 结 果1输入3个变量值Year=2010、Month=9、Day=1020109112输入3个变量值Year=2010、Month=9、Day=3020101013输入3个变量值Year=2010、Month=9、Day=31无效4输入3个变量值Year=2010、Month=10、Day=10201010115输入3个变量值Year=2010、Month=10、Day=3120101116输入3个变量值Year=2010、Month=12、Day=10201012117输入3个变量值Year=2010、Month=12、Day=312011118输入3个变量值Year=2010、Month=2、Day=1020102119输入3个变量值Year=2012、Month=2、Day=28201222910输入3个变量值Year=2010、Month=2、Day=2820103111输入3个变量值Year=2012、Month=2、Day=2920123112输入3个变量值Year=2010、Month=2、Day=29无效13输入3个变量值Year=2010、Month=2、Day=30无效注意: 请读者尝试采用等价类划分法、边界值分析法和决策表法进行测试用例设计，并体会等价类划分法、边界值分析法与决策表法的不同。
4. 拓展练习
【练习】采用决策表法针对以下需求进行测试用例设计。
需求: 订购单的检查规则为，若订购单金额超过600元且未过期，则发出批准单和提货单；若订购单金额超过600元，但过期了，则不发批准单；如果订购单金额低于600元，则不论是否过期都发出批准单和提货单，在过期的情况下还需发出通知单。