上一次分享，我们讲了测试分析工程方法，这一期和大家分享一下测试设计工程方法。

测试设计技术按是否需要参考内部结构可分为黑盒技术和白盒技术，黑盒技术依据对测试文档进行分析或者基于开发人员、测试人员和用户的经验得出或选择测试条件或测试用例，无论是功能性的用例还是非功能性的用例，都不需要参考组件或系统的内部结构。而白盒技术则需要对组件或系统结构进行分析。

测试技术的选择需要考虑下面的几个因素：系统类型、法律法规标准、客户或合同的需求、风险级别、风险类型、测试目标、文档的可用性、测试人员的技能水平 、时间和成本的预算、开发生命周期、用例模型和以前发现缺陷类型的经验等。

下面主要介绍几种常见的基于规格说明的黑盒测试设计技术，这些技术的共同特点是：使用正式或非正式的模型来描述需要解决的问题，根据这些模型可以系统地导出测试用例。

这里介绍几种常见的方法等价类、边界值、判定表、用例测试。

1、等价类划分法

通常情况下，考虑测试输入数据所有可能的组合是不现实的，怎么用较少的数据达到相同的测试效果呢，等价类划分方法可以实现这个目的。先看下等价类划分定义：将软件或系统的输入（或输出）分成不同的组，对于同一个组的输入，软件或系统应该有相似的表现行为，就好像系统是以相同的方式对这些输入值进行处理。等价类是输入条件的一个子集合，该输入集合中的数据对于揭示程序中的错误是等价的。

等价类又分为有效等价类和无效等价类，有效等价类代表对程序有效的输入，而无效等价类则是其他任何可能的输入（即不正确的输入值）。设计用例时要包含有效等价类和无效等价类，来测试被测系统既能正确处理有效输入，也能正确处理无效输入。

等价类划分原则：

原则1.如果输入条件规定了一个取值范围，那么就应该确定一个有效等价类以及两个无效等价类。

如月份取值在1~12之间，由此可确定一个有效等价类即月份在1~12之间，和两个无效等价类，即月份取值小于1及月份取值大于12。

原则2.规定了输入条件必须如何的情况下可以确定一个有效等价类和一个无效等价类。

如输入值必须大于0，则有效等价类为输入值大于0 ，无效等价类为输入值小于或者等于0。

原则3.在输入数据是一个bool常量的情况下，可以确定一个有效等价类和一个无效等价类。

原则4.在规定了输入数据由n个值构成的情况下，并要求定其中的每个值进行测试时，可以确定n个有效等价类和一个无效等价类。

原则5.在规定了输入数据冰箱最受的规则的情况下，可以确定一个有效等价类和若干个无效等价类（从不同角度违反规则）。

原则6.在确知已划分的等价类中各元素在程序处理中的方式不同的情况下,则应再将该等价类进一步的划分为更小的等价类。

用等价类设计测试用例步骤如下：

1）为每一个等价类规定一个唯一的编号

2）设计一个新的测试用例,使其尽可能多地覆盖尚未被覆盖地有效等价类,重复这一步，直到所有的有效等价类都被覆盖为止

3）设计一个新的测试用例,使其仅覆盖一个尚未被覆盖的无效等价类,重复这一步，直到所有的无效等价类都被覆盖为止。

用等价类方法设计测试用例举例：带薪年假计算方法，职工累计工作满1年不满10年的，年休假为5天；已满10年不满20年的，年休假为10天；已满20年的，年休假为15天。劳动合同法规定职工请事假累计20天及以上且单位按照规定不扣工资的，取消本年度年休假，20天内的按实际年休假发放。假设工作最长年限为60年。

第一步：划分有效等价类和无效等价类，根据员工不同服务年限，可得到如下的等价类

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

第三步：为无效等价类设计测试用例

经过以上三步后，基于等价类的用例设计已经结束，覆盖了所有的有效等价类和无效等价类。

2、边界值分析

软件本身具备复杂性、一致性、不可见性，因此程序的缺陷经常在等价类的边界和接口处被发现，所以在等价类分析后还应该对于每个测试的变量加上边界值分析。

对于测试的每个输入，都应在其定义的边界附加测试用例，一般边界需要考虑略低于边界值、边界值、略高于边界值等几种情况。

针对计算年假问题中的有效等价类1=

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

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

使用判定表的步骤是：

1）识别条件和动作

2）识别规则：至少有一个行动项，至少有一个条件项

3）引入不关心的因素“-”，减少用例数目（不关心项：条件是不相关的或不适用的，不关心项需谨慎使用）

4）每个规则即为一个测试用例

如何判断判定表是冗余或不一致呢？

1）n个条件下最多有2的n次方个规则

2）为每个规则引入一个规则计数器

若规则内包含不关心项，则计数器值为1。否则，出现m个不关心项，则计数器的值为2的m次方

3）所有规则计数器之和若等于2的n次方，则判定表是完整的，否则可能存在冗余（大于2的n次方）或不一致（小于2的n次方）。

如上面判定表，我们可以判断下是否冗余或不一致，引入计数器count，计数器之和等于8等于2的3次方，所以这个判定表不存在冗余或不一致现象。

判定表由于条件、动作（结果）比较清晰，比较容易查漏补缺，在测试设计中非常常用。存在的不足是条件间或动作间的具体的先后顺序或逻辑关系在表中并没有体现，需要我们在生成规则时根据业务逻辑进行针对性的判断。

4、用例测试／用户场景测试

用例测试也称为用户场景测试，分析用户是怎么和系统打交道的，典型的行为有哪些，会出现什么结果。针对用户典型的行为模式形成的测试场景，把最可能发生的场景称为主场景，由主场景得到的测试用例，是发现系统在实际应用中存在缺陷的最有效的方式。

测试人员的测试就是代表用户进行测试，从用户角度、用户的行为模式等进行测试，所以用例测试大家有意无意的都在使用了，只是主场景会考虑的较多，分支场景和异常场景考虑的相对少，有意识的加强即可。

按上图可以组合出多个不同的测试场景：

测试场景1：主场景
测试场景2：主场景 分支场景1
测试场景3：主场景 分支场景2 分支场景4
测试场景4：主场景 分支场景3
测试场景5：主场景 分支场景1 分支场景3
测试场景6：主场景 分支场景2 分支场景1 分支场景3
测试场景7：主场景 分支场景5
测试场景8：主场景 分支场景2 分支场景5
测试场景9：主场景 分支场景2 分支场景4
测试场景10：主场景 分支场景5　　

设计用例设计步骤

1）分析需求，画出流程图，确定出软件的主场景和各分支场景。

2）依据主场景和各分支场景，生成不同的测试场景。判断生成的测试场景是否完备有两个标准，覆盖每个场景至少一次，覆盖每一种场景序列至少一次。

3）针对生成的各测试场景，设计相应的测试用例。

4）重新审核生成的测试用例，去掉多余的部分，并针对最终确定出的测试用例，设计测试数据。