测试开发话题05---用例篇（2）

寻星探路

发布于 2025-12-17 19:29:11

1620

文章被收录于专栏：CSDN博客CSDN博客

一、设计测试用例的方法

1、基于需求的设计方法

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

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

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

1）明确需求中的功能点

账号注册，账号登陆

2）结合万能公式设计测试点

2、具体的设计方法

2.1等价类

上述设计的测试用例，存在用例还未完全设计完成，“姓名必填，6~15位的字符类型”，这样一个具体的需求该如何来设计测试用例呢？测试的时候通过穷举法来测试6位、7位、8位......14位，15位是否测试通过，这样的方法能够满足测试的要求吗？若此时把范围从“6~15位”改成“6~150位呢”？试想一下这样一个简单的测试点需要测试多久呢，显示是不符合企业测试要求的。而等价类法的出现就解决了穷举法不能解决的问题。

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

⽣活中等价类的案例：

因材施教的例子：原则上讲，老师应该依据每个学生自身的情况，指定符合的学习方案。但是实际上学生太多⽼师管不过来，只能分成几类：优等生强调知识面的扩展和综合能力的提升；中等生强调夯实基础，查缺补漏；差等生强调优先掌握重点，暂时跳过难点... 思路：输入的集合是无穷的，不能全都覆盖到。

等价类分类：

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

• 无效等价类：根据需求说明书，不满足需求的集合。

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

1）确定有效等价类和无效等价类

2）编写测试用例，设计具体测试数据

练习：根据学到的边界值将上述未完成的用例进行完善

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

2.2边界值

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

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

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

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

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

2.3正交法

通过等价类和边界值方法我们完成了部分用例的补充当前还剩下一个场景的用例未补充完成，“只填写部分选项”，这里到底要设计多少测试用例呢？通常来说，为了保证系统的测试覆盖率，我们首先能够想到的就是排列组合。假如当前有两个选项A和B，可以设计出都填写、都不填写、填写A、填写B四个测试用例（2²）。假如当前有三个选项A、B、C，通过设计可以得到8个测试用例（2³） ...... 当前可选的选项是5个，分别是，姓名、电子邮箱、密码、确认密码、验证码。按照排列组合设计出来的用例是32个.....

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

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

正交表：

如图最简单的正交表是L(4)(2(3))，含意如下：“L”代表正交表；L下角的数字“4”表示有4横行，简称行，即要做四次试验；括号内的指数“3”表示有3纵列，简称列，即最多允许安排的因素是3 个；括号内的数“2”表示表的主要部分只有2种数字，即因素有两种水平1与2。

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

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

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

正交表的性质：

• 每⼀列中，不同的数字出现的次数相等。

• 任意两列中数字的排列方式⻬全而且均衡

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

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

1. 找到因素和水平因素：姓名、电子邮箱、密码、确认密码、验证码水平：填写、不填写 2. 用allparis工具生成正交表 a. 将因素和水平写入Excel表格中 b. allparis目录下创建新的文本文件0714.txt，复制Excel中的因素和水平，直接粘贴到文本中保存并退出 c. 使用allparis命令生成正交表：allparis.exe0714.txt>0714jg.txt（将生成的正交表数据放入 0714jg.txt文件中）

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

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

#注：使用allparis生成的正交表和预期有出入，但是不影响我们用来设计测试用例。

2.4判定表法

通过具体的方法能够将测试用例设计的更加完整和规范。

需求中会存在各种各样的场景，现在我们把需求改成如下的要求：

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

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

判定表

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

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

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

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. 根据判定表编写测试⽤例

a. 账号包含admin，非内部注册链接，点击注册按钮，为管理员身份

b. 账号包含admin，内部注册链接，不点击注册按钮，非管理员身份

c. 账号不包含admin，内部注册链接，点击注册按钮，为管理员身份

d. 账号包含admin，内部注册链接，点击注册按钮，为管理员身份

e. 账号包含admin，非内部注册链接，不点击注册按钮，非管理员身份

f. 账号不包含admin，非内部注册链接，点击注册按钮，非管理员身份

g. 账号不包含admin，非内部注册链接，不点击注册按钮，非管理员身份

2.5场景法

现在的软件几乎都是用事件触发来控制流程的，事件触发时的情景便形成了场景，而同一事件不同的触发顺序和处理结果就形成事件流。

通过运用场景来对系统的功能点或业务流程的描述，从而提⾼测试效果的一种方法。用例场景来测试需求是指模拟特定场景边界发生的事情，通过事件来触发某个动作的发生，观察事件的最终结果，从而用来发现需求中存在的问题。我们通常以正常的用例场景分析开始，然后再着手其他的场景分析。场景法一般包含基本流和备用流，从一个流程开始，通过描述经过的路径来确定的过程，经过遍历所有的基本流和备用流来完成整个场景。场景主要包括4种主要的类型：正常的用例场景，备选的用例场景，异常的用例场景，假定推测的场景。

读完上面的概念是不是⼀脸懵（懵就对了，因为我也看不懂，简单来说），场景法就是一个常规的流程中，某些阶段可能会出现一些意想不到的情况，常规流程是基本流，从阶段中分析出来的不同情况被称之为备选流，场景法比较考验同学们的发散思维。针对场景法给出生活中的案例。以逛街买衣服为例，讲讲场景法的使用方法。

该方法可以比较生动地描绘出事件触发时的情景，有利于测试设计者设计测试用例，是测试用例更容易理解和执行。

典型的应用是是用业务流把各个孤立的功能点串起来，为测试人员建立整体业务感觉，从而避免陷入功能细节忽视业务流程要点的错误倾向

案例：

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

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

1）确定基本流

2）确定备选流

3）根据备选流补充测试用例

4）编写测试用例

编写测试用例：

1）输入正确的账号密码，点击注册后系统发出确认邮件并在24H内确认，注册成功。

2）不输入账号密码，点击注册，提示重新输入

3）只输入账号，不输入密码，点击注册，提示重新输入

4）......

2.6错误猜测法

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

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

错误推测法和目前流行的“探索式测试方法”的基本思想一致，这类方法在敏捷开发模式下的投入产出比很高，被广泛应用于测试。

当我们一提到某个非常熟悉的人的名字，脑海会立刻浮现对他的评价 “武大郎”：憨厚，老实，为人坦诚，乐于助人 “潘金莲”：美丽，“温柔”，“疼爱丈夫”，“善于交友”，“精通制衣” 张三要去卖瓜用例1：张三这人不实诚，小心他缺斤少两用例2：张三这人粗心，小心他的瓜被压坏了用例3：张三这人小气，小心不要把他惹哭了

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

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

案例：

以注册为例 1、校验中特殊字符空格的处理? 2、密码校验中的大小写？ 3、姓名中的特殊字符？ 4、密码发送是否明文
#注：笔试的时候编写测试用例需要使用传统的编写方式，须完整写出测试以例以及必要要素。面试的时候只需要按照思维导图模式说出测试用例。

3、更多用例练习

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

3.1命令行程序

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

zip命令 功能测试：对不同的文件类型进行测试 1）普通的txt文件能够生成zip文件 2）图片/视频/zip文件能够生成zip文件 3）多个文件能够生成zip文件（混合文件） 4）空文件夹可以生成zip文件 5）错误的命令是否可以解压（zipzip/没有写压缩包文件名称/没有源文件） 6）其他参数的测试 界面测试： 1）文件压缩成功命令行提示是否美观 2）文件压缩报错命令行提示是否友好 性能测试： 1）文件大小超过1G时文件是否可以压缩 2）文件大小超过1G时文件压缩消耗的时间是否在合理的时间范围内 兼容性测试： 1）zip工具可以在多系统上使用，如Windows、Linux、Mac 易用性测试： 1）zip命令有使用帮助教程，如zip--help命令下会展示如何使用 安全性： 1）使用zip命令不会泄漏文件内容

3.2web程序

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

如何对当前接口设计测试用例呢？

不同的请求⽅式：        
    1.以GET⽅式请求接⼝是否可以返回预期的响应数据        
    2.以POST⽅式请求接⼝是否可以返回数据    
参数组合（如果接⼝需要拼参数的情况下）：        
    1.空参数       
    2.多参数
    3.少参数
    4.参数对应的值为空/过⻓/特殊字符....
不同的参数格式：
    1.url拼参
    2.form-data格式
    3.raw格式等等
接⼝性能：
    1.⼀千万个请求同时发起，是否能够返回响应
    2.并发情况下响应时间是否在⼤众接受范围内

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