的某一天，小w发现过去两天输入法小米普通定制版出现大量用户被误开启灵犀功能，且线上灵犀崩溃问题激增。一阵“惊吓”过后，小w赶紧找开发沟通，问题很快得到了解决。由于测试范围遗漏导致线上事故，这使得初入测试职场的小w愧疚万分，他因此进行了深刻的总结和反思并在组内分享，让测试小白——我受益匪浅，从中get到了一项新的测试用例设计方法：判定表法。今天我们通过实际案例一起学习下这个方法吧~
一、概念
判定表是分析和表达多种输入条件下系统执行不同动作的工具，它可以把复杂的逻辑关系和多种条件组合的情况表达的既准确又明确。判定表通常由四个部分组成，如下图：
1)条件桩：列出了系统的所有输入，次序无关紧要
2)动作桩：列出了系统可能采取的操作，操作的排列顺序没有约束
3)条件项：列出针对它左列输入的取值，在所有可能情况下的真假值
4)动作项：列出在输入项的各种取值情况下应该采取的动作
5)动作项和条件项一起，指出了在条件项的各种取值情况下应该采取的动作，在判定表中贯穿条件项和动作项的一列就是一条规则，可以针对每个合法输入组合的规则设计用例进行测试
二、案例背景
三、判定表法在该案例中的具体实施步骤
1)标识输入和输出
逐项分析测试子项的测试规格，找出其中的输入和输出并标识出来。
输入：fr=android_oem_xiaomi_sogou、build= Build_103012_0908、lingxi_version=0
输出：下发灵犀开关
2)构造判定表
将标识的输入填入条件桩部分，将标识的输出填入动作桩部分。条件项部分的列数为2n(n为输入数)。
3)逐步分析条件项组合，填入其动作项
分析每列的条件项取值情况，根据输入和输出逻辑关系，得到该列的输出值，并填入到该列动作项，得到一条规则。如果该列条件项取值组合不合法，则动作项填入“X”。
4)生成测试用例
简化后的判定表的每一列可以设计为一个测试用例，它的输入和输出都已经非常明确。生成后的测试用例为：
①当fr=android_oem_xiaomi_sogou且build =Build_103012_0908且lingxi_version=0时，下发灵犀开关；
②当fr=android_oem_xiaomi_sogou且build =Build_103012_0908，但lingxi_version!=0时，不下发灵犀开关；
③当fr=android_oem_xiaomi_sogou且lingxi_version=0，但build!=Build_103012_0908时，不下发灵犀开关(注：在实际测试中，验证3这条case时使用build=纯净版build或者build=泛灵犀版build，因纯净版build及泛灵犀版build不等于Build_103012_0908且这两个版本含有灵犀代码。)；
④当fr=android_oem_xiaomi_sogou，但build!=Build_103012_0908且lingxi_version!=0时，不下发灵犀开关；
⑤当lingxi_version=0，但fr!=android_oem_xiaomi_sogou且build !=Build_103012_0908时，下发灵犀开关；
⑥当fr!=android_oem_xiaomi_sogou且build !=Build_103012_0908且lingxi_version!=0时，不下发灵犀开关。
四、总结
判定表的优点：
1) 充分考虑了输入条件简的组合，对组合情况覆盖充分；
2) 最终每个用例覆盖多种输入情况，有利于提高测试效率；
3) 设计过程中，对输入条件间的约束关系做了考虑，避免了无效用例，用例的有效性高；
4) 能同时得出每个测试项目的预期输出。
判定表的缺点：
1) 当被测试特性输入较多时，会造成判定表规格庞大；
2) 输入之间的约束条件不能有效区分输入是否确实需要进行组合测试，会造成不需要组合测试的输入做了组合，从而产生用例冗余。
