常用测试用例设计方法-判定表测试用例设计判定表理论判定表设计过程判定表的优缺点判定表中发现的bug个人心得
判定表测试用例设计判定表理论
判定表是用于分析和表现在多个输入条件下系统执行不同动作的工具，能够具体且明确地表现复杂的逻辑关系和多个条件的组合情况。 判定表通常由以下四个部分组成。
(1)列出条件桩)系统的所有输入，不影响列出的输入顺序
)2)动作桩)列出系统可能采取的操作。 这些操作的排列顺序没有限制
)3)条件项目)列出对此输入的条件的可能取值，尽可能真假值
)4)行动项目)列出取输入项目各种值时应采取的行动
动作项和条件项表示取条件项的各种值时应该采取的动作，在判定表中，规则是贯穿条件项和动作项的列，可以对每个合法输入组合的规则设计测试用例进行测试
判定表设计过程判定表测试用例的设计步骤如下。
(1)决定规则的个数
根据输入的条件数据计算规则的个数，如果有n个条件，则规则共有2^N个。 n为3时，规则数为8个** (这里的公式很多学生理解错了。 因为这里的2实际上只输入了条件是0还是1的真伪值。 如果输入的条件为5种，则此2为5。 **
)2)列出所有条件桩和动作桩
条件桩是影响结果的条件(输入的所有条件)，动作桩是所有条件组合的结果(系统对应所有结果)
)3)填写条件项和动作项
要显示每个条件项，通常使用1和0的显示。 如果选择此条件，则使用1；如果未选择，则使用0。 必须显示条件项中所有条件的组合，根据条件情况确定操作项，然后显示操作项
)4)相似规则的简化、整合
简化判定表，就是综合类似规则来减少测试用例，当然也会牺牲测试用例的充分性。
例如，如果只有一个输入不同，则表示输出相同，输入不影响输出。 因此，我们将这两列合并为一列，并简化合并规则，如图所示。
只有一个输入条件不同，不影响结果
条件桩条件项条件项1YY2NN3YN动作桩动作项动作项1XX合并后：
条件桩条件项1Y2N3——动作桩动作项1x(5)将最后得到的判定表的各规则转换为测试用例
例(收费站功能要求)根据车牌颜色和有无ETC判断是否收费的车牌颜色是蓝黄绿黄绿双重拼法。 白色和黑色等颜色不收费
根据以上说明得到的输入条件有车牌颜色和是否安装ETC两个；
输出的条件(动作桩)有一个。 如何收费)不按成本收费和折扣收费收费
步骤1 :确定规则的数量
因为有两个输入条件，所以各条件的输入只有yes和no，规则数为2^2=4(这里实际上进行了简化的判定表。 车牌颜色的输入实际上有很多，但对于是否影响收费结果，只要判断是否是收费车牌就可以了，所以输入车牌的条件项目被简化为两种。 以下条件桩所示)
步骤2 :列出所有条件桩和动作桩
出条件桩1 :牌照是否收费： 0不收费，1收费
条件桩ETC:0是否安装，1是否安装
有一个动作桩。 0免费，1成本费用，2折费用
第三步：填写条件项目和行动项目
如下表所示
编号1234条件10011条件20101操作10012步骤4 :简化、合并类似规则
综上所述，如果车牌颜色是免费的，则是否安装ETC并不影响最后是否收费，因此合并后的判定表如下表所示
编号123条件1011条件2——01动作1012步骤5 :将各规则转换为测试用例
1 )输入免费牌照颜色，检查是否收费
2 )输入收费牌照，未安装ETC，按成本检查是否收费
3 )输入收费牌照，安装ETC，检查是否打折收费
用判定表的优缺点判定表设计测试用例有以下优点。
)1)充分考虑输入条件之间的组合，避免漏诊
)设计过程种类分析输入条件之间的约束关系，避免出现无效用例，提高测试用例的有效性
)3)设计时同时输出各测试项目的期待结果
使用判定表设计测试用例有以下缺点。
(1)被测定特性输入多时，判定表变得庞大
)输入条件之间的约束不能有效区分当前组合是否合理，产生不必要的组合条件
)3)规则整合流程种类存在猜测遗漏的风险。 虽然某个输入条件与输出接口无关，但在软件设计上，内部对该条件采取了不同的程序分支()最常见的是PC侧的商城和APP侧的商城，逻辑相同，但内部采取了不同的分支处理) )
在判定表中发现的错误，在测试一次订单生成规则时，必须选择会员等级和是否收到自己提取的对应运费。 (等级越高，下单后选择快递寄送的运费就越多。 )另外，条件是会员是否购买了运费卡，购买后免费送货。 测试中使用判定表设计了用例，但测试中每个会员等级都有用例，因此发现开发遗漏并根据等级退还了运费
个人心得判定表有多个输入条件，输出结果有多个需求，设计过程中有关键(对于数学逻辑掌握不好的同学，可以按照步骤一步步设计，对于逻辑掌握好的同学，可以一步到位生成简化后的判定表)，判定表非常强大，但我们的bug多在用例中
之外，比如上述的收费站收费举例，虽然最后简化成了3条用例，但是往往BUG的发现会在（输入免费车牌，同时输入安装了ETC这个用例以外的场景）因为我们的开发可能写的代码是先判断是否安装了ETC，然后安装了就直接算折扣，跳过了车牌校验。那么如何测试到这种情况，由于我们的用例简化后很少，所以测试过程中我们可以进行探索性测试，即思考开发是如何实现该功能的，是否用例上还有遗漏的可能性，进行补充测试。那对于用例多的时候，测试时间被压缩又如何处理？那就要根据用例的优先级，牺牲一定的测试质量，优先保证功能达到上线标准去进行测试了