🏀🏀🏀来都来了，不妨点个关注！
🎧🎧🎧博客主页：欢迎各位大佬!

1.测试用例的概念

在讲解测试用例的设计之前，我们先对测试用例的概念做一个介绍。
测试用例就是一组集合，包括了测试环境、操作步骤、测试数据和预期结果这几大要素。

2.测试用例的好处

• 提高代码的复用性，提高测试人员的测试效率。
• 便于回归测试
• 为自动化测试提供基础

3. 黑盒测试用例的设计

在说明如何进行黑盒测试用例的设计之前，我们先对黑盒测试的概念进行一个讲解。

3.1 黑盒测试的概念

黑盒测试，也称为功能测试或数据驱动测试，是一种软件测试方法。其核心思想是将被测软件视为一个无法打开的“黑盒子”。测试人员无需关心软件内部的逻辑结构和代码实现，仅依据软件的需求规格说明书，检查软件的功能是否符合其预定的功能说明。

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

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

在进行分析测试需求的时候，一般分为功能测试需求和非功能测试需求。

3.2.1 功能测试需求

对于功能测试中，可以借助功能框图来帮助我们进行测试的需求分析。概括起来，功能测试需求包括以
下，通常包括以下几个方面。
（1）系统各个功能界面的验证
（2）借助业务把功能串起来进行测试
（3）功能的一致性，交互性（多功能互操作）的测试
（4）系统的不同输入，结果输出的业务数据测试。
（5）功能的错误操作，异常操作的测试（属于负面测试）
（6）功能实现用到的算法验证，有时需要运用代码评审
（7）用户操作的易用性，用户体验，往往结合功能测试同时验证

3.2.2 非功能测试需求

非功能测试需求主要涉及性能，安全性，可靠性，兼容性，易维护性和可移植性等。从测试需求分析来
看，每一类非功能特性测试都需要根据需求单独分析。他们之间可能会存在相互影响，如安全性越高，
就越有可能给易用性，性能带来更大的挑战。

3.3 具体的黑盒测试用例设计方法

3.3.1 等价类法

概念：依据需求将输入（特殊情况下会考虑输出）划分为若干个等价类，从等价类中选出一个测试用例，如果这个测试用例测试通过，则认为所代表的等价类测试通过，这样就可以用较少的测试用例达到尽量多的功能覆盖，解决了不能穷举测试的问题。

1️⃣ 有效等价类：指对于程序的规格说明来说是合理的、有意义的输入数据构成的集合。
2️⃣ 无效等价类：指对于程序的规格说明而言不合理或无意义的输入数据。
等价类设计测试用例的步骤：

1. 充分理解需求
2. 划分有效等价类，无效等价类
3. 分别从有效等价类和无效等价类中抽取一个数据进行测试用例的设计

下面，我们可以考虑一个常见的场景：用户登录时输入账号功能：
例如用户名长度需要在6到16个字符之间，对此进行等价类的划分则如下：

3.3.2 边界值法

概念：边界值法是一种黑盒测试方法，其核心思想是通过选择系统输入的边界值和特殊值作为测试用例，边界值通常指的是输入变量的最小值、最大值以及临界值，而特殊值则是系统能够接受的非常规输入。
在设计测试用例时，边界值法常常与等价类划分法一起使用。
通过边界值法进行测试用例的设计时我们需要对以下几个概念进行了解：

• 上点：边界上的点，在闭区间中，上点位于区间内，在开区间中，上点位于区间外。
• 离点：离点是指离上点最近的点，在开区间中，离点位于域内；而在闭区间中，离点则位于域外。
• 内点：内点指的是区间内的任意点。
  我们仍以上面的账号的长度进行测试用例的设计，如下：
  

3.3.3 判定表法

概念：判定表法，又称为决策表法，是一种表格状的图形工具，适用于处理判断条件较多、各条件又相互组合、有多种决策方案的情况。判定表法能够把所有的输入条件、所有可能采取的动作按表格列出来，每一种条件和动作的组合构成一条规则，也即一条用例。
判定表由四个部分组成：

1. 条件桩： 列出所有条件的名称，即系统的所有输入。
2. 动作桩：列出系统可能采取的操作，即结果。
3. 条件项：列出各个条件所有可能的取值。
4. 动作项：列出所有可能采取的动作

规则：一组条件与动作的组合，一条规则对应一条测试用例

举例：“淘宝双十一，订单提交，金额大于300或者有红包，则有优惠”。

对应的测试用例如下：

3.3.4 正交表法

正交表通常用Ln(mk)表示，其中L代表正交表，n代表试验次数或正交表的行数，k代表最多可安排影响指标因素的个数或正交表的列数，m表示每个因素水平数。正交表的每一列中，不同数字出现的次数是相等的，这是正交表的一个重要特性。
n : 正交表的行数，也是实验的次数
k : 正交表的列数，也是控件的个数
m : 每个控件的取值个数
两个重要概念：

• 因素 ：输入变量
• 水平 ：每一个输入变量的取值

正交表的两个性质：

• 均衡分散性：正交表的每一列中，不同的数字（或水平）出现的次数是相等的。
• 整齐可比性：正交表中任意两列所构成的各有序数对出现的次数都一样多。

如何通过正交表设计测试用例
充分理解需求 —> /确定因素，确定水平 —> 画正交表 —> 补充正交表 —> 将正交表转换成测试用例
我们以注册这个需求进行设计，我们要求姓名，邮箱，密码，确认密码，验证码都输入正确才能注册成功。
对上述需求进行分析可以得知：

3.3.4.1 确定因素和水平

因素：姓名，邮箱，密码，确认密码，验证码。
水平：填写，不填写。

3.3.4.2 通过allpairs画正交表

3.3.4.3 补充正交表

3.3.4.4 将正交表转换成测试用例

3.3.5 场景设计法

现在的软件几乎都是用事件触发来控制流程的，事件触发时的情景便形成了场景，而同一事件不同的触发顺序和处理结果就形成事件流。其中，基本流是软件功能按照最短的事件流实现的一条正确流程；而备选流则是由于出现异常、缺陷或其他原因导致最终的目的不能实现或实现的流程并非最短的流程。 该方法可以比较生动地描绘出事件触发时的情景，有利于测试设计者设计测试用例，是测试用例更容易理解和执行。典型的应用是是用业务流把各个孤立的功能点串起来，为测试人员建立整体业务感觉，从而避免陷入功能细节忽视业务流程要点的错误倾向

那么如何通过场景设计法进行测试用例的设计呢？
充分理解需求—> 确定主数据流—>确定次数据流—>每一个数据流都是一个测试用例
上面讲解可能有点抽象，我们拿找女朋友这件事进行举例：

上面则是一条找女朋友未出现异常时的事件流，但找女朋友肯定不会这么一帆风顺嘛，也会出现以下种种情况即出现次事件流：

3.3.6 错误猜测法

黑盒测试的错误猜测法，也被称为错误推测法，是一种软件测试方法。其核心思想是在测试程序时，测试人员根据经验、知识和直觉来推测程序中可能存在的各种错误，从而有针对性地编写检查这些错误的测试用例。这种方法主要依赖于测试人员的直觉和工程经验，而并非是一种有章可循的工程设计方法。
需要注意的是，错误猜测法并不是一种完全可靠的测试方法，因为它依赖于测试人员的直觉和经验，可能存在遗漏或偏差。因此，在实际测试过程中，通常会结合其他测试方法，如等价类划分、边界值分析等，以确保测试的全面性和有效性。

以注册为例

1. 校验中特殊字符空格的处理
2. 密码校验中的大小写
3. 姓名中的特殊字符
4. 密码发送是否明文

4. 一些面试题

4.1 使用Fiddler模拟弱网

注意：如果你是模拟手机APP的弱网，那么你需要确保Fiddler能够抓到手机APP的包。

4.1.1 在Fiddler中打开弱网设置

打开Fiddler→Rules→Performance→勾选Simulate Modem Speed，勾选之后你会发现网络速度已经慢下来了，因为系统里有预设的网络参数值。

4.1.2 设置网络参数

4.2 接口测试

我们在一个页面按F12

4.2.1 在页面中按F12查看接口

4.2.2 选择一个接口进行复制

通过上面这张图即可查看一个页面有多少接口，我们选一个info接口进行测试如下：

4.2.3 在postman中import复制的内容

最后将我们复制的粘贴到下面截图即可，就可以开始进行接口测试了。

4.2.4 进行测试

测试http请求方法（get，post，delete…），针对参数进行测试（传递所有参数，传递部分参数，不传参数，传其他参数）

4.3 设计水杯测试用例

测试用例一般不唯一，一般是根据测试人员的经验。

4.4 设计微信发朋友圈测试用例

4.5 设计登录测试用例