企业官网建设流程全解析

设计测试用例的方法（等价类，边界值，场景法）

这篇博客，是从这篇博客的内容中，分离出来的，用来介绍测试用例的。
上一篇博客：测试(9) - 测试用例篇

如果你没有看过上一篇博客，推荐看到上一篇博客中，这篇博客的链接后，再点击那个链接，进来看这篇博客。

实际在工作中，设计测试用例的步骤是：

1. 基于需求的设计方法
2. 采用具体的设计方法

1. 基于需求的设计方法

基于需求的设计方法也是总体设计测试用例的方法，在工作中，我们需要参考需求文档/产品规格说明书来设计测试用例。

测试人员接到需求之后，要对需求进行分析和验证，从合理的需求中进一步分析细化需求，从细化的需求中找出测试点，根据这些测试点再去设计测试用例。

这流程就是：接到需求 → 分析和验证 → 细化需求 → 找出测试点 → 设计测试用例

以该注册邮箱账号需求为例，我们来设计测试用例。

这是注册邮箱账号的需求文档：

1.1 明确需求中的功能点：

从上述需求文档的描述中，功能点有两个：

1. 邮箱账号注册
2. 邮箱账号登录

1.2 结合万能公式设计测试用例：

这是依据 万能公式（6个测试思维方向）设计的测试用例：

万能公式，针对这 6 个方面：

1. 功能测试
2. 性能测试
3. 界面测试
4. 兼容性测试
5. 易用性测试
6. 安全测试

2. 具体的设计方法

具体的设计方法，介绍 6 个：

1. 等价类
2. 边界值
3. 正交法
4. 判定表法
5. 错误猜测法
6. 场景法

其中，这 6 给设计方法，在实际工作中，也是有使用频率的：

用的最多的，频繁使用的：等价类 & 边界值

用的频率正常的：错误猜测法 & 场景法

工作中几乎不会的：正交法 & 判定表法

其中：

• 等价类 & 边界值是真真切切的设计方法
• 错误猜测法 & 场景法是设计测试用例的一种思维，能帮助你设计更多的测试用例。
• 正交法 & 判定表法，是一种设计方法，但工作中，完全（几乎完全）不会用，但是对以后设计测试用例，会有潜移默化的影响，提升测试思维能力。

2.1 等价类

上述注册邮箱账号的测试用例，还存在用例未完全设计完成的情况，以 “姓名必填，6~15 位字符类型” 这一具体需求为例，我们该如何设计测试用例？

测试时如果采用穷举法，逐一验证6 位、7 位、8 位……14 位、15 位是否测试通过，这种方式能否满足测试要求？若此时将长度范围从 “6 ~ 15 位” 修改为 “6 ~ 150 位”，可以想象，仅这一个简单测试点就需要耗费大量测试时间，显然不符合企业实际的测试要求。

而等价类法的出现，恰好解决了穷举法无法解决的问题。

等价类的思想：
依据需求将输入（特殊情况下会考虑输出）划分为若干个等价类，从若干等价类中选取一个测试用例。
若该测试用例测试通过，则认为其所代表的整个等价类均测试通过。

这样就可以用较少的测试用例实现尽可能多的功能覆盖，解决了无法进行穷举测试的问题。

生活案例理解：

假如你学校的图书馆，在某一个楼层，这里就假设，在图书馆二楼，有一个大型的图书存储室，提供了很多座椅，让学生随时拿书出来，坐在椅子上看书。

其中，书分成了很多类的书，这里以专业为例进行分类：计算机类图书，机械类图书，会计图书，教育类图书等。

如果没有按照等价类的思想，你要找一本计算机类的图书，一本一本的找，要找很久。

如果图书馆按照区域分类图书（前提条件），比如：

你要找一本计算机网络的书，只要在一块区域中，找到一本计算机类的图书，就可以只在这部分区域中找就行（明确该区域是计算机类图书所在区域），而不用一本一本的，所有区域都找一遍了。

应用到注册邮箱：

以 “姓名必填，6 ~ 15 位字符类型” 这一具体需求为例，我们可以将 6~15 位字符类型，划分出多个 等价类：

1. 等价类1
2. 等价类2
3. 等价类3
4. ……

那么，测试人员，只需要从每个等价类中选取一个测试用例。

若该测试用例测试通过，则认为其所代表的整个等价类均测试通过。

这样就可以用较少的测试用例实现尽可能多的功能覆盖，大大减少了测试需要耗费的时间。

等价类分类：

有效等价类：针对 程序规格说明书（需求文档） 而言，由合理、有意义的输入数据构成的集合，用于验证程序是否实现了 程序规格说明书（需求文档）中规定的功能与性能。

无效等价类：根据需求说明书（需求文档），不满足需求的输入数据所构成的集合。

根据等价类设计测试用例的步骤：

1. 确定有效等价类和无效等价类
2. 编写测试用例，设计具体测试数据

例如，6~15 位字符类型，我们可以设计等价类：

1. 有效等价类：6~15位（合理的，不符合姓名格式要求的，有意义的输入数据）
2. 无效等价类：<6位，>15位（不符合姓名格式要求的，不满足需求的输入数据）

• 对于 6~15位，我们测试一个 10位 的案例，测试用例通过，就说明，这个等价类中其他的测试用例也都没有问题。
• 对于 <6位，我们测试一个 1位 的案例，测试用例通过，就说明，这个等价类中其他的测试用例也都没有问题。
• 对于 >15位，我们测试一个 20位 的案例，测试用例通过，就说明，这个等价类中其他的测试用例也都没有问题。

上述，也符合我们设计测试用例的思想：测试用例的设计，不仅要覆盖有效、可预期的输入场景，还必须充分考虑无效、异常及不可预期的输入情况。

等价类划分的缺点

等价类划分，只看单个输入项，把输入分成有效、无效等价类。

比如：账号输入框、密码输入框，我们分别给账号划分等价类、给密码划分等价类。

问题：它不考虑多个输入之间互相搭配组合的情况。

举个例子：登录功能，两个输入框：账号、密码

• 账号：有效、无效
• 密码：有效、无效

等价类只会单独测：

1. 账号有效，密码有效
2. 账号无效，密码有效
3. 账号有效，密码无效

但是！等价类不会主动去测「账号无效 + 密码无效」这种组合场景。
这就是它的短板：只单独看每个输入，忽略输入之间组合带来的 bug。

2.2 边界值

边界值分析法是对输入或输出的边界值开展测试的黑盒测试方法，一般作为等价类划分法的补充。
它的测试用例选取等价类划分得到的输入区间的边界点。

日常语言中的 “边界” 漏洞示例：
考完试下发成绩，老师布置寒假作业：超过 60 分的，所有题目抄写 1 遍；低于 60 分的，所有题目抄写 3 遍。
那么小明写作业，要抄几次？因为他刚好考了 60 分。

边界值取值包含：边界值 + 次边界值
边界值，次边界值是相对的，那我们如何确定 边界值，次边界值？

• 边界值：找区间的左右端点，然后确定是否是有效的等价类
  次边界值（离点）：紧挨着端点的相邻数字，根据边界值，是否是有效的等价类，再确定应该是左端点的左边，还是左端点的右边，是右端点的左边，还是右端点的右边

确定边界值：

例子 1：闭区间 [6，15]

含义：取值范围包含 6 和 15，6~15 之间都合法。

• 边界值（区间端点）：6、15
  6、15 在区间内部，属于有效等价类。
• 次边界值（离点）：5、16
  5 在 6 的左侧，16 在 15 的右侧，都超出区间范围，属于无效等价类。

总结：闭区间，端点是有效；端点往外紧邻的数字是无效。

例子 2：开区间 (6，15)

含义：取值范围不包含 6 和 15，必须大于 6、小于 15 才合法。

• 边界值（区间端点）：6、15
  6、15 不在区间内，属于无效等价类。
• 次边界值（离点）：7、14
  7 是 6 右边第一个数，14 是 15 左边第一个数，落在区间内部，属于有效等价类。

总结：开区间，端点是无效；端点往区间内部紧邻的数字是有效。

其他例子：

1. 输入框长度为 1~11 位（闭区间 [1,11]），取边界值：0、1、11、12
2. 运动员参赛项目为 1~3 项（闭区间 [1,3]），取边界值：0 项、1 项、3 项、4 项

边界值 + 等价类 结合使用：

还是拿上面的例子：6~15 位字符类型，我们可以设计等价类：

1. 有效等价类：6~15位
2. 无效等价类：<6位、>15位

前面的例子中，我们已经选取了三个案例，进行测试：

• 对于6~15位，我们测试一个 10位 的案例，测试用例通过，就说明，这个等价类中其他的测试用例也都没有问题。
• 对于<6位，我们测试一个 1位 的案例，测试用例通过，就说明，这个等价类中其他的测试用例也都没有问题。
• 对于>15位，我们测试一个 20位 的案例，测试用例通过，就说明，这个等价类中其他的测试用例也都没有问题。

现在，**加上 边界值：6，15，次边界值：5，16 ** 进行测试。

那么，这些测试用例，也是可以优化的，把之前选取的 1，10，20 这三个测试用例，删除就行。

2.3 正交法（了解即可，可以不掌握，工作中基本不用）

通过等价类和边界值方法，我们已完成了部分测试用例的补充。

当前仍有一个场景的用例未补充完成，即 “只填写部分选项”，这里究竟需要设计多少个测试用例呢？

通常来说，为了保证系统的测试覆盖率，我们首先会想到采用排列组合的方式。

• 若有两个选项 A 和 B，可设计出：都填写、都不填写、填写 A、填写 B，共 4 个测试用例（2²）。
• 若有三个选项 A、B、C，可设计出 8 个测试用例（2³）。
• ……

当前可选的选项有 5 个，分别是：姓名、电子邮箱、密码、确认密码、验证码。若按照排列组合方式设计，将得到 32 个测试用例。

✅ 正交法的核心目的是减少测试用例数量，通过最少的用例覆盖输入条件的两两组合。

正交试验设计（Orthogonal experimental design）是研究多因素、多水平的一种设计方法。

它根据正交性，从试验因素的全部水平组合中挑选出部分有代表性的点进行试验，通过对这部分试验结果的分析，了解全面试验的情况，从而找出最优的水平组合。正交试验设计是一种基于正交表、高效率、快速、经济的试验方法。

正交表：

通过正交表，挑选出部分有代表性的点。

如图最简单的正交表是 L₄(2³)：

因素：对指标的影响条件，通常是正交表中的⼀列。

如：姓名、电子邮箱、密码、确认密码、验证码

水平：每一个因素对应的可选项。

如：姓名，有 2 种可选项：填写，不填写。选 1 为填写，选 2 为不填写。

正交表的性质：

正交表的性质：

• 每一列中，不同数字出现的次数相等。
• 任意两列中，数字的排列方式齐全且均衡。

根据正交表的这些性质，一般人很难通过手动方式设计出正交表。

对于计算机专业的同学，很难画出来，对于数学专业的同学，也很难画出来。

如何设计正交表：

1. 确定因素和水平

2. 使用 allpairs 工具生成正交表

   a. 将因素和水平录入 Excel 表格

   b. 在 allpairs 目录下新建文本文件 new.txt，将 Excel 中的因素和水平复制粘贴到文件中保存并关闭

   c. 执行 allpairs 命令生成正交表：allpairs.exe new.txt > zhengjiao.txt

3. 根据正交表编写测试用例

4. 补充遗漏的重要测试用例

继续以邮箱注册为例，采用正交法补全剩余测试用例：

1. 确定因素和水平

   • 因素：姓名、电子邮箱、密码、确认密码、验证码
   • 水平：填写、不填写

2. 使用 allpairs 工具生成正交表

   a. 将因素和水平录入 Excel 表格

   b. 在 allpairs 目录下新建文本文件 0714.txt，将 Excel 中的因素和水平复制粘贴到文件中保存并关闭

   c. 执行 allpairs 命令生成正交表：allpairs.exe 0714.txt > 0714jg.txt（生成的正交表数据存入 0714jg.txt 文件）

3. 根据正交表编写测试用例

4. 补充遗漏的重要测试用例

注意：使用 allpairs 生成的正交表可能与预期存在出入，但不影响我们据此设计测试用例。

这里介绍的很粗糙，你可以点击这两篇博客去看看。

正交测试用例自动生成工具—Allpairs下载和使用（偏向安装）

如何使用allpairs工具生成正交表（超详细版）（偏向使用）

这是别人写的博客，写的很好。

2.4 判定表法（了解即可，可以不掌握，工作中基本不用）

通过具体的方法，可以让测试用例设计得更加完整与规范。

需求中会存在各种各样的业务场景，现将需求修改为如下要求：

用户输入的账号中包含admin字符，或者通过内部链接进入注册页面，提交注册按钮后即为管理员身份；反之则不具备管理员身份。

从这个需求可以看出，不同的条件组合会对应不同的输出结果。这类场景无法使用正交法解决，而正交法原本适用于只需考虑输入之间组合关系、对应不同结果的场景。

判定表：

判定表是一种表达逻辑判断的工具，形如：

通过该图，可以清晰地展示所有条件对应的结果。我们需要借助这张表，清晰地编写测试用例。

判定表法设计测试用例的步骤：

1. 确认需求中的输入条件与输出条件
2. 梳理输入条件与输出条件之间的逻辑关系
3. 绘制判定表
4. 根据判定表编写测试用例

根据如下要求，设计测试用例：

用户输入的账号中包含admin字符，或者通过内部链接进入注册页面，提交注册按钮后即为管理员身份；反之则不具备管理员身份。

1. 确认需求中输入条件和输出条件

输入条件：包含 admin 字符、内部链接进入、提交注册按钮

输出条件：管理员角色、非管理员角色

2. 找出输入条件和输出条件之间的关系

我们通过字符 a，b，c，数字 1，2 表示各种输入条件和输出结果：

输入条件：包含 admin 字符（a）、内部链接进入（b）、提交注册按钮（c）

输出条件：管理员角色（1）、非管理员角色（2）

输入条件的组合：ac ab bc abc a b c 非 abc

对应的输出结果：1 2 1 1 2 2 2 2

3. 画判定表

4. 根据判定表编写测试用例

1）包含 admin 字符，不是从内部链接进入，提交注册按钮，成为管理员账号

2）不包含 admin 字符，内部链接进入，提交注册按钮，成为管理员账号

3）不包含 admin 字符，不是从内部链接进入，只提交注册按钮，不会成为管理员账号

4）包含 admin 字符，从内部链接进入，提交注册按钮，成为管理员账号

5）不包含 admin 字符，不是从内部链接进入，未提交注册按钮，不会成为管理员账号

6）包含 admin 字符，不是从内部链接进入，未提交注册按钮，不会成为管理员账号

7）不包含 admin 字符，内部链接进入，未提交注册按钮，不会成为管理员账号

8）不包含 admin 字符，不是从内部链接进入，提交注册按钮，不会成为管理员账号

2.5 错误猜测法：

错误猜测法是基于对被测软件的设计理解、过往测试经验与个人直觉，推测软件可能存在的缺陷，并针对性设计测试用例的方法。

该方法重点依赖对软件需求的理解、对设计与实现细节的把握，以及测试人员的经验积累和直觉判断。

例如，我们说到使用字符拼接，形成 SQL语句，有经验的测试人员就会想到 SQL注入 的风险。

错误猜测法与当下主流的探索式测试思想基本一致，这类方法在敏捷开发模式下投入产出比高，是测试工作中被广泛应用的实用技巧。

这个方法的缺点是难以系统化，并且过度依赖个人能力。

2.6 场景法

现在的软件大多采用事件触发来控制流程，事件触发时的情境构成场景；同一事件不同的触发顺序和处理结果，则形成事件流。

场景法是通过运用场景来描述系统功能点或业务流程，从而提升测试效果的一种方法。
使用场景法测试需求，是指模拟特定场景边界发生的事件，通过事件触发相应动作，观察最终结果，以此发现需求中存在的问题。
通常先从正常用例场景开始分析，再逐步扩展到其他场景。

场景法一般包含基本流和备用流：从一个流程起始，按执行经过的路径确定过程，通过遍历所有基本流和备用流，完成整个场景的覆盖。

场景主要分为四类：

• 正常用例场景
• 备选用例场景
• 异常用例场景
• 假定推测场景

很多人初次接触这些概念会觉得抽象，简单理解：

场景法就是在一个常规流程里，考虑某些环节可能出现的各种意外或分支情况 ——常规流程就是基本流，从各环节中延伸出的不同情况，就是备选流。场景法非常考验测试人员的发散思维。

下面以逛街买衣服为例，用生活化的方式讲解场景法的使用。

该方法能够生动地描绘出事件触发时的业务场景，便于测试设计者设计测试用例，让测试用例更易理解、更易执行。

其典型应用是通过业务流将各个孤立的功能点串联起来，帮助测试人员建立完整的业务认知，避免陷入单一功能细节而忽略整体业务流程要点的问题。

根据场景法设计测试用例的步骤：

1. 确定基本流
2. 分析并确定备选流
3. 结合备选流组合，补充测试场景与测试用例
4. 编写完整、可执行的测试用例

案例练习：邮箱注册接口

根据场景法设计测试用例的步骤：

1. 确定基本流
2. 分析并确定备选流
3. 结合备选流组合，补充测试场景与测试用例

4. 编写完整、可执行的测试用例：
   1. 输入正确的账号密码，点击注册后系统发出确认邮件并在 24H 内确认，注册成功。
   2. 不输入账号密码，点击注册，提示重新输入
   3. 只输入账号，不输入密码，点击注册，提示重新输入
   4. ……（剩余部分自己补充）

3. 更多测试用例练习：命令行程序（很少会见到）

上面已经介绍了测试用例的设计方法，并讲解了Web场景法用例设计。

接下来我们来看这么一种特殊情况：命令行程序。

针对命令行中可使用zip/unzip命令进行文件解压缩的功能，测试用例设计如下：

3.1 功能测试

对不同文件类型与场景进行验证：

1. 普通 txt 文件可正常生成 zip 压缩包
2. 图片、视频、已存在的 zip 文件可正常生成 zip 压缩包
3. 多个不同类型文件（混合文件）可正常生成 zip 压缩包
4. 空文件夹可正常生成 zip 压缩包
5. 错误命令的校验（如重复输入 zip、未指定压缩包文件名、未指定源文件等）
6. 其他命令参数的功能验证

3.2 界面测试

1. 文件压缩成功时，命令行提示信息是否清晰规范
2. 文件压缩报错时，命令行提示信息是否友好易懂

3.3 性能测试

1. 文件大小超过 1G时，是否可正常完成压缩
2. 文件大小超过 1G时，压缩耗时是否在合理范围内

3.4 兼容性测试

1. 验证 zip 工具可在 Windows、Linux、Mac 等多系统上正常使用

3.5 易用性测试

1. 验证 zip 命令提供帮助说明（如执行zip --help可展示使用方法）

3.6 安全性测试

1. 使用 zip 命令过程中不会泄露文件内容

4. 更多测试用例练习：web程序接口

这一部分属于是接口测试的内容，我们这里仅作测试用例的编写，不介绍接口测试的知识点。

4.1 接口测试用例设计思路

以一个博客详情页接口为例：

接口地址：http://192.168.47.135:8080/blog_system/blog?blogId=10

在命令行中，接口请求示例如下：

curl命令为我们提供了在命令行中快速请求并验证接口的能力。在此基础上，我们应如何为当前接口设计出完备的测试用例呢？

1. 不同的请求方式

• 以GET 方式请求接口，是否可以返回预期的响应数据
• 以POST 方式请求接口，是否可以返回预期的响应数据

2. 参数组合（如果接口需要拼参数的情况下）

• 空参数
• 多参数
• 少参数
• 参数对应的值为空 / 过长 / 特殊字符……

3. 不同的参数格式

• URL 拼参
• form-data 格式
• raw 格式等等

4. 接口性能

• 千万个请求同时发起，是否能够返回响应
• 并发情况下响应时间是否在大众接受范围内

5. Postman 接口测试工具使用教程

在对接口进行测试时，使用curl命令进行接口测试在操作上并不理想。实际工作中，我们常常使用接口测试工具来提升测试的质量和效率，常见的接口测试工具有Postman。

具体教程，可以看这篇博客：Postman 接口测试工具使用教程

6. 总结：

这篇博客，介绍了 设计测试用例的方法：

1. 基于需求的设计方法

   1. 明确需求中的功能点
   2. 结合万能公式的思想，设计测试用例
      万能公式：
      1. 功能测试
      2. 性能测试
      3. 界面测试
      4. 兼容性测试
      5. 易用性测试
      6. 安全测试

2. 具体的设计方法：

   1. 等价类
   2. 边界值
   3. 正交表法
   4. 判定表法
   5. 错误猜测法
   6. 场景法

   其中，用得比较多的是：等价类划分，边界值，场景法

3. 其他场景下，测试用例的编写方式

   1. 命令行程序
   2. web程序接口
   3. ……

4. Postman接口测试工具使用教程

回到上一篇博客：测试(9) - 测试用例篇

最后，如果这篇博客能帮到你的，请你点点赞，有写错了，写的不好的，欢迎评论指出，谢谢！