1. 什么是黑盒测试
黑盒测试是一种软件测试方法，它侧重于测试软件的功能和行为，而不考虑内部代码的实现细节。在黑盒测试中，我们不需要了解软件的内部结构、算法或代码逻辑，而是根据软件的需求规范和功能说明来测试软件的输入和输出。
2. 测试用例的设计方法
测试用例的基本要素：测试环境、操作步骤、测试数据、预期结果等要素。
2.1 基于需求进行测试用例的设计
基于需求设计测试用例是测试设计和开发测试用例的基础，第一步就要分析测试需求，验证需求是否正确、完整、无二义性，并且逻辑自洽。在需求正确的基础上细化测试需求，从测试需求提炼出一个个测试点或者测试项，然后根据每一个测试点进行测试用例的设计。
分析测试需求时，一般分为功能测试需求和非功能测试需求。
功能性的测试用例是根据软件需求规格说明书，对软件的功能进行测试，验证软件是否满足用户的需求；非功能性的测试用例是根据软件的性能、安全性、可用性、可靠性等方面进行测试，验证软件是否符合质量标准。
2.1.1 功能需求测试分析
对于功能需求测试，通常包括以下几个方面：
2.1.2 非功能需求测试分析
非功能需求测试分析是根据软件的性能、安全性、可用性、可靠性等方面进行测试，验证软件是否符合质量标准。
2.2 基于需求来设计测试点
下面是基于需求分析出来的测试点（对163邮箱注册接口的测试点分析）。注意，下面只是测试点，并不是完整的测试用例。想要一个完整的测试用例就需要补充其它要素，比如测试数据、预期结果等。
2.3 具体的设计方法
基于需求设计测试点的方法可以帮我们理清脉络、划分模块。但是我们还需要其它的设计方法来为我们精化测试点。比如“密码必须达到8~16位”，这个模块可以使用等价类、边界值等测试用例设计方法再进行优化。
2.3.1 等价类
等价类的基本思想是把程序的输入域划分成若干部分（子集），然后从每个部分中选取少数代表性的数据作为测试用例。每一类的代表性数据在测试中的作用等价于这一类中的其他值。等价类法可以减少测试用例的数量，提高测试效率和覆盖率。
等价类分为：
比如：注册模块中，用户名必填且要求8~15位字符。
有效等价类：8~15 位
无效等价类：小于 8 位 或 大于 15 位
现在可以分别在两类中抽取数据来代表它们自己的集合。
2.3.2 边界值
边界值分析法就是对输入或输出的边界值进行测试的一种测试方法。通常边界值分析法是作为对等价类划分法的补充，这种情况下，其测试用例来自等价类的边界。
谈到边界值法，就不得不讨论边界点，边界点一般分为如下几个板块：
比如有以下区间：
- 上点：6、15
- 内点：13（取区间内的值即可）
- 离点：7、16
如果现在要求是用户名长度 6~15 呢？一样的道理：
现在可以将等价类 与 边界值 合并起来：
将这两者合并后数据就更完整了。
2.3.3 判定表法
判断表是一种用来分析和表达多个逻辑条件下执行不同操作的情况的工具。它可以把复杂的问题按照所有可能的情况列出来，简明而不遗漏。
在理解判定表之前需要知道一些定义：
可能还是很抽象，请看下面案例：
“若用户欠费或停机，则不允许发短信”。我这里先给出它的判定表，先来理解上面的四个定义，请看下图。
那么我们如何用判定表法来设计测试用例呢？一般是下面四步：
看案例：“验证用户名需求：第一项要求输入手机号或者电子邮箱作为账户名；第二项要求正确输入验证码，两项都验证成功后填写账户信息。但如果第一项校验不正确，则报错 L (输入手机号或电子邮箱格式错误)；如果第二项验证不成功，则报错 M (验证码输入错误)。”
-
条件桩：输入手机号、输入电子邮箱、输入验证码
-
动作桩：报错L、报错M、填写账户信息
-
设计表：
- 简化表
可以看到 第1项、第2项 中同时输入了手机号与邮箱，这是不可能存在的，它俩只能一个为真，所以删除前两项；
这时，表中的 6 列数据就是 6 个测试用例了。
2.3.4 因果图法
上面的判定表法有一个缺点：第一，就是有的数据它不存在，还需要我们去优化；第二，如果我们的条件数为 7，那么判定表的项（列）有多少呢？27=1282^7=12827=128 个，数量太多了。这时候就可以使用因果法来设计判定表，没错，还是要用判定表，但是这里因果图可以过滤很多不存在的项。
在使用因果图的时候，我们还需要了解它的一些定义。
E、I、M、O、R 是 a、b、c条件的关系。
知道了上面的定义后，我们就可以利用因果图来设计判定表。这里使用上面判定表的案例：“验证用户名需求：第一项要求输入手机号或者电子邮箱作为账户名；第二项要求正确输入验证码，两项都验证成功后填写账户信息。但如果第一项校验不正确，则报错 L (输入手机号或电子邮箱格式错误)；如果第二项验证不成功，则报错 M (验证码输入错误)。”
怎么画这个图呢？
（1）先把条件与结果画出来，并建立条件之间的关系，条件在左、结果在右：
（2）完善中间节点。
（3）条件、中间节点与结果的关系
（4）根据因果图转化为判定表
图里的“-”表示无论取何值，结果都是一样的，换言之，结果与该条件没有什么关系。转化为判定表的时候，“以结果看齐”，根据因果图，将所有能达到该结果的条件的组合列出。
比如最后一个结果“填写账户信息”，与它有联系的条件：“第二项输入验证码”、“第一项输入手机号或第一项输入电子邮箱”，要想结果成立则这个两个条件必须同时成立，因为它们是“与”的关系。再往下推，要想“第一项输入手机号或第一项输入电子邮箱”成立，则“第一项输入手机号”或“第一项输入电子邮箱”同一时间只能有一个成立，因为它们互斥。整个过程的值就是判定表中的一列或几列。
可以看到，使用因果图后判定表中的项就少了很多，这就是因果图法的效果。
2.3.4 正交表法
当测试用例的数量比较多，并且条件之间没有什么联系时，我们就可以使用正交法来减少我们的测试用例。它利用正交表来设计试验方案和分析试验结果，能够在很多的试验条件中，选出少数几个代表性强的试验条件，并通过这几次试验的数据，找到较好的生产条件，即最优的或较优的方案。
同样的，我们需要知道以下定义：
- 条件：因子55
- 取值：水平（条件的取值的个数）
设计正交表的步骤：
案例：网站兼容性测试。
(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。
这个表里的 Column 代表的是因子，这里有 4 个，ExperimentNumber（实验数）代表的是测试用例的个数，这里有 9 个。而重点是中间的值。比如：
第一行：第一组实验，所有因子的值都取第一个。
第二行：第二组实验，第一个因子的值取第一个，其它因子的值取第二个。
……
| 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 |
*补充：用例个数 = 因子数 （水平数-1） + 1
但是这样来设计太麻烦了，很容易搞错。有一个软件可以自动设计正交表：通过 allpairs 软件来生成正交表 - 掘金 (juejin.cn)
2.3.5 状态迁移图法
前面的设计法大都是针对某一个功能点进行测试用例的设计。这里的状态迁移图法与场景设计法则是针对整体业务流程进行测试。
状态迁移图法：它适用于整个系统状态比较多的情况，首先要找出所有的状态，然后再分析各个状态之间的转换条件和转换路径。然后从其状态迁移路径覆盖的角度来设计测试用例。
案例：飞机售票系统。
（1）客户向航空公司打电话预定机票，此时机票信息处于“预订”状态。
（2）顾客支付了机票费用后，机票信息变为“已支付”状态。
（3）旅行当天到达机场，拿到机票后，机票信息变为“已出票”状态。
（4）登机检票后，机票信息变为“已使用”状态。
（5）在登机之前任何时间都可以取消自己的订票信息，如果已经支付了机票的费用，则还可以退款，取消后，订票信息处于“已取消”状态。
路径1：预定——》已取消
路径2：预定——》已支付——》已取消
路径3：预定——》已支付——》已出票——》已取消
路径4：预定——》已支付——》已出票——》已使用
2.3.6 场景设计法
场景设计法跟状态迁移图差不多，场景设计法适用于整个系统没有明确的状态的时候。在这之前，我们需要知道一些概念：
- 基本流：也叫有效流或正确流，模拟用户正确的业务操作流程。
- 备选流：也叫无效流或错误流，模拟用户错误的业务操作流程。
- 异常流：（其实也可看成是备选流）也叫故障流或中断流，模拟系统出现异常或故障的情况。例如，用户登录网站的异常流有网络断开，点击登录，无法连接服务器；系统维护中，点击登录，提示系统暂停服务等。
场景设计法的步骤：
场景1：基本流
场景2：基本流一备选流程1一基本流
场景3：基本流一备选流程2一基本流
场景4：基本流一异常流程1
……
案例：“验证用户名需求：第一项要求输入手机号或者电子邮箱作为账户名；第二项要求正确输入验证码，两项都验证成功后填写账户信息。但如果第一项校验不正确，则报错 L (输入手机号或电子邮箱格式错误)；如果第二项验证不成功，则报错 M (验证码输入错误)。”
基本流：输入正确用户名、输入正确的验证码、填写账户信息
备选流1：用户名填写错误，报错L
备选流2：输入的验证码错误，报错M
可以将整个流程化为流程图。
测试用例：
用例1：第一项输入手机号，第二项验证码正确，进入填写账户信息页面。
用例2：第一项输入电子邮箱，第二项验证码正确，进入填写账户信息页面。
用例3：第一项输入不是手机号或者电子邮箱，报错L。
用例4：第一项输入手机号或者电子邮箱，第二项验证码错误，报错M。
这其实跟状态迁移图的思路差不多，都是将不同的路径进行组合，但是重复的路径可以删去。
2.3.7 错误猜想法
错误猜想法是基于检验与直觉的，没有一个固定的公式。根据以往的测试经验和对系统内部知识的了解，列出系统中各种可能有的错误和容易发生错误的特殊情况，再根据它们来设计测试用例。
假设要测试一个计算器程序，它可以进行加、减、乘、除四则运算，并且有一个显示屏和一些数字和符号键。
我们可以根据以下的错误类型或易错情况来设计测试用例：
- 输入数据的有效性：比如输入非数字或非法符号，输入空值或过长的值，输入超出计算器范围的值等。
- 输出数据的正确性：比如检查计算结果是否正确，是否符合数学规则，是否有四舍五入或精度损失等。
- 系统功能的完备性：比如检查加、减、乘、除四则运算是否都能正常执行，是否支持负数和小数的运算，是否支持括号和优先级的运算等。
