“测试经验说”系列之如何进行测试分析设计？（下）

作者简介Lilian，TestBird自动化测试高级专家，16年测试工作经验，主持过多个产品的测试验证、测试技术能力的规划和实施落地。主导多项测试技术：组件测试、敏捷测试、测试能力提升、测试评估的方案和成功落地。擅长测试分析设计、测试管理、敏捷测试、探索性测试、基于模型的测试、测试过程改进、缺陷根因分析、测试评估等。上一次分享，我们讲了测试分析工程方法，这一期和大家分享一下测试设计工程方法。

第二步：为有效等价类设计测试用例

第三步：为无效等价类设计测试用例经过以上三步后，基于等价类的用例设计已经结束，覆盖了所有的有效等价类和无效等价类。2、边界值分析软件本身具备复杂性、一致性、不可见性，因此程序的缺陷经常在等价类的边界和接口处被发现，所以在等价类分析后还应该对于每个测试的变量加上边界值分析。

判定表通常由五个部分组成，条件桩、动作桩、条件项、动作项以及规则。如下：

条件桩列出了问题的所有条件（输入）。动作桩列出了可能采取的操作／行动（输出）。条件项针对条件桩的取值，在所有可能情况下的真假值。动作项是在条件项的各种取值下，应该采取的动作。规则是在一个条件组合的特定取值及其相应要执行的操作，在判定表中贯穿条件项和动作的一列就是一条规则。

如何判断判定表是冗余或不一致呢？1）n个条件下最多有2的n次方个规则2）为每个规则引入一个规则计数器若规则内包含不关心项，则计数器值为1。否则，出现m个不关心项，则计数器的值为2的m次方3）所有规则计数器之和若等于2的n次方，则判定表是完整的，否则可能存在冗余（大于2的n次方）或不一致（小于2的n次方）。

判定表由于条件、动作（结果）比较清晰，比较容易查漏补缺，在测试设计中非常常用。存在的不足是条件间或动作间的具体的先后顺序或逻辑关系在表中并没有体现，需要我们在生成规则时根据业务逻辑进行针对性的判断。4、用例测试／用户场景测试用例测试也称为用户场景测试，分析用户是怎么和系统打交道的，典型的行为有哪些，会出现什么结果。