判定表

测试⽤例设计--判定表1、为什么⽤判定表设计测试⽤例？等价类⽅法详细的考虑了需求输⼊域，但对于输⼊域与输⼊域存在关联时⽆法覆盖，（⽐如等价类划分设计测试⽤例时，设计⼀条新的测试⽤例，使其仅覆盖⼀个⽆效等价类，直⾄所有的⽆效等价类完全被覆盖，没有考虑⽆效等价类与⽆效等价类的组合情况）。

所以需要⼀种能考虑输⼊域间的互相关系设计⽅法来考虑业务描述性的测试需求。

2、什么是判定表？判断表是分析喝表达若⼲输⼊条件下，被测对象根据输⼊作出不同响应的⼯具，适⽤于业务逻辑关系和多种条件组合情况。

判定表的结构条件桩：被测对象的所有输⼊条件项：针对条件桩可能输⼊的真假值动作桩：针对条件桩被测对象可能采取的所有动作动作项：针对动作桩，被测对象响应可能结果取值3、怎么⽤判定表设计测试⽤例？步骤：⼀、列出所有的条件和动作⼆、根据提取出来的条件桩和动作桩，设计判定表确定规则的个数（假如有n个条件，每个条件有2个取值（0、1），就可以产⽣2的n次⽅种规则）三、填写判定表四、简化判定表（合并判定表是牺牲测试充分性，混乱业务逻辑为代价。

8条以内的规则不建议合并）五、抽取测试⽤例（简化判定表后，可抽取判定表中的每⼀条规则作为测试⽤例，判定表得到的是测试规则，不是最终的测试⽤例。

规则不能验证功能点正确性，仅验证业务规则的正确性）4、判定表设计测试⽤例的优缺点？优点：判定表充分考虑了输⼊域之间的组合情况，每条规则覆盖了多条输⼊条件，考虑输⼊的约束关系，降低了漏测的风险。

同时利⽤判定表可推断出需求规格本⾝的逻辑性，反向证明了需求的正确。

缺点：当输⼊项过多时，规则数以2的n次⽅剧增，判定表会⾮常庞⼤，采⽤判定表合并时会造成逻辑缺失，业务混乱错误的情况。

5、判断表设计测试⽤例的例⼦⽰列⼀：停机或⽋费不允许主被叫步骤⼀：列出所有的条件和动作条件：停机/⽋费动作：主被叫步骤⼆：确定规则数有3个条件，每个条件有2个取值，故有8个规则步骤三：填写判定表步骤四：只有4条规则不合并，8条以下的规则不建议合并步骤五：规则抽取：(1)⽤户不停机不⽋费，可进⾏主被叫(2)⽤户不停机⽋费，不允许主被叫(3)⽤户停机不⽋费，不允许主被叫(4)⽤户停机⽋费，不允许住被叫。

测试⽤例设计--判定表1.定义判定表通常由四部分组成，如上图：条件桩：它列出决定⼀组条件的对象；条件项：它列出各种可能的条件组合；动作桩：它列出所有的操作；动作项：它列出在对应的条件组合下的动作。

2.应⽤的范围在多个条件多个动作，并且每个条件的取值只有两种的情况下，我们就可以采⽤判定表⽅法。

3.步骤 1）识别条件和动作 2）⽣成判定表 3）简化判定表4.案例订购单的检查。

如果⾦额超过500元，⼜未过期，则发出批准单和提货单；如果⾦额超过500元，但过期了，则不发批准单；如果⾦额低于500元，则不论是否过期都发出批准单和提货单，在过期的情况下还需要发出通知单。

判定表分析过程 1）识别条件和动作条件桩条件项1：⾦额＞500元订购⾦额是否⼤于500元0：⾦额＜=500元1：订单未过期订购单是否过期0：订单过期动作桩动作项发出批准单X：表⽰发出批准单发出提货单X：表⽰发出提货单发出通知单X：发出通知单 2）⽣成判定表条件桩条件项订购⾦额是否⼤于500元1100订购单是否过期1010发出批准单X X X发出提货单X X X发出通知单X 3)简化判定表在很多情况下，⼀个判定表写出来以后，是很复杂的，我们需要对其进⾏简化。

如果表中有两条或者多条规则具有相同的动作，并且其条件项之间存在极为相似的关系，我们就可以将其合并。

条件桩条件项订购⾦额是否⼤于500元--10订购单是否过期100发出批准单X X发出提货单X X发出通知单X 这⾥引⼊⼀个概念，规则，以上判定表⾥，右部的每⼀列（条件项和对应的动作项）都是⼀条规则。

以上判定表⾥每⼀条规则都可以转化为测试⽤例。

判定表练习:对功率大于50马力的机器且维修记录不全或已运行10年以上的机器，应给予优先的维修处理，利用判定表进行分析，完成用例设计。

条件：
1）功率是否大于50马力
2）维修记录是否齐全
3）运行是否超过10年
动作：
1)进行优先处理
判定表如下:
有两种合并方法：
1）合并1357项、48项
2）合并1357项、68项
但这样合并之后我们看看后三条规则,写出的用例逻辑性会变差，让看的人感觉莫名其妙,比如第二张表的第4条规则,写出用例标题应该是“验证功率不到50马力且运行不超过10年的机器的处理优先级”，这样会给人感觉功率和运行年限之间存在一定的逻辑关系，但其实功率与马力之间才是强逻辑关系,功率与运行年限之间的逻辑关系是比较弱的.所以建议还是不合并为好，不要为了节省几个用例去牺牲整个用例的逻辑性.这道题只把1357列合并就可以了，也就是说对于运行超过10年的机器，不管它的马力和维修记录如何都必须进行优先处理.。

软件工程判定表和判定树题目
软件工程判定表和判定树题目可能如下：
1. 判定表题目：
假设在一个软件工程项目中，存在以下情况需要判断：
条件（Condition）：是否选择使用数据库作为数据存储方式？动作（Action）：如果选择使用数据库，则需进行数据库配置；如果不选择使用数据库，则不需进行数据库配置。

请根据上述情况编写一个判定表，确定是否需要进行数据库
配置。

2. 判定树题目：
假设在一个软件工程项目中，存在以下情况需要判断：
条件（Condition）：是否选择使用框架进行开发？
子条件（Sub-Condition）：如果选择使用框架，则需考虑使
用的是前端框架还是后端框架？
子子条件（Sub-Sub-Condition）：如果选择使用前端框架，
则需考虑使用的是React还是Vue？
动作（Action）：如果选择使用React，则使用React进行开发；如果选择使用Vue，则使用Vue进行开发；如果选择不
使用框架，则进行自主开发。

请根据上述情况编写一个判定树，确定最终使用的开发方式
和框架。

软件测试基础（四）⽤例设计⽅法之判定表驱动法判定表也称为决策表，⽤于描述程序输⼊条件组合与相应的程序处理动作之间的对应关系。

等价类划分和边界值分析都没有考虑被测程序输⼊条件的组合情况，只是孤⽴地考虑各个输⼊条件的测试数据取值问题，对输⼊组合情况下产⽣可能产⽣的错误没有进⾏充分地测试。

判定表驱动法从多个输⼊条件组合的⾓度来满⾜测试的覆盖率要求，是⿊盒测试⽅法中最严格、最有逻辑的测试⽅法。

1.判定表的构造与化简判定表⼀般由上图4个部分构成（1）条件桩：列出了问题所包含的所有条件。

⼀般情况下，条件的排列书必须⽆关紧要。

（2）动作桩：列出了问题规定可能采取的操作。

对这些操作的排列顺序⼀般没什么要求。

（3）条件项：条件桩中每个条件可以取真值或者假植，条件项给出了这些条件取值的多种组合情况。

（4）动作项：列出了在各种条件取值情况下应当采取的相应动作。

判定表的构造过程⼀般包括5个步骤： ①列出所有的条件桩和动作桩 ②根据条件桩中的条件个数确定规则的个数 ③根据条件组合，填⼊条件取值，形成每⼀个条件项 ④填⼊相应的动作项，得到初始判定表 ⑤化简初始判定表，合并相似规则2.判定表构造实例 （1） 假设程序的规格说明要求：“对于各科成绩⾼于85分并且是优秀毕业⽣的⼈员，或总是成绩⼤于450的⼈员，应当优先录取，其他情况进⾏正常处理”。

从规格说明可知，条件桩由“各科成绩均⾼于85分”“优秀毕业⽣”和“总成绩⼤于450分”三个条件构成，动作桩由“优先录取”和“正常处理”两种动作构成。

因为由三个条件，所以有23=8个规则。

根据8种条件取值组合情况，可以得到如下表所⽰判定表序号12345678条件各科成绩⾼于85分Y Y Y Y N N N N 优秀毕业⽣Y Y N N Y Y N N 总成绩⼤于450Y N Y N Y N Y N动作优先录取√√√√√正常处理√√√ 化简之后的判定表如下序号1，23456条件各科成绩⾼于85分Y Y Y N N 优秀毕业⽣Y N N--总成绩⼤于450-Y N Y N动作优先录取√√√正常处理√√ （2） ⼀个函数根据A、B、C三条边的输⼊值怕段是否能够构成三⾓形，如果能够构成三⾓形，进⽽判断是等腰三⾓形还是等边三⾓形。