五、判定表驱动法

1、判定表驱动法概述

判定表也称为决策表，其实质就是一种逻辑表。在程序设计发展初期，判定表就已经被当作程序开发的辅助工具了，帮助开发人员整理开发模式和流程，因为它可以把复杂的逻辑关系和多种条件组合的情况表达的既具体又明确，利用判定表可以设计出完整的测试用例集合。

2、判定驱动法 —— 引例

为了让大家明白什么是判定表，下面通过一个“图书阅读指南”来制作一个判定表，图书阅读指南指明了图书阅读过程中可能出现的状况，以及针对各种情况给读者的建议。

（1）在图书阅读过程中可能会出现3种情况：

• 是否疲倦。
• 是否对内容感兴趣。
• 对书中的内容是否感到糊涂。

如果回答是肯定的，则使用“Y”标记；

如果回答是否定的，则使用“N”标记。

那么这3种情况可以有2³=8种组合，针对这8种组合。

（2）阅读指南给读者提供了4条建议：

• 回到本章开头重读。
• 继续读下去。
• 跳到下一章去读。
• 停止阅读并休息。

（3）针对以上分析，得出以下图书阅读指南判定表。

（4）在实际测试中，条件桩往往很多，而且每个条件桩都有真假两个条件项，有n个条件桩的判定表就会有2ⁿ种条件规则，如果每条规则都设计一个测试用例，不仅工作量大，而且有些工作量可能是重复的无意义的。例如在“图书阅读指南”中，第1、2条规则，第1条规则取值为：Y、Y、Y，执行结果为“停止阅读并休息”；第2条规则取值为：Y、Y、N，执行结果也是为“停止阅读并休息”；对于这两条规则来说，前两个问题的取值相同，执行结果一样。

这些不影响结果取值的问题称为无关条件项，用“-”表示。忽略无关条件项，可以将两条规则合并。

合并规则需要满足如下两个条件：①两条规则采取的动作相同；②两条规则的条件项取值相似。

（5）根据合并规则，可以将“图书阅读指南”判定表合并。

3、判定表结构

判定表是把作为条件的所有输入的各种组合值以及对应的输出值都罗列出来而形成的表格，判定表由4个部分组成，判定表结构如下：

其中每一列称为一个规则。判定表的4个部分分别为：

• 条件桩：列出问题的所有条件，除了某些问题对条件的先后次序有要求之外，通常决策表中所列条件的先后次序都无关紧要。
• 条件项：条件项就是条件桩的所有可能取值。
• 动作桩：动作桩就是问题可能采取的操作，这些操作一般没有先后次序之分。
• 动作项：指出在条件项的各组取值情况下应采取的动作。

在判定表中，任何一个条件组合的特定取值及其相应要执行的操作称为一条规则，即判定表中的每一列就是一条规则，每一列都可以设计一个测试用例，根据判定表设计测试用例就不会有所遗漏。

4、判定表的建立步骤

• 确定规则个数（n个条件相应的有2ⁿ条规则）。
• 列出所有的条件桩和动作桩。
• 填入条件项。
• 填入动作项，制定初始判定表。
• 简化，合并相似规则或相同动作。

5、使用判定表设计测试用例的条件

• 规格说明以判定表的形式给出，或很容易转换成判定表。
• 条件的排列顺序不影响执行哪些操作。
• 规则的排列顺序不影响执行哪些操作。
• 当某一规则的条件已经满足，并确定要执行的操作后，不必检验别的规则。
• 如果某一规则要执行多个操作，这些操作的执行顺序无关紧要。

6、案例：工资发放

某公司的薪资管理制度如下：员工工资分为年薪制与月薪制两种，员工的错误定位包括普通错误与严重错误两种，如果是年薪制的员工，犯普通错误扣款2%，犯严重错误扣款4%；如果是月薪制的员工，犯普通错误扣款4%，犯严重错误扣款8%。该公司编写了一款软件用于员工工资计算发放，现在要对该软件进行测试。

对公司员工工资管理进行分析，可得出员工工资由4个因素决定：年薪、月薪、普通错误、严重错误。其中，年薪与月薪不可能同时并存，但普通错误与严重错误可以并存。

员工最终扣款结果有7种：未扣款、扣款2%、扣款4%、扣款6%（2%+4%）、扣款4%、扣款8%、扣款12%（4%+8%）。

采用判定表驱动法设计该软件的测试用例。

具体解析如下：

（1）分析员工工资的原因和结果：

（2）有4个原因，每个原因有“Y”和“N”两个取值，理论上可以组成2⁴=16种规则，但是c1与c2不能同时并存，因此有2³=8种规则。得出员工工资判定表如下：

（3）最终得出员工工资测试用例表：

六、正交实验设计法

1、正交实验设计法概述

正交实验设计法（Orthogonal experimental design）是指从大量的实验点中挑选出适量的、有代表性的点，依据Glois理论导出“正交表”，从而合理的安排实验的一种实验设计方法。

2、正交实验设计法三个关键因素

• 指标：判断实验结果优劣的标准。
• 因子：因子也称为因素，是指所有影响实验指标的条件。
• 因子的状态：因子的状态也叫因子的水平，它指的是因子变量的取值。

3、利用正交实验法设计测试用例的步骤

• 提取因子，构造因子状态表
• 加权筛选，简化因子状态表
• 构建正交表，设计测试用例

接下来对这三个步骤进行一一解析。

（1）举个栗子（步骤一）：

提取因子，构造因子状态表—— 即分析软件的规格需求说明得到影响软件功能的因子，确定因子可以有哪些取值，即确定因子的状态。

例如，某一软件的运行受到操作系统和数据库的影响，因此影响其运行是否成功的因子有操作系统和数据库两个，而操作系统有Windows、Linux、Mac三个取值，数据库有MySQL、MongoDB、Oracle三个取值，因此操作系统的因子状态为3，数据库因子状态为3。得到如下因子-状态表：

（2）举个栗子（步骤二）：

加权筛选，简化因子状态表 —— 在实际软件测试中，软件的因子及因子的状态会有很多，每个因子及其状态对软件的作用也大不相同，如果把这些因子及状态都划分到因子-状态表中，最后生成的测试用例会相当庞大，从而影响软件测试的效率。因此需要根据因子及状态的重要程度进行加权筛选，选出重要的因子与状态，简化因子-状态表。

（3）举个栗子（步骤三）：

构建正交表，设计测试用例 —— 正交表的表示形式为 L_n(t^c) 来表示。

• L表示正交表。
• n为正交表的行数，正交表的每一行可以设计一个测试用例，因此行数n也表示可以设计的测试用例的数目。
• c表示正交实验的因子数目，即正交表的列数，因此正交表是一个n行c列的表。
• t称为水平数，表示每个因子能够取得的最大值，即因子有多少个状态。
• 在行数为n(n为正整数)的正交表中，行数n（试验次数）=∑（每列水平数t-1）+1。如： ①L₈(2⁷)，n=7×(2-1)+1=8；②L₄(2³)，n=3×(2-1)+1=4。

下面举出两个例子辅助理解：例1：L₄(2³) 是最简单的正交表，它表示该实验有3个因子，每个因子有两个状态，可以做4次实验，如果用0和1表示每个因子的两种状态，则该正交表就是一个4行3列的表。正交表如下图所示： 例2：在实际软件测试中，大多数情况下，软件有多个因子，每个因子的状态数目都不相同，即各列的水平数不等，这样的正交表称为混合正交表，如L₈(2⁴ + 4¹) ，这个正交表表示有4个因子有2种状态，有1个因子有4种状态。 那么正交表的行数为 n= ∑（每列水平数t-1）+ 1 = (2-1)×4 + (4-1)×1 + 1 = 8，这个n值的计算如果发生在大型项目时往往是很难计算的。 所以，混合正交表往往难以确定测试用例的数目，即n的值。因此，在这种情况下，可以登录正交表的一些权威网站，查询n值，下面给大家提供一个正交表查询网站， 在这里，可以查询到不同因子数、不同水平数的正交表的n值。最终得出，该混合正交表如下图所示：

4、正交表的特点

正交表最大的特点是取点均匀分散、齐整可比，每一列中每种数字出现的次数都相等，即每种状态的取值次数相等。

5、总结

写到这里，对正交实验设计法做个小结：

• 在正交表中，每个因子的每个水平与另一个因子的各水平都“交互”一次，这就是正交性，它保证了实验点均匀分散在因子与水平的组合之中，因此具有很强的代表性。
• 对于受多因子多水平影响的软件，正交实验法可以高效适量的生成测试用例，减少测试工作量，并且利用正交实验法得到的测试用例具有一定的覆盖度，检错率可达50%以上。
• 正交实验法虽然好用，但在选择正交表时要注意先要确定实验因子、状态及它们之间的交互作用，选择合适的正交表，同时还要考虑实验的精度要求、费用、时长等因素。

6、案例：微信Web页面运行环境正交试验设计

微信是一款手机App软件，但它也有web版微信可以登录，如果要测试微信web页面运行环境，需要考虑多种因素，在众多的因素中，我们可以选出几个影响比较大的因素，如服务器、操作系统，插件和浏览器。利用正交实验设计法设计该软件的测试用例。

具体解析如下：（1）提取因子，构造因子状态表

• 对于选取出的4个影响因素，每个因素又有不同的取值，同样，在每个因素的多个值中，可以选出几个比较重要的值。如：

• 服务器：IIS、Apache、Jetty；
  
• 操作系统：Windows7、Windows10、Mac；
  
• 插件：无、小程序、微信插件；
  
• 浏览器：IE11、Chrome、FireFox；
  

• 构造的因子状态表如下：
  

（2）加权筛选，简化因子状态表

• 微信web版运行环境正交实验中有4个因子：服务器、操作系统、插件、浏览器，每个因子又有3个水平，因此该正交表是一个4因子3水平正交表。
• 所以正交表的行数为 `n= ∑（每列水平数t-1）+ 1 = (3-1)×4 + 1 =

9`，因此正交表的表示形式为L₉(3⁴)。

• 得出n=9后，查表可得，简化后的因子状态表如下：

（3）构建正交表，设计测试用例

• 将因子、状态映射到正交表，可生成具体的测试用例，具体如下表：

七、场景法

1、设计思想

现在的软件几乎都是由事件来触发的，事情触发便形成了场景，而同一事件不同的触发顺序和处理结果就形成了事件流。

2、场景的构成要素

场景可以看成是基本流与备选流的集合。用例的场景用来描述流经用例的路径，从用例的开始到结束遍历这条路径上所有的基本流和备选流。

（1）基本流

基本事件流，从系统某个初始状态开始，经一系列状态后，到达最终状态的一个业务流程，并且是最主要、最基本的一个业务流程（无任何差错，程序从开始直接到执行结束）。

（2）场景流

备选事件流，以基本流为基础，在基本流所经过的每个判定节点处满足不同的触发条件而导致的其他事件流。

3、基本流和备选流的场景说明

先用一张图来描述基本流和备选流的流程。

从上图可以看出，图中经过用例的每条路径都用基本流和备选流来表示。

基本流：采用直黑线表示，是经过用例的最简单的路径。

备选流：采用不同色彩表示，一个备选流可能从基本流开始，在某个特定条件下执行，然后重新加入基本流中（如备选流1和3）；也可能起源于另一个备选流（如备选流2），或者终止用例而不再重新加入到某个流（如备选流2和4）。

根据图中每条经过的可能路径，从基本流开始，再经过基本流、备选流的综合，可以确定不同的用例场景，如下： 基于以上例子，可以得出以下结论：基本流只有一个，而备选流的数目则取决于基本流上判定节点的数目与事务分析的颗粒度，颗粒度越细，考虑越周全，得到的备选流数目就越多，相应的测试工作量就越大。

4、设计测试用例

场景法设计测试用例的基本步骤如下：

（1） 根据需求规格说明，描述出程序的基本流及各项备选流。

（2） 根据基本流和各项备选流生成不同的场景。

（3） 对每一个场景生成相应的测试用例。

（4） 对生成的所有测试用例重新复审，去掉多余的测试用例。测试用例确定后，对每一个测试用例确定测试数据值。

5、总结

写到这里，对场景法做个小结：

• 场景法以事件流和场景为核心，又被称为业务流程测试法，要求测试人员使用场景法设计测试用例时把自己当成最终用户，尽可能真实地模拟用户在使用此软件时的操作情形。
• 在测试过程中，测试人员需要模拟两个方面的业务：正确的操作流程和可能出现的错误操作。
• 它适用于业务比较复杂的软件系统测试。

6、案例：在线购物案例

有一个在线购物的实例：用户进入一个在线购物网站进行购物，选购物品后，进行在线购买，这时需要使用账号登录；登录成功后，进行付钱交易；交易成功后，生成订购单；完成整个购物过程。请使用场景法设计测试用例。

案例解析如下：

（1）确定基本流和备选流

• 基本流：登录在线购物网站，选择物品，登录账号，付钱交易，生成订购单。
• 备选流1：账号不存在。
• 备选流2：密码错误。
• 备选流3：货物库存不足。
• 备选流4：账号余额不足。

（2）根据基本流和备选流来确定场景，如下表：

表 购物系统场景表

（3）根据每一个场景，设计需要的测试用例

【解析】

可以采用矩阵或判定表来确定和管理测试用例，下面介绍一种通用的格式，其中各行代表各个测试用例，而各列则代表测试用例的信息。 在矩阵中，

• V（有效）用于表明这个条件必须是VALID（有效的）才可执行基本流；
• I（无效）用于表明这种条件下将激活所需备选流；
• N/A(不适用)表明这个条件不适用于测试用例。

购物系统场景矩阵见下表：

表 购物系统场景矩阵

（4）设计具体的测试用例数据（假设所购物品单价为30元）

表 购物系统具体测试用例

八、功能图法

功能图法目前的使用频率较低，此处不做细讲……

九、黑盒测试方法策略总结

写到这里，对上面八大黑盒测试方法做个小结。

1、各种测试方法选择的综合策略

（1）首先进行等价类划分，包括输入条件和输出条件的等价划分，将无限测试变成有限测试，这是减少工作量和提高测试效率最有效的方法。

（2）在任何情况下都必须使用边界值分析方法。经验表明，用这种方法设计出的测试用例发现程序错误的能力最强。

（3）可以用错误推测法追加一些测试用例，这需要依靠测试工程师的智慧和经验。

（4）对照程序逻辑，检查已设计出的测试用例的逻辑覆盖程度。如果没有达到要求的覆盖标准，应当再补充足够的测试用例。

（5） 如果程序的功能说明中含有输入条件的组合情况，则一开始就可选用因果图法和判定表。

（6）对于参数配置类的软件，要用正交试验法选择较少的组合方式达到最佳效果。

（7） 对于业务流清晰的软件，可以使用场景贯穿测试，再综合使用各种测试方法。

2、黑盒测试的优缺点

（1）优点：①对较大的代码单元来说，黑盒测试比白盒测试的效率高 ，测试人员不需要了解实现的细节，包括特定的编程语言；②测试人员和编程人员是相互独立的，从用户的角度进行测试，很容易被接受和理解，有助于暴露任何与规格不一致或者歧异的地方，测试用例可以在规格完成后马上进行。

（2）缺点：不能测试程序内部特定部位，比如程序未执行的代码，这些代码得不到测试，则无法发现错误。若没有清晰的和简明的规格，测试用例很难被设计，不易进行充分性测试。

十、写在最后

黑盒测试相较于白盒测试来说比较简单，不需要了解程序内部的代码，与软件的内部实现无关；从用户角度出发，能很容易的知道用户会使用到哪些功能，会遇到哪些问题；并且是基于软件开发文档做的相关测试，能较清楚地了解软件实现了文档中的哪些功能。

八大典型的黑盒测试方法讲解到这里就结束啦！如有不理解或者有误的地方欢迎评论区或私聊我交流~