黑盒测试的测试用例设计方法（很全！！！）

1. 什么是黑盒测试

  黑盒测试是一种软件测试方法，它侧重于测试软件的功能和行为，而不考虑内部代码的实现细节。在黑盒测试中，我们不需要了解软件的内部结构、算法或代码逻辑，而是根据软件的需求规范和功能说明来测试软件的输入和输出。

2. 测试用例的设计方法

  测试用例的基本要素：测试环境、操作步骤、测试数据、预期结果等要素。

2.1 基于需求进行测试用例的设计

  基于需求设计测试用例是测试设计和开发测试用例的基础，第一步就要分析测试需求，验证需求是否正确、完整、无二义性，并且逻辑自洽。在需求正确的基础上细化测试需求，从测试需求提炼出一个个测试点或者测试项，然后根据每一个测试点进行测试用例的设计。

  分析测试需求时，一般分为功能测试需求和非功能测试需求。

  功能性的测试用例是根据软件需求规格说明书，对软件的功能进行测试，验证软件是否满足用户的需求；非功能性的测试用例是根据软件的性能、安全性、可用性、可靠性等方面进行测试，验证软件是否符合质量标准。

2.1.1 功能需求测试分析

  对于功能需求测试，通常包括以下几个方面：

1. 需要对软件的功能模块进行划分，确定测试的范围和目标。
2. 需要对每个功能模块进行详细的分析，提取出可测试的内容，形成测试需求和测试点。
3. 需要对功能模块之间的交互和业务流程进行分析，设计相应的场景和用例。
4. 需要对功能需求的正确性、完整性、一致性、可核实性等进行评审，确保测试需求的质量。

2.1.2 非功能需求测试分析

  非功能需求测试分析是根据软件的性能、安全性、可用性、可靠性等方面进行测试，验证软件是否符合质量标准。

2.2 基于需求来设计测试点

  下面是基于需求分析出来的测试点（对163邮箱注册接口的测试点分析）。注意，下面只是测试点，并不是完整的测试用例。想要一个完整的测试用例就需要补充其它要素，比如测试数据、预期结果等。

2.3 具体的设计方法

  基于需求设计测试点的方法可以帮我们理清脉络、划分模块。但是我们还需要其它的设计方法来为我们精化测试点。比如“密码必须达到8~16位”，这个模块可以使用等价类、边界值等测试用例设计方法再进行优化。

2.3.1 等价类

  等价类的基本思想是把程序的输入域划分成若干部分（子集），然后从每个部分中选取少数代表性的数据作为测试用例。每一类的代表性数据在测试中的作用等价于这一类中的其他值。等价类法可以减少测试用例的数量，提高测试效率和覆盖率。

  等价类分为：

1. 有效等价类：满足用户需求输入集合。
2. 无效等价类：不满足用户需求的输入集合。

  比如：注册模块中，用户名必填且要求8~15位字符。

有效等价类：8~15 位 无效等价类：小于 8 位 或 大于 15 位

  现在可以分别在两类中抽取数据来代表它们自己的集合。

2.3.2 边界值

  边界值分析法就是对输入或输出的边界值进行测试的一种测试方法。通常边界值分析法是作为对等价类划分法的补充，这种情况下，其测试用例来自等价类的边界。

  谈到边界值法，就不得不讨论边界点，边界点一般分为如下几个板块：

1. 上点：边界上的点。
2. 内点：边界内的点。
3. 离点：离边界值最近的一个点
   1. 如果是闭区间，离点就是区间外距离上点最近的点。
   2. 如果是开区间，离点就是区间内距离上点最近的点。

  比如有以下区间：

• 上点：6、15
• 内点：13（取区间内的值即可）
• 离点：7、16

如果现在要求是用户名长度 6~15 呢？一样的道理：

现在可以将等价类 与 边界值 合并起来：

  将这两者合并后数据就更完整了。

2.3.3 判定表法

  判断表是一种用来分析和表达多个逻辑条件下执行不同操作的情况的工具。它可以把复杂的问题按照所有可能的情况列出来，简明而不遗漏。

在理解判定表之前需要知道一些定义：

1. 条件桩：输入条件
2. 条件项：条件的取值（条件是否发生）
3. 动作桩：输出结果
4. 动作项：根据条件项的取值来决定动作项的值，这个值就是结果是否发生。

  可能还是很抽象，请看下面案例：

“若用户欠费或停机，则不允许发短信”。我这里先给出它的判定表，先来理解上面的四个定义，请看下图。

  那么我们如何用判定表法来设计测试用例呢？一般是下面四步：

1. 定义条件桩与动作桩。
2. 设计判定表，全组合。
3. 填写动作项。
4. 简化判定表，如果结果相同并且只有一个条件不同可以合并。

  看案例：“验证用户名需求：第一项要求输入手机号或者电子邮箱作为账户名；第二项要求正确输入验证码，两项都验证成功后填写账户信息。但如果第一项校验不正确，则报错 L (输入手机号或电子邮箱格式错误)；如果第二项验证不成功，则报错 M (验证码输入错误)。”

• 条件桩：输入手机号、输入电子邮箱、输入验证码

• 动作桩：报错L、报错M、填写账户信息

• 设计表：

• 简化表

  可以看到 第1项、第2项 中同时输入了手机号与邮箱，这是不可能存在的，它俩只能一个为真，所以删除前两项；

  这时，表中的 6 列数据就是 6 个测试用例了。

2.3.4 因果图法

  上面的判定表法有一个缺点：第一，就是有的数据它不存在，还需要我们去优化；第二，如果我们的条件数为 7，那么判定表的项（列）有多少呢？$2^7=128$ 个，数量太多了。这时候就可以使用因果法来设计判定表，没错，还是要用判定表，但是这里因果图可以过滤很多不存在的项。

  在使用因果图的时候，我们还需要了解它的一些定义。

1. 图中的 c 表示 “条件”，e 表示 结果，那么下面就是条件与结果的关系。
   1. 恒等：一旦有了 c1 发生就一定有e1这个结果。
   2. 非：一旦有了 c1 这个条件，e1 就不会发生。
   3. 与：c1、c3 同时发生，e1 才会发生。
   4. 或：c1、c2、c3，只要满足其中一个条件 e1 就会发生。

2. 条件与条件之间的关系。
   1. 互斥：a、b、c条件 一次最多有一个条件成立。
   2. 包含：a、b、c条件至少一个必须成立。
   3. 屏蔽：当 a 成立的时候，b 不能成立；当 a 不成立时，b 不一定成立（可能成立、可能不成立）。
   4. 唯一：a、b、c有且只有一个成立，不能 全部不成立。
   5. 要求：如果 a 成立了，b 一定成立，反之相同。

E、I、M、O、R 是 a、b、c条件的关系。

  知道了上面的定义后，我们就可以利用因果图来设计判定表。这里使用上面判定表的案例：“验证用户名需求：第一项要求输入手机号或者电子邮箱作为账户名；第二项要求正确输入验证码，两项都验证成功后填写账户信息。但如果第一项校验不正确，则报错 L (输入手机号或电子邮箱格式错误)；如果第二项验证不成功，则报错 M (验证码输入错误)。”

1. 用因果图先分析 条件与条件、条件与结果 之间的关系。
   1. 条件：第一项输入手机号、第一项输入电子邮箱、第二项输入验证码。
   2. 动作（结果）：报错 L、报错 M、填写账户信息。
   3. 中间节点：当多个原因（输入条件）不是单纯的与和或的关系，可以利用中间节点存取中间结果，使因果图更加清晰；当多个原因（输入条件）都在描述同一件事情，可以利用中间节点归并逻辑使得因果图更加清晰。

  怎么画这个图呢？

（1）先把条件与结果画出来，并建立条件之间的关系，条件在左、结果在右：

（2）完善中间节点。

（3）条件、中间节点与结果的关系

（4）根据因果图转化为判定表

  图里的“-”表示无论取何值，结果都是一样的，换言之，结果与该条件没有什么关系。转化为判定表的时候，“以结果看齐”，根据因果图，将所有能达到该结果的条件的组合列出。

  比如最后一个结果“填写账户信息”，与它有联系的条件：“第二项输入验证码”、“第一项输入手机号或第一项输入电子邮箱”，要想结果成立则这个两个条件必须同时成立，因为它们是“与”的关系。再往下推，要想“第一项输入手机号或第一项输入电子邮箱”成立，则“第一项输入手机号”或“第一项输入电子邮箱”同一时间只能有一个成立，因为它们互斥。整个过程的值就是判定表中的一列或几列。

  可以看到，使用因果图后判定表中的项就少了很多，这就是因果图法的效果。

2.3.4 正交表法

  当测试用例的数量比较多，并且条件之间没有什么联系时，我们就可以使用正交法来减少我们的测试用例。它利用正交表来设计试验方案和分析试验结果，能够在很多的试验条件中，选出少数几个代表性强的试验条件，并通过这几次试验的数据，找到较好的生产条件，即最优的或较优的方案。

  同样的，我们需要知道以下定义：

• 条件：因子55
• 取值：水平（条件的取值的个数）

设计正交表的步骤：

1. 分析需求获取因子（条件）及水平。
2. 根据因子及水平树选择正交表。
3. 替换因子水平获取实验次数。
4. 细化输出测试用例。

案例：网站兼容性测试。

(1)Web浏览器：Netscape 6.2、IE 6.0、Opera 4.0。

(2)插件：无、RealPlayer、 MediaPlayer。

(3)应用服务器：IIS、Apache、 Netscape Enterprise。

(4)操作系统：Windows 11、Windows NT、Linux。

1. 得出，因子：4 水平：3
2. 查公式，这是根据因子与水平来查表的，👉Orthogonal Arrays (york.ac.uk) 里提供了很多正交表，比如里面的 因子4、水平3的正交表为：

这个表里的 Column 代表的是因子，这里有 4 个，ExperimentNumber（实验数）代表的是测试用例的个数，这里有 9 个。而重点是中间的值。比如：

第一行：第一组实验，所有因子的值都取第一个。

第二行：第二组实验，第一个因子的值取第一个，其它因子的值取第二个。

……

3. 回到案例上，我们根据这个表来设计正交表

	web浏览器	插件	应用服务器	操作系统
1	Netscape 6.2	无	IIS	Windows 11
2	Netscape 6.2	RealPlayer	Apache	Windows NT
3	Netscape 6.2	MediaPlayer	Netscape Enterprise	Linux
4	IE 6.0	无	Apache	Linux
5	IE 6.0	RealPlayer	Netscape Enterprise	Windows 11
6	IE 6.0	MediaPlayer	IIS	Windows NT
7	Opera 4.0	无	Netscape Enterprise	Windows NT
8	Opera 4.0	RealPlayer	IIS	Linux
9	Opera 4.0	MediaPlayer	Apache	Windows 11

4. 还有一个问题，不是所有的因子水平数都有对应的正交表，比如5因子2水平，怎么办呢？那就是找到离它最近的一个正交表，比如7因子2水平的正交表，多的2个因子不填就行了。

*补充：用例个数 = 因子数 （水平数-1） + 1

但是这样来设计太麻烦了，很容易搞错。有一个软件可以自动设计正交表：通过 allpairs 软件来生成正交表 - 掘金 (juejin.cn)

2.3.5 状态迁移图法

  前面的设计法大都是针对某一个功能点进行测试用例的设计。这里的状态迁移图法与场景设计法则是针对整体业务流程进行测试。

  状态迁移图法：它适用于整个系统状态比较多的情况，首先要找出所有的状态，然后再分析各个状态之间的转换条件和转换路径。然后从其状态迁移路径覆盖的角度来设计测试用例。

1. 明确状态节点。
2. 绘制迁移图。
3. 绘制状态迁移树。
4. 抽取路径设计用例。

案例：飞机售票系统。

（1）客户向航空公司打电话预定机票，此时机票信息处于“预订”状态。

（2）顾客支付了机票费用后，机票信息变为“已支付”状态。

（3）旅行当天到达机场，拿到机票后，机票信息变为“已出票”状态。

（4）登机检票后，机票信息变为“已使用”状态。

（5）在登机之前任何时间都可以取消自己的订票信息，如果已经支付了机票的费用，则还可以退款，取消后，订票信息处于“已取消”状态。

1. 设计状态迁移图

2. 设计状态迁移树，这一步就像是把图转换为树。

3. 抽取路径设计用例。

路径1：预定——》已取消

路径2：预定——》已支付——》已取消

路径3：预定——》已支付——》已出票——》已取消

路径4：预定——》已支付——》已出票——》已使用

2.3.6 场景设计法

  场景设计法跟状态迁移图差不多，场景设计法适用于整个系统没有明确的状态的时候。在这之前，我们需要知道一些概念：

• 基本流：也叫有效流或正确流，模拟用户正确的业务操作流程。
• 备选流：也叫无效流或错误流，模拟用户错误的业务操作流程。
  • 异常流：（其实也可看成是备选流）也叫故障流或中断流，模拟系统出现异常或故障的情况。例如，用户登录网站的异常流有网络断开，点击登录，无法连接服务器；系统维护中，点击登录，提示系统暂停服务等。

  场景设计法的步骤：

1. 分析需求，选出基本流与备选流。
2. 根据基本流和备选流生成场景。
3. 根据场景生成用例。

场景1：基本流

场景2：基本流一备选流程1一基本流

场景3：基本流一备选流程2一基本流

场景4：基本流一异常流程1

……

案例：“验证用户名需求：第一项要求输入手机号或者电子邮箱作为账户名；第二项要求正确输入验证码，两项都验证成功后填写账户信息。但如果第一项校验不正确，则报错 L (输入手机号或电子邮箱格式错误)；如果第二项验证不成功，则报错 M (验证码输入错误)。”

基本流：输入正确用户名、输入正确的验证码、填写账户信息

备选流1：用户名填写错误，报错L

备选流2：输入的验证码错误，报错M

可以将整个流程化为流程图。

测试用例：

用例1：第一项输入手机号，第二项验证码正确，进入填写账户信息页面。

用例2：第一项输入电子邮箱，第二项验证码正确，进入填写账户信息页面。

用例3：第一项输入不是手机号或者电子邮箱，报错L。

用例4：第一项输入手机号或者电子邮箱，第二项验证码错误，报错M。

这其实跟状态迁移图的思路差不多，都是将不同的路径进行组合，但是重复的路径可以删去。

2.3.7 错误猜想法

  错误猜想法是基于检验与直觉的，没有一个固定的公式。根据以往的测试经验和对系统内部知识的了解，列出系统中各种可能有的错误和容易发生错误的特殊情况，再根据它们来设计测试用例。

  假设要测试一个计算器程序，它可以进行加、减、乘、除四则运算，并且有一个显示屏和一些数字和符号键。

我们可以根据以下的错误类型或易错情况来设计测试用例：

• 输入数据的有效性：比如输入非数字或非法符号，输入空值或过长的值，输入超出计算器范围的值等。
• 输出数据的正确性：比如检查计算结果是否正确，是否符合数学规则，是否有四舍五入或精度损失等。
• 系统功能的完备性：比如检查加、减、乘、除四则运算是否都能正常执行，是否支持负数和小数的运算，是否支持括号和优先级的运算等。