测试——用例篇

目录

1. 测试用例

1.1 概念

2. 设计测试用例的万能公式

2.1 常规思考+逆向思维+发散性思维

2.2 万能公式 

3. 设计测试用例例的方法

3.1 基于需求的设计方法

​编辑

3.2 具体的设计方法

3.2.1 等价类

3.2.2 边界值

3.2.3 正交法

3.2.4 判定表法

3.2.5 场景法

3.2.6 错误猜测法

---

1. 测试用例

1.1 概念

什么是测试用例？

测试用例（Test Case）是为了实施测试而向被测试的系统提供的⼀组集合，这组集合包含：测试环境、操作步骤、测试数据、预期结果等要素

设计测试用例原则⼀：

测试用例中⼀个必需部分是对预期输出或结果进行定义

什么是要素？我们在编写测试⽤例的时候，每个⽤例需要给出这些要素对应的信息。

⽤例编号	test-01
标题	成功注册网易邮箱
测试⽅式	⼿⼯测试
功能模块	注册登陆

重要性	重要
测试前提	系统运⾏正常，邮件服务器已开启
测试环境	win10 Chrome版本103.0.5060.66（正式版本）（64位）
测试数据	邮箱地址：[e-mail] 密码：123456 ⼿机号：12312341234
测试步骤	1.打开⾕歌浏览器，输⼊⽹易注册地址：https://mail.163.com/register/index.htm 2.输⼊邮箱地址，密码，⼿机号，获取验证码并输⼊正确的验证码，勾选协议 3.点击注册按钮
期望结果	展现注册成功的结果⻚，并且使⽤刚注册的账号可以正常登陆并进⼊邮箱⾸⻚

为什么需要测试用例呢，不写测试用例可以进行测试吗？

测试中可能会遇到很多问题，诸如：

• 不知道是否较全⾯的测试了所有功能
• 测试的覆盖率⽆法衡量
• 对新版本的重复测试很难实施（即回归测试⽆法仅通过⼈⼯测试的方式进行历史功能的回归）
• 存在大量冗余测试影响测试效率

测试用例的出现就是解决这些问题。另外，测试用例的作用还可以避免测试⼈员被迫背锅~~

实际中产品出现问题，第⼀责任⼈首先想到的是测试为啥没有测到？

上面展示的是传统的编写测试用例的方式，我们在学习敏捷模型的时候了解到，如今大多数企业采⽤的都是思维导图的方式来编写测试用例。以下课程内容包括日常用例练习都是用思维导图/脑图进行编写。

2. 设计测试用例的万能公式

现在有⼀款产品，要求我们对“门锁”设计测试用例，假如你是测试⼈员，你会怎么设计呢？

可以看出，用例的设计最重要的⼀点是保证功能是正确的。上图给出的案例，在互联网企业中，这样去设计测试用例的非常少，缺乏经验的同学往往以这样的思路去设计。

2.1 常规思考+逆向思维+发散性思维

正确设计测试用例的思想：常规思维+逆向思维+发散性思维

设计测试用例的原则⼆：

1.测试用例的编写不仅应当根据有效和预料到的输⼊情况，而且也应该根据无效和未预料到的输⼊情况。

2.检查程序是否“未做其应该做的”仅是成功的⼀半，测试的另⼀半是检查程序是否“做了其不应该做的”。（是上⼀条原则的必然结果）

3.计划测试⼯作时不应默许假定不会发现错误

明白了设计测试用例是思维的正确还往往不够。

若仅仅通过头脑风暴去设计测试用例，那么当我们面对面试官时，能够想出来的用例是寥寥⽆⼏的，所以在设计测试用例的时候需要有思路的去设计。

2.2 万能公式 

设计测试用例的万能公式：功能测试+界面测试+性能测试+兼容性测试+易用性测试+安全测试。

功能测试

功能测试是⼀个试图发现程序与其外部规格说明之间存在不⼀致的过程。外部规格说明是⼀份从最终用户的角度对程序行为的精确描述。功能测试通常是⼀项黑盒操作。在进行功能测试时，需要对规格说明进行分析以提炼测试用例，本课程中讨论的具体设计测试用例的方法尤其适用于功能测试。然而，不仅是⼯作中还是面试中，可能会存在需求不明确的功能？这种情况下该如何进行功能测试？

• 查找其他相关⽂档，来帮助理解所要测试的产品需要完成的目标;
• 尽量多参加项目组内的会议，比如需求讨论、设计讨论、计划讨论等，能够加深对产品的理解;
• 召集相关⼈员，对你整理的结果进行讨论，通过评审后，这份文档就可以作为依据来设计你的case了;
• 如果是⼀款已经上线的产品，可以多使用产品，有不懂的问产品经理;
• 也可以去看历史bug，可以了解到⼀些需要关注的东西。

界面测试

对软件界面上所有的内容都需要进行测试。

要求：

• 整体界面、测试界面的实现与设计图要求⼀致。
• 界面元素测试：控件操作验证

性能测试

性能测试和功能测试的区别是：功能测试检查软件是否做了，而性能测试测试软件做的好不好。

兼容性测试

软件是部署在硬件系统之上，并依赖所需要的软件环境。如QQ可以在PC端打开，也可以在移动端打开；移动端⼜分为IOS系统和Android系统，且市面上⼿机⼜有不同的品牌、不同的机型、不同的版本。软件是否能够在不同的环境下正确运行需要测试⼈员进⾏验证。

问题：既然市⾯上有众多版本的机器，那么在执⾏兼容性测试时难道所有的机型都需要全面覆盖吗？

选取标准：

• 优先选择使⽤当前产品top级别的机型进⾏测试，实际在企业中，后台是可以获取到使⽤产品的机型，并以报表的形式统计在后台，供产品⼈员或其他⼈员制定策略参考。
• 选择主流的浏览器/机型进⾏测试

易用性测试

易用性测试的标准是检查产品是否具备简单易上⼿的属性。假如测试人员从来没有安装或使用过该产品，作为⼀个新用户，对当前产品是否能够快速适用产品的使用流程。

安全测试

安全测试和性能测试⼀样都是比较大的领域。常见的安全问题如：

• 隐私数据明文显示。
• 参数未强校验导致SQL注⼊。
• 越权：普通用户也可以执行管理员权限的操作

接下来继续尝试对门锁进⾏测试⽤例的设计，你能设计多少呢？

除了万能公式之外，还有⼀个比较常用的测试类型：弱网测试、安装卸载测试

弱网测试

弱网测试的目的就是尽可能保证用户体验，关注的关键点包括：

• 页面响应时间是否可以接受，关注包括热启动、冷启动时间、页面切换、前后台切换、⾸字时间，⾸屏时间等。
• 页面呈现是否完成⼀致。
• 超时⽂案是否符合定义，异常信息是否显⽰正常。
• 是否有超时重连。
• 安全⻆度：是否会发⽣dns劫持、登陆ip更换频繁、单点登陆异常等。
• ⼤流量事件分险：是否会在弱网下进行更新apk包、下载文件等大流量动作。

弱网需要借助⼯具来构造弱网，这⾥推荐使⽤fiddler

1. fiddler配置代理
2. fiddler进行抓包（桌⾯/移动端）
3. fiddler如何构造弱网条件

安装卸载测试

针对需要进行部署的软件，除了软件功能外，我们还需要关注软件的能够成功安装和卸载

3. 设计测试用例例的方法

3.1 基于需求的设计方法

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

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

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

1.明确需求中的功能点

        账号注册，账号登陆

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

3.2 具体的设计方法

3.2.1 等价类

上述设计的测试⽤例，存在用例还未完全设计完成，“姓名必填，6~15位的字符类型”，这样⼀个具体的需求该如何来设计测试用例呢？

测试的时候通过穷举法来测试6位、7位、8位......14位，15位是否测试通过，这样的方法能够满⾜测试的要求吗？若此时把范围从“6~15位”改成“6~150位呢”？试想⼀下这样⼀个简单的测试点需要测试多久呢，显然是不符合企业测试要求的。

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

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

⽣活中等价类的案例：

因材施教的例⼦:

原则上讲, ⽼师应该依据每个学⽣自身的情况, 指定符合的学习方案. 但是实际上学⽣太多⽼师管不过来, 只能分成几类: 优等⽣强调知识面的扩展和综合能力的提升; 中等生强调夯实基础, 查缺补漏; 差等⽣强调 优先掌握重点, 暂时跳过难点...

思路：输⼊的集合是无穷的, 不能全都覆盖到

 等价类分类：

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

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

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

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

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

3.2.2 边界值

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

⽇常语⾔中的"边界"漏洞。

考完试发成绩了, ⽼师布置寒假作业: 超过60分的, 所有题目抄写1遍, 低于60分的, 所有题目抄写3遍。

于是小明就没有写作业~~, 因为他刚好60分。

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

边界值即给定返回的左数据和右数据

选择次边界值的时候需要根据边界值的有效无效情况来定

1. 若边界值为有效等价类中的数据，则次边界值为无效等价类中的边界
2. 若边界值为无效等价类中的数据，则次边界值为有效等价类中的边界

• 输⼊框⻓度为1-11，取边界值为：1、11、12、0
• 运动员的参赛项⽬为1-3项，取边界值为：0项、1项、3项、4项
• 查询⾯⻚⾯有999⾏，每50⾏为一页，取边界值为：输出0⾏、1⾏、50⾏、51⾏、999⾏

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

3.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⼯具生成正交表

• 将因素和水平写入Excel表格中
• allparis⽬录下创建新的⽂本⽂件new.txt，复制Excel中的因素和水平，直接粘贴到⽂本中保存并退出
• 使⽤allparis命令⽣成正交表：allparis.exe new.txt>zhengjiao.txt

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

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

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

1. 找到因素和水平

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

2. 用allparis工具生成正交表

• 将因素和水平写⼊Excel表格中
• allparis目录下创建新的文本文件0714.txt，复制Excel中的因素和水平，直接粘贴到文本中保存并退出
• 使用allparis命令生成正交表：allparis.exe 0714.txt>0714jg.txt（将生成的正交表数据放入0714jg.txt文件中）

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

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

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

3.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，⾮内部注册链接，不点击注册按钮，⾮管理员⾝份

3.2.5 场景法

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

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

读完上面的概念是不是⼀脸懵，场景法就是⼀个常规的流程中，某些阶段可能会出现⼀些意想不到的情况，常规流程是基本流，从阶段中分析出来的不同情况被称之为备选流，场景法比较考验同学们的发散思维。

针对场景法给出⽣活中的案例。以逛街买衣服为例，讲讲场景法的使用⽅法。

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

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

案例：

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

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

1.确定基本流

2.确定备选流

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

4.编写测试用例

确定基本流和备用流后，编写测试用例：

1.基本流：点击注册同意协议，输⼊正确的信息，点击注册，成功激活

2.备用流：点击注册不同意协议，重新点击注册同意协议，输⼊正确的信息，点击注册，成功激活

3.备用流：点击注册不同意协议，重新点击注册同意协议，输⼊错误的信息，重新输入正确信息，点击注册，成功激活

4......

3.2.6 错误猜测法

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

这个方法强调的是对被测试软件的需求理解以及设计实现的细节把握，还有个人的经验和直觉。 错误推测法和目前流行的“探索式测试方法”的基本思想⼀致，这类方法在敏捷开发模式下的投⼊产出比很高，被⼴泛应用于测试。

当我们⼀提到某个非常熟悉的⼈的名字，脑海会⽴刻浮现对他的评价

“武⼤郎”：憨厚，⽼实，为⼈坦诚，乐于助⼈

“潘金莲”：美丽，“温柔”，“疼爱丈夫”，“善于交友”，“精通制⾐”

张三要去卖⽠

⽤例1：张三这⼈不实诚，小心他缺斤少两

⽤例2：张三这⼈粗心，小心他的瓜被压坏了

⽤例3：张三这人小气，小心不要把他惹哭了

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

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

 案例：

以注册为例

1、校验中特殊字符空格的处理?

2、密码校验中的大小写？

3、姓名中的特殊字符？

4、密码发送是否明文

 3.3 更多用例练习

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

3.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.3.2 接口

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

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

不同的请求方式：

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

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

1. 空参数
2. 多参数
3. 少参数
4. 参数对应的值为空/过⻓/特殊字符....

不同的参数格式：

1. url拼参
2. form-data格式
3. raw格式等等

接口性能：

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

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