【软件测试基础】黑盒测试（知识点 + 习题 + 答案

《 软件测试基础持续更新中》

对于黑盒测试这一章，等价类划分、边界值测试、决策表、场景法，这四种是最容易出大题的，其他几种考察频率很低。下述的一些例题只是经典例题，掌握方法后，还要多加练习！

目录

3.1 等价类划分（重要）

【经典例题】三角形问题的等价类划分： 

3.2 边界值测试（重要）

【经典例题】登录界面

3.3 组合测试

3.4 决策表（重要）

【经典例题】订购单的检查

3.5 因果图

3.6 场景法（重要）

 【经典例题】围绕ATM机取款功能设计测试用例

3.7 状态转换法

3.8 错误猜测法

3.9 用例方法使用总结

---

黑盒测试，又称为功能测试或数据驱动测试，是把测试对象当作看不见内部的黑盒。在完全不考虑程序内容结构和处理过程的情况下，测试者仅根据程序功能的需求规范考虑确定测试用例和推断测试结果的正确性。

3.1 等价类划分（重要）

划分等价类：根据需求的输入或者输出划分有效等价类 和 无效等价类。

测试用例设计步骤：

1. 划分等价类后，建立等价类表，并为每一个等价类规定一个唯一的编号
2. 设计一个新用例，使它能够尽量多覆盖尚未覆盖的有效等价类。 重复该步骤，直到所有有效等价类均被用例所覆盖
3. 设计一个新用例，使它仅覆盖一个尚未覆盖的无效等价类。重复该步骤，直到所有的无效等价类均被用例所覆盖 

【经典例题】三角形问题的等价类划分： 

测试背景：
某程序规定："输入三个整数 a 、 b 、 c 分别作为三边的边长构成三角形。通过程序判定所构成的三角形的类型，当此三角形为一般三角形、等腰三角形及等边三角形时，分别作…处理 "。用等价类划分方法为该程序进行测试用例设计。

分析题目中给出和隐含的对输入条件的要求：

（1）整数　　（2）3个数　　（3）非零数　　（4）正数　　（5）两边之和大于第三边　　（6）等腰　　（7）等边

如果 a 、 b 、 c 满足条件（ 1 ） ~ （ 4 ），则输出下列四种情况之一：

1)如果不满足条件（5），则程序输出为 " 不能构成三角形 " 。
2)如果三条边相等即满足条件（7），则程序输出为 " 等边三角形 " 。
3)如果只有两条边相等、即满足条件（6），则程序输出为 " 等腰三角形 " 。
4)如果三条边都不相等，则程序输出为 " 一般三角形 " 。

（1）列出等价类表并编号

（2） 设计覆盖有效等价类的测试用例

（3）设计覆盖无效等价类的测试用例

---

3.2 边界值测试（重要）

边界值测试是一种最基本、最简单的黑盒测试方法，通常可作为等价类测试的补充。刚好等于、刚好大于、刚好小于。

● 如果输入条件规定了值的范围，则应该取刚达到这个范围的边界值，以及刚刚超过这个范围边界的值作为测试输入数据
● 如果输入条件规定了值的个数，则用最大个数、最小个数、比最大个数多1、比最小个数少1的数做为测试数据
● 如果输入域是有序集合(如有序表、顺序文件等)，则选取集合中特定次序的数据作为边界，如第一个或最后一个数据等
● 如果程序用了一个内部结构，应该选取这个内部数据结构的边界值作为测试用例；
● 分析规格说明，找出其他可能的边界条件

【经典例题】登录界面

以下是163邮箱的新用户注册页面：https://mail.163.com/register/index.htm?from=ntes_nav&regPage=163#/normal

注意是普通注册，见下图：

请用等价类和边界值对该注册功能设计用例，要求写出等价类划分的步骤

答案解析：

【1】划分等价类后，建立等价类表： （必须的不能少，划分的更加详细也没事，答案不唯一）

【2】 设计测试用例：

因为需要考虑边界值测试，所以对于邮箱地址，需要测试字符个数为：6、18、5、19的用例数据。对于密码需要考虑字符个数为：8、16、7、17的数据。

用例要求：一个用例可覆盖多个有效等价类  ，但一个用例只覆盖一个无效等价类 。

3.3 组合测试

目的：为组合爆炸情况提供一种相对合理的解决方案，在保证错误检出率的前提下采用较少的测试用例。

组合测试的实施步骤：

1、根据测试目标，识别出所需测试的软件功能，以及影响被测软件功能的参数。

2、依据步骤1的结果，识别每个参数的取值 范围。取值范围应为有限个离散取值。如果 某参数的取值范围不符合要求，则采用其他 测试技术对其进行离散化处理。

3、依据步骤1的结果识别出参数间的约束。 分析各参数间交互作用的强度，设定指导测试用例设计的组合强度。

4、根据步骤3中设定的组合强度，采用对应组合测试方法，生成与组合强度相符的测试 覆盖项。

5、依据步骤4中的测试覆盖项生成测试用例，直到每个测试覆盖项都包含在至少一个 测试用例中。

---

常见的组合强度包括：单一选择、基本选择、成对组合、全组合和K强度组合等。

我们使用某组织的旅行选项作为案例，来逐一说明不同的组合强度对用例设计的影响。 某组织为其员工到国内主要城市出差而记录了他们的旅行选项，分为目的地、舱位、座位三个分类的单选项。这些单选项的内容如表所示。

单选项	可选值
目的地	北京、上海、广州
舱位	头等舱、公务舱、经济舱
座位	靠过道、靠窗

【1】单一选择：被测软件中的所有参数取值范围的任意可能取值至少被一个测试用例覆盖。

对于单一选择测试，本案例只需要3个测试用例即可达到覆盖：

测试用例编号	输入值			预期结果
	目的地	舱位	座位
1	北京	头等舱	靠过道	预订成功
2	上海	公务舱	靠窗	预订成功
3	广州	经济舱	靠过道	预订成功

 【2】基本选择：被测软件中，对于任意一个参数的N个取值 ，存在N条测试用例覆盖这N个取值，且其他参数的取值相同。

对于基本选择测试，测试覆盖项是通过选择每个参数的“基本选择” 来确定的。基本选择可以从操作手册、用例的基本路径或者等价类划分中得到的测试覆盖项中挑选。在本案例中，操作手册中给出了一个基本选择：上海、经济舱、靠窗 ：

基本选择的测试用例如下表：

测试用例编号	输入值			预期结果
	目的地	舱位	座位
1	上海	经济舱	靠窗	预订成功
2	北京	经济舱	靠窗	预订成功
3	广州	经济舱	靠窗	预订成功
4	上海	头等舱	靠窗	预订成功
5	上海	公务舱	靠窗	预订成功
6	上海	经济舱	靠过道	预订成功

【3】成对组合：被测软件中任意两个参数，它们取值范围的任意一对有效取值至少被一个测试用例所覆盖。

在成对组合中，测试覆盖项是两个不同参数的不重复键值对，如下表所示：

测试覆盖项编号	测试覆盖项内容	测试覆盖项编号	测试覆盖项内容	测试覆盖项编号	测试覆盖项内容
TCOVER1	北京，头等舱	TCOVER8	广州，公务舱	TCOVER15	广州，靠窗
TCOVER2	北京，公务舱	TCOVER9	广州，经济舱	TCOVER16	头等舱，靠过道
TCOVER3	北京，经济舱	TCOVER10	北京，靠过道	TCOVER17	头等舱，靠窗
TCOVER4	上海，头等舱	TCOVER11	北京，靠窗	TCOVER18	公务舱，靠过道
TCOVER5	上海，公务舱	TCOVER12	上海，靠过道	TCOVER19	公务舱，靠窗
TCOVER6	上海，经济舱	TCOVER13	上海，靠窗	TCOVER20	经济舱，靠过道
TCOVER7	广州，头等舱	TCOVER14	广州，靠过道	TCOVER21	经济舱，靠窗

 设计用例覆盖所有测试覆盖项，共9条用例，如下表：

测试用例编号	输入值			预期结果	测试覆盖项
	目的地	舱位	座位
1	北京	头等舱	靠过道	预订成功	TCOVER1，10，16
2	北京	公务舱	靠窗	预订成功	TCOVER2，11，19
3	北京	经济舱	靠过道	预订成功	TCOVER3，10，20
4	上海	头等舱	靠过道	预订成功	TCOVER4，12，16
5	上海	公务舱	靠窗	预订成功	TCOVER5，13，19
6	上海	经济舱	靠过道	预订成功	TCOVER6，12，20
7	广州	头等舱	靠窗	预订成功	TCOVER7，15，17
8	广州	公务舱	靠过道	预订成功	TCOVER8，14，18
9	广州	经济舱	靠窗	预订成功	TCOVER9，15，21

【4】全组合：被测软件中所有参数取值范围的任意有效取值的组合至少被一个测试用例所覆盖。

根据乘法原理等排列组合知识，三个参数分别有3，3，2个取值可能，则一共可以得出3*3*2=18种不同的组合。

 【5】K强度组合：在组合强度要求为K的组合中(简称为K强度) ，任意K个参数取值范围的任意有效值的组合至少被一个测试用例覆盖。

当K=1 ， K强度组合就是单一选择；当K=2 ， K强度组合就等同于成对组合；而当K等于所有参数数量时， K强度组合等同于全组合。

3.4 决策表（重要）

也称判定表法，是分析和表达多种逻辑条件下执行不同操作情况的工具。

在一些数据处理当中，某些操作的实施依赖与多个逻辑条件的组合，即对不同逻辑条件的组合值，分别执行不同的操作，决策表适合于处理这种问题。

 决策表通常由4个部分组成：

• 条件桩（Condition Stub）：列出了问题的所有条件（输入区）
• 动作桩（Action Stub）：列出了问题规定可能采取的操作。这些操作的排列顺序没有约束（输出区）
• 条件项（Condition Entry）：列出针对它左列条件的取值。在所有可能情况下的真假值。（输入取值区）
• 动作项（Action Entry）：列出在条件项的各种取值情况下应该采取的动作（输出取值区）

规则（Rule）：决策表中右部的每一列（条件项和对应的动作项）都是一条规则 。

图示：

使用决策表法设计用例的步骤：

1、分析输入域，并对输入域进行有效划分，确定规则的个数。

2、填入条件取值，填入相应的动作，得到初始决策表

3、简化决策表，合并相似规则（相同动作）

4、设计测试用例，一条规则对应一个测试用例 

【经典例题】订购单的检查

【例子】 某公司订购单的检查：如果金额超过500元，又未过期，则发出批准单和提货单；如果金额超过500元，但过期了，则不发批准单；如果金额低于500元，则不论是否过期都发出批准单和提货单，在过期的情况下还需要发出通知单。

得到初始决策表：

化简规则（下面两个要同时满足）：

• 输出相同：欲化简的多个测试用例的输出结果应相同
• 输入相似：仅有一个输入条件的值可以不相同

 得到简化决策表：

3.5 因果图

因果图法是从需求中找出因(输入条件)和果(输出或程序状态的改变)，通过因果图转化成判定表。

输入与输出的依赖关系，考虑输入之间的约束、 输出之间的约束，最终也要转换成决策表（判定 表）。

输入与输出之间：恒等，非，或，与

输入与输入之间：E约束，I约束，O约束，R约束

输出与输出之间：M约束（强制约束）

注：这里不做过多探讨……

因果图法最终生成的是决策表。利用因果图生成测试用例的基本步骤如下：

1. 分析软件规格说明中哪些是原因，哪些是结果，并给每个原因和结果赋予一个标识符。

2. 分析软件规格说明中的语义，找出原因与结果之间、原因与原因之间对应的关系， 根据这些关系画出因果图。

3. 由于语法或环境的限制，有些原因与原因之间、原因与结果之间的组合情况不可能出现。为表明这些特殊情况，在因果图上用一些记号表明约束或限制条件。

4. 把因果图转换为决策表。

5. 根据决策表中的每一列设计测试用例。

3.6 场景法（重要）

场景法：通过分析不同事件的触发顺序和处理结果，构建各个事件流，并基于这些事件的触发控制业务流程，形成多个不同场景，最终基于场景设计测试用例。

适用：业务流程类软件，订单流程，政务系统审批流程，OA系统。

【1】基本流是从系统的某个初始状态开始，经一系列状态变化后到达终止状态的过程中最主要的一个业务流程。

【2】备选流是以基本流为基础，在经过基本流上每个判定节点(包括条件判定和循环判定)处满足不同的触发条件，而导致的其他事件流。

场景法使用步骤：

• 分析需求（流程图）
• 分析基本流和备选流
• 根据基本流和备选流，构建场景
• 设计测试用例，覆盖每一个分支（场景）

 【经典例题】围绕ATM机取款功能设计测试用例

过程描述：插入卡，校验成功后，输入密码，确定；密码校验通过后，输入取款金额，通过校验金额数，取钱成功；如果不通过，则不成功。

（1）画流程图：

基本流：插卡，正确的卡，正确的密码，……取款成功

备选流1：卡错误

备选流2：密码错误

备选流3：密码输入错误次数大于三次

备选流4：取款大于当天的取款额度

备选流5：卡余额小于取款数

备选流6： ATM机余额不足

（2）构建场景：

场景1（基本流）：正确的卡，正确的密码，……取款成功

场景2（基本流+备选流1）：卡错误

场景3（基本流+备选流2）：卡正确，密码错误

场景4（基本流+备选流2+备选流3）：卡正确，密码错误，输入错误次数大于三次

场景5（基本流+备选流4）：卡正确，密码正确，取款金额大于当天允许额度

场景6（基本流+备选流5）：卡正确，密码正确，取款额度符合，卡余额小于取款数

场景7（基本流+备选流6）：卡正确，密码正确，当天额度正确，ATM机余额不足

（3）设计测试用例：

ID	场景	输入						预期输出
		账户	密码	取款金额	取款额度	卡余额	ATM机余额
ATM-ST-001	1	4201	888888	1000	10000	50000	是	取款成功，账户余额更新为49000
ATM-ST-002	2	6789	N/A	N/A	N/A	N/A	N/A	提示卡错误，退卡
ATM-ST-003	3	4201	777777	N/A	N/A	N/A	N/A	提示密码错误，返回基本流
ATM-ST-004	4	4201	777777 777778 777779	N/A	N/A	N/A	N/A	提示密码错误，吞卡
ATM-ST-005	5	4201	888888	15000	10000	N/A	N/A	提示超过取款额度，返回基本流
ATM-ST-006	6	4201	888888	1000	10000	500	N/A	提示卡余额不足，返回基本流
ATM-ST-007	7	4201	888888	1000	10000	50000	500	提示ATM机余额不足，返回基本流

---

场景法使用注意事项：

• 最少的场景数等于事件流的总数，基本流与备选流的总数
• 有且唯一有一个场景仅包含基本流
• 对应某个备选流，至少应有一个场景覆盖

3.7 状态转换法

使用场合：多状态变化的情况

目标：设计测试用例达到对系统状态的覆盖，状态-条件组合的覆盖以及状态迁移路径的覆盖。

状态图的使用步骤：

1.根据需求，理解关键字段，获得主要的状态

2.绘制状态迁移图

3.画出状态迁移树

4.抽取测试用例规则（每个状态至少到达一次）

由于我们学校不怎么考察，就简单概述了，需要更多可以查询其他博客。

3.8 错误猜测法

是基于经验和直觉，推测程序中可能出现的各种错误和容易发生错误的特殊情况 。

3.9 用例方法使用总结

【1】首先进行等价类，几乎所有输入框都可以使用。

【2】任何情况下都必须使用边界值，所用涉及数值的，几乎都需要。

【3】因果图， 描述多个输入之间的制约关系。

【4】决策表（判定表），输入较多时，因果图比较复杂，因此往往使用决策表法替代因果图法。

【5】业务流程清晰，事件触发，使用场景法，涉及到使用流程的。

【6】状态转移法，不同状态相互转换。

【7】参数配置类的软件，组合测试法，输入条件排列组合过多时。

【8】错误推测法，使用其他方法都已思考过，将错误推测法设计的用例作为补充。

结尾

下一章更新：白盒测试。有错误的地方还望指出，评论区共同探讨。

期待三连！