测试新人必看：6 种易上手的用例设计方法，快速搭建思路

​

🔥草莓熊Lotso：个人主页

❄️个人专栏：《C++知识分享》《Linux 入门到实践：零基础也能懂》

✨生活是默默的坚持，毅力是永久的享受。

🎬博主简介：

​

前言

如果说 “万能公式” 是设计测试用例的宏观框架，那么具体的设计方法就是填充这个框架的 “血肉”。面对复杂的业务逻辑和海量的输入组合，单纯依靠经验往往会顾此失彼。本文将带你深入学习业界公认的 6 大测试用例设计方法（等价类、边界值、正交法、判定表、场景法、错误猜测法），并结合 “邮箱注册” 等经典案例，教你如何在实战中精准、高效地设计出覆盖全面的测试用例集。

​

一.基于需求的设计方法

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

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

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

​

• 1.明确需求中的功能点：账号注册，账号登录
• 2.结合万能公式设计测试点

​

二.具体的设计方法

2.1 等价类

上述设计的测试用例，存在用例还未完全设计完成，“姓名必填，6~15位的字符类型”，这样⼀个

具体的需求如果我们直接使用穷举法来进行测试的话需要花费大量的时间，显然是不符合企业测试要求的。

• 等价类的出现就解决了穷举法不能解决的问题

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

2.1.1 等价类分类：

• 有效等价类：对于程序的规格说明书是合理的，有意义的输入数据构成的集合，利用有效等价类验证程序是否实现了规格说明书中所规定的功能和性能。
• 无效等价类：根据需求说明书，不满足需求的集合。

2.1.2 根据等价类设计测试用例的方法：

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

--学到这里我们下先对上面的一些用例进行完善

​

其它的一些地方与这个类似，大家可以自己下来再继续完善

缺点： 等价类只考虑输入域的分类，没有考虑输出域的组合，需要其它的设计方法补充

2.2 边界值

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

• 日常语言中的“边界”漏洞：考试完发成绩了，老师布置寒假作业：超过60分的，所有题目抄写1遍，低于60分的，所有题目抄写3遍。于是小明就没有写作业。因为他刚好60分

边界值包含：边界值+次边界值

• 输入框长度为1-11，取边界值为：1，11，12，0
• 运动员的参赛项目取1-3项，取边界值为：0项，1项，3项，4项
• 查询面页面有999行，每50行为一页，取边界值为：输出0行，1行，50行，51行，999行

​

继续将上述的用例通过边界值补充完整

​

2.3 场景法

场景法是模拟用户在实际使用软件过程中可能遇到的各种场景，通过对这些场景的分析来设计测试用例。这里的 “场景” 通常是指用户为了达到某个目标，在软件系统中进行的一系列操作步骤 。

场景法⼀般包含基本流和备用流，从⼀个流程开始，通过描述经过的路径来确定的过程，经过遍历所有的基本流和备用流来完成整个场景。场景主要包括4种主要的类型：正常的用例场景，备选的用例场景，异常的用例场景，假定推测的场景

应用步骤：

1. 确定业务流程：梳理软件系统所涉及的核心业务流程，例如电商系统中的商品浏览、加入购物车、结算支付、订单查询等流程 ；在线教育系统中的课程报名、学习、考试、成绩查询等流程。
2. 识别场景：根据业务流程，分析正常使用场景和异常使用场景。
   • 正常场景：用户按照系统预期的操作方式进行操作，顺利完成业务流程。比如在电商系统中，用户正常挑选商品、加入购物车、填写收货信息并成功支付。
   • 异常场景：考虑各种可能导致业务流程中断或出现错误的情况。例如，在支付环节网络中断、用户输入错误的支付密码、购物车中商品库存不足等。
3. 设计测试用例：针对每个识别出的场景，设计具体的测试用例，明确测试步骤、预期结果等。比如针对 “支付环节网络中断” 这个异常场景，测试步骤可以是在支付时手动关闭网络，预期结果是系统提示网络异常，并在网络恢复后能重新进行支付操作 。

​

优点：

1. 贴近实际：以用户实际使用场景为出发点，能更好地发现软件在真实使用环境下可能出现的问题，提高测试的有效性。
2. 全面覆盖：不仅能覆盖正常业务流程，还能充分考虑到各种异常情况，有助于提高测试覆盖率，减少软件上线后的故障风险 。

缺点：

1. 测试用例数量多：当业务流程复杂、场景多样时，可能会产生大量的测试用例，增加测试执行的时间和成本 。
2. 依赖经验：场景的识别和分析在一定程度上依赖测试人员的经验，经验不足可能导致部分重要场景被遗漏 。

我们再拿之前的邮箱注册用例来演示一下

​

​

补充测试小问题：

• 假设大家都是测试工程师，现在需要测试一个活动，这个活动每个月都要进行，但是每个月的福利是不一样的。

​

2.4 正交法

​

• 正交法的目的是为了减少用例的数目。用尽量少的用例覆盖输入的两两组合

2.4.1 正交表的构成和性质

正交表：

如图最简单的正交表是L(4)(2(3))，含意如下：“L”代表正交表；L 下角的数字“4”表示有 4 横行，

简称行，即要做四次试验；括号内的指数“3”表示有3 纵列，简称列，即最多允许安排的因素是3

个；括号内的数“2”=表示表的主要部分只有2 种数字，即因素有两种水平1与2。

​

正交表的构成：因素数、水平数、行数。

• 因素：对指标的影响条件，通常是正交表中的⼀列。
• 水平：因素对应的可选项。

正交表的性质：

• 每⼀列中，不同的数字出现的次数相等。
• 任意两列中数字的排列方式齐全而且均衡--这个看下图，对应的没有重复

​

2.4.2 正交表设计测试用例的步骤

根据正交表的性质，⼀般人很难通过手动设计出正交表；

正交表设计测试用例的步骤如下： 1.找到因素和水平，我们还是拿之前的邮箱注册为例

​

2.将因素和水平写入excel表格中(表格不需要保存）--不推荐其它软件，格式问题

​

3.在allpairs.exe同级文件下创建一个txt文件，将excel表格复制到txt中，不要有其它操作直接保存

4.使用allpairs.exe工具对txt生成正交表文件

​

5.根据生成好的正交表来编写测试用例，继续将重要的用例补全

​

2.5 判定表法

2.5.1 判定表法的介绍

通过具体的方法能够将测试用例设计的更加完整和规范。 需求中会存在各种各样的场景，现在我们把需求改成如下的要求： 用户输入的账号中包含admin字符，或者通过内部链接进入注册页面，提交注册按扭成为管理员身份；反之无管理员身份。

通过这个需求可以看出，不同的组合操作可能对应不同的结果。采用正交法无法解决这样的问题。而正交法能够解决需要考虑输入之间的组合关系对应不同结果的场景。

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

​

通过该图，可以把所有条件对应的结果清晰的表达出来。我们就需要借助该表来清晰的写出测试用

例。

2.5.2 判定表法设计测试用例

• 1.确认需求中输入条件和输出条件
• 2.找出输入条件和输出条件之间的关系
• 3.画判定表
• 4.根据判定表编写测试用例

确认了步骤后，我们使判定表法进一步对上述需求进行测试用例的设计：

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

• 输入条件：账号包含admin字符（a）、内部注册链接(b)、点击注册按钮(c)
• 输出条件：管理员（1）、无管理员（2）

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

输入条件：ac ab bc abc a b c 非abc 对应结果：1 2 1 1 2 2 2 2

3.画判定表

​

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

​

2.6 错误猜测法

错误猜测法是对被测试软件设计的理解，过往经验以及个人直觉，推测出软件可能存在的缺陷，从而针对性地设计测试用例的方法。

这个方法强调的是对被测试软件的需求理解以及设计实现的细节把握，还有个人的经验和直觉。

错误推测法和目前流行的“探索式测试方法”的基本思想⼀致，这类方法在敏捷开发模式下的投入产

出比很高，被广泛应用于测试

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

还是根据邮箱账号注册的案例，根据场景法来设计测试用例：

以注册为例

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

注意：笔试的时候编写测试用例需要使用传统的编写方式，须完整写出测试用例以及必要要素。

⾯试的时候只需要按照思维导图模式说出测试用例。

三.用例练习

--上面介绍了设计测试用例以及方法时介绍过web场景用例的设计。接下来看看不同题型用例的设计吧。

3.1 命名行程序

存在功能可以在命名行中使用zip/unzip命令对文件进行解压缩，这样的场景如何来设计测试用例

​

zip命令： 功能测试：

• 1）普通的txt文件能够生成zip文件
• 2）图片/视频/zip文件能够生成zip文件
• 3）多个文件能够生成zip文件（混合文件）
• 4）空文件夹可以生成zip文件
• 5）错误的命令是否可以解压（zip zip/没有写压缩包文件名称/没有源文件）
• 6）其他参数的测试

界面测试：

• 1）文件压缩成功命令行提示是否美观
• 2）文件压缩报错命令行提示是否友好

性能测试：

• 1）文件大小超过1G时文件是否可以压缩
• 2）文件大小超过1G时文件压缩消耗的时间是否在合理的时间范围内

兼容性测试：

• 1）zip工具可以在多系统上使用，如Windows、Linux、Mac

易⽤性测试：

• 1）zip命令有使用帮助教程，如zip --help命令下会展示如何使用

安全性测试：

• 1） 使用zip命令不会泄漏文件内容

3.2 web程序接口

我们现在对一个博客系统进行接口测试，现在我们来看看。

接口请求示例如下：

​

通过curl命令我们可以在命令行上请求接口，并对接口进行测试。

如何对当前接口进行测试呢？

对接口进行测试时，使用curl命令进行接口测试在操作上并不方便，实际在使用中我们常常使用接口测试工具来保证测试的质量和效率，这里推荐使用postman

整体操作流程图：

​

​

​

​

​

添加请求的方式：

1.手动填写

2.复制请求并添加到postman中

• 1）打开页面按开发者工具，选中要复制的接口，右键复制URL

​

• 2）打开postman，点击“import”按钮，选择"Raw text"⽅式导⼊请求，将复制好的URL粘贴到文本框中，选择“continue”

​

• 3）继续点击“import”

​

• 4）最终，接口被成功导⼊到postman中啦，基于上面设计好的用例，在postman上尝试执行测试。

​

3.接口管理

是否每次都要重新执行一遍填写请求的步骤呢？只需⼀步，就可以在postman中保存经常要使用到的接口

​

• 1.针对当前接口进行保存
• 2.选择保存的接口名称，可以⾃定义
• 3.选择想要保存的文件夹 最终，当前文件会被保存到example⽂件夹中
• 当我们下次想要测试某个接口时，只需要在“Collections”对应文件夹下找到接口即可。

​

结尾

往期回顾：

从 “懵圈” 到 “秒杀”：测试用例设计万能公式，小白也能直接套用！

结语：理论是行动的先导。这 6 种方法各有侧重，没有优劣之分。真正的高手，在于能够根据具体需求，灵活地选择和组合最适合的方法，将理论知识转化为解决实际问题的能力。不断练习和总结，你也能成为一名测试用例设计的架构师。

✨把这些内容吃透超牛的！放松下吧✨ ʕ˘ᴥ˘ʔ づきらど