【测试】之测试用例篇

1. 测试用例

1.1 概念

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

例如：买了一个新电视 咱们需要测试一下
1.开机测试 2.切换频道 3.调一下分辨率 4.测试一下网络电视 5.蓝牙功能...
这些是我们买完电脑后一定会做的测试内容，而这些内容并不会写到纸上，以文字的形式展示出来，这里一条一条的表述是一个测试用例
软件中涉及到的特性太多了，仅仅通过头脑风暴是无法完成一次完整的测试。
编写测试用例，通过编写测试用例我可以想到要测试哪些内容，通过一次又一次的更新修改将测试用例写到完成功能覆盖更高即可
设计测试用例原则⼀：
测试用例中⼀个必需部分是对预期输出或结果进行定义
什么是要素？我们在编写测试用例的时候，每个用例需要给出这些要素对应的信息。

为什么需要测试用例呢，不写测试⽤例可以进行测试吗？
测试中可能会遇到很多问题，诸如：
• 不知道是否较全面的测试了所有功能
• 测试的覆盖率无法衡量
• 对新版本的重复测试很难实施（即回归测试⽆法仅通过人工测试的⽅式进行历史功能的回归）
• 存在⼤量冗余测试影响测试效率
测试用例的出现就是解决这些问题。另外，测试用例的作⽤还可以避免测试⼈员被迫背锅~~
实际中产品出现问题，第⼀责任⼈⾸先想到的是测试为啥没有测到？

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

早期纯用Excel完整编写、管理所有测试用例的方式用得多，现在这种纯Excel模式用得少了；现在主流是思维导图梳理用例思路，Excel仅用来编写、归档管理。

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

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

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

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

正确设计测试⽤例的思想：常规思维+逆向思维+发散性思维
设计测试⽤例的原则⼆：
1.测试⽤例的编写不仅应当根据有效和预料到的输⼊情况，⽽且也应该根据⽆效和未预料到的输⼊情 况。
2.检查程序是否"未做其应该做的"仅是成功的⼀半，测试的另⼀半是检查程序是否"做了其不应该
做的"。（是上⼀条原则的必然结果）
3.计划测试⼯作时不应默许假定不会发现错误

明白了设计测试用例是思维的正确还往往不够。
若仅仅通过头脑风暴去设计测试⽤例，那么当我们面对面试官时，能够想出来的用例是寥寥无几的， 所以在设计测试用例的时候需要有思路的去设计。

2.2 万能公式

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

1. 功能测试

从产品功能角度出发，验证功能是否正确；黑盒测试，对照用户规格说明；需求不明时查文档、参与会议、评审文档、体验产品、查看历史bug。

2. 界面测试

肉眼可见的所有界面元素都需测试；检查元素大小、颜色、形状、材质，界面与设计图一致，控件可正常操作。

3. 性能测试

验证极端场景；功能测试查"是否实现"，性能测试查"做得好不好"；关注响应、启动、切换速度等。

4. 兼容性测试

适配不同系统/软件版本、不同浏览器；优先测试用户TOP机型、主流机型/浏览器，不全部覆盖。

5. 易用性测试

产品简单易上手，新用户可快速适应；包含引导教程等。

6. 安全测试

1. 硬件：危险材质、气味
2. 软件：隐私数据加密存储、脱敏展示、接口数据安全
3. 常见风险：SQL注入、越权操作、登录密码加密

弱网测试

• 弱网测试的目的就是尽可能保证用户体验，关注的关键点包括： 页面响应时间是否可以接受，关注包括热启动、冷启动时间、页面切换、前后台切换、首字时间，首屏时间等。
• 页面呈现是否完成一致。
• 超时文案是否符合定义，异常信息是否显示正常。
• 是否有超时重连。
• 安全角度：是否会发生dns劫持、登陆ip更换频繁、单点登陆异常等。
• 大流量事件风险：是否会在弱网下进行更新apk包、下载文件等大流量动作。

Fiddler弱网测试操作步骤

1. 配置代理：设置Fiddler代理，使设备（桌面/移动端）流量经过Fiddler。
2. 抓包：开启抓包，捕获桌面端或移动端的网络请求数据。
3. 构造弱网条件：通过Fiddler设置上传、下载速率，模拟弱网环境。

1. 下行速度（下载速度） 你接收数据的速度

场景：刷视频、加载页面、接收图片、APP 获取服务器数据

Fiddler 对应：response‑trickle‑delay（图里 150ms），数值越大，下载越慢

2. 上行速度（上传速度） 你发送数据的速度

场景：发消息、发图片、提交表单、登录、上传文件

Fiddler 对应：request‑trickle‑delay（图里 300ms），数值越大，上传越慢

安装卸载测试

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

例如：QQ、王者荣和平精英、抖音、快手这些软件都会涉及到安装和卸载
安装:安装包是否可以安装、卸载之后是否可以继续安装、重复安装...软件更新后安装是否成功。
卸载:安装完成后卸载、安装一般后卸载、卸载一次后继续安装继续卸载、卸载一般停止后是否还可以继续卸载.....

练习使用万能公式对水杯进行用例的设计

3. 设计测试用例的方法

3.1 基于需求的设计方法

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

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

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

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

上面叫做根据需求文档先设计初步的测试用例，而部分用例还需要细化，就需要借助具体的设计方法

3.2 具体的设计方法

3.2.1 等价类

上述设计的测试⽤例，存在⽤例还未完全设计完成，"姓名必填，6~15位的字符类型"，这样⼀个
具体的需求该如何来设计测试⽤例呢？
测试的时候通过穷举法来测试6位、7位、8位......14位，15位是否测试通过，这样的⽅法能够满⾜测试的要求吗？若此时把范围从"6~15位"改成"6~150位呢"？试想⼀下这样⼀个简单的测试点需要
测试多久呢，显⽰是不符合企业测试要求的。
而等价类法的出现就解决了穷举法不能解决的问题
依据需求将输⼊（特殊情况下会考虑输出）划分为若⼲个等价类，从等价类中选出⼀个测试⽤例，如果 这个测试⽤例测试通过，则认为所代表的等价类测试通过，这样就可以⽤较少的测试⽤例达到尽量多的 功能覆盖，解决了不能穷举测试的问题。
⽣活中等价类的案例：

因材施教的例⼦: 原则上讲, ⽼师应该依据每个学⽣⾃⾝的情况, 指定符合的学习⽅案. 但是实际上学⽣太多⽼师管不过 来, 只能分成⼏类: 优等⽣强调知识⾯的扩展和综合能⼒的提升; 中等⽣强调夯实基础, 查缺补漏; 差等⽣强调 优先掌握重点, 暂时跳过难点...

思路：输⼊的集合是⽆穷的, 不能全都覆盖到
等价类分类：

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

根据等价类设计测试⽤例的⽅式：
1.确定有效等价类和⽆效等价类
2.编写测试⽤例，设计具体测试数据
练习：根据学到的边界值将上述未完成的⽤例进⾏完善

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

有效等价类：6~15 位

无效等价类：小于6位、大于15位

3.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⾏
   继续将上述⽤例通过边界值补充完整
   
   

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⼯具⽣成正交表

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

• 3. 根据正交表编写测试⽤例
• 4. 补充遗漏的重要测试⽤例

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

1. 找到因素和⽔平
   因素：姓名、电⼦邮箱、密码、确认密码、验证码
   ⽔平：填写、不填写
2. ⽤allparis⼯具⽣成正交表
   a. 将因素和⽔平写⼊Excel表格中
   b. allparis⽬录下创建新的⽂本⽂件0714.txt，复制Excel中的因素和⽔平，直接粘贴到⽂本中保存并退出
   c. 使⽤allparis命令⽣成正交表：allparis.exe 0714.txt>0714jg.txt（将⽣成的正交表数据放⼊
   0714jg.txt⽂件中）
   步骤演示
   

2.将因素和水平写入到excel表格中（表格不需要保存）

建议使用微软自带的Excel软件，有些同学电脑上有wps、其他的excel工具(不建议使用)
使用excel可以保证格式是正确的
3.在allparis.exe同级文件夹下创建一个txt文件，将excel表格中的内容复制到txt文件中，不要有其他的操作直接保持文件

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


~：表示可以是任意的选项：填写/不填写

1. pairings含义：这条测试用例，覆盖了多少组两个因素的两两组合。
2. 数字越大越好：数值越大，这条用例覆盖的测试场景越多。
3. 作用：allpairs靠它优先筛选高效用例，用最少用例，实现两两组合全覆盖。
   注意：
   

练习：淘宝购物车"设计测试用例

3.2.4 判定表法

通过具体的⽅法能够将测试⽤例设计的更加完整和规范。
需求中会存在各种各样的场景，现在我们把需求改成如下的要求：
用户输⼊的账号中包含admin字符，或者通过内部链接进⼊注册⻚⾯，提交注册按钮成为管理员⾝
份；反之⽆管理员⾝份。
通过这个需求可以看出，不同的组合操作可能对应不同的结果。采用正交法无法解决这样的问题。而正交法能够解决需要考虑输⼊之间的组合关系对应不同结果的场景。
判定表
判定表是⼀种表达逻辑判断的工具，形如：

通过该图，可以把所有条件对应的结果清晰的表达出来。我们就需要借助该表来清晰的写出测试⽤
例。
1.感觉疲倦，但是不感兴趣
2.感觉疲倦，有兴趣
3.不疲劳，感兴趣
.....(没有判定表，写出来的用例组合非常凌乱，思路不清晰)
根据判定表法设计测试用例的步骤：

1. 确认需求中输⼊条件和输出条件
   输入:账户包含admin字符，内部链接进入注册页面，提交注册按钮
   输出:管理员/无管理员
2. 找出输入条件和输出条件之间的关系
   
3. 画判定表
   
4. 根据判定表编写测试用例
   用例 1：账户包含 admin、非内部链接进入注册、点击提交注册按钮 → 输出为管理员
   用例 2：账户不包含 admin、内部链接进入注册、点击提交注册按钮 → 输出为管理员
   用例 3：账户包含 admin、内部链接进入注册、不点击提交注册按钮 → 输出为无管理员
   用例 4：账户包含 admin、内部链接进入注册、点击提交注册按钮 → 输出为管理员
   用例 5：账户不包含 admin、非内部链接进入注册、不点击提交注册按钮 → 输出为无管理员
   用例 6：账户包含 admin、非内部链接进入注册、不点击提交注册按钮 → 输出为无管理员
   用例 7：账户不包含 admin、内部链接进入注册、不点击提交注册按钮 → 输出为无管理员
   用例 8：账户不包含 admin、非内部链接进入注册、点击提交注册按钮 → 输出为无管理员

3.2.5 场景法

现在的软件⼏乎都是⽤事件触发来控制流程的，事件触发时的情景便形成了场景，⽽同⼀事件不同的触发顺序和处理结果就形成事件流。
通过运⽤场景来对系统的功能点或业务流程的描述，从⽽提⾼测试效果的⼀种⽅法。⽤例场景来测试需求是指模拟特定场景边界发⽣的事情，通过事件来触发某个动作的发⽣，观察事件的最终结果，从⽽⽤来发现需求中存在的问题。我们通常以正常的⽤例场景分析开始，然后再着⼿其他的场景分析。 场景法⼀般包含基本流和备⽤流，从⼀个流程开始，通过描述经过的路径来确定的过程，经过遍历所有的基本流和备⽤流来完成整个场景。场景主要包括4种主要的类型：正常的⽤例场景，备选的⽤例场景，异常的⽤例场景，假定推测的场景。
读完上⾯的概念是不是⼀脸懵，场景法就是⼀个常规的流程中，某些阶段可能会出现⼀些意想不到的
情况，常规流程是基本流，从阶段中分析出来的不同情况被称之为备选流，场景法⽐较考验同学们的
发散思维。
针对场景法给出⽣活中的案例。以逛街买⾐服为例，讲讲场景法的使⽤⽅法。

该⽅法可以⽐较⽣动地描绘出事件触发时的情景，有利于测试设计者设计测试⽤例，是测试⽤例更容易理解和执⾏。

案例：
还是根据邮箱账号注册的案例，根据场景法来设计测试⽤例TODO
根据场景法设计测试⽤例的步骤
1.确定基本流
2.确定备选流
3.根据备选流补充测试⽤例
4.编写测试⽤例

编写测试⽤例：
1.输⼊正确的账号密码，点击注册后系统发出确认邮件并在24H内确认，注册成功。
2.不输⼊账号密码，点击注册，提⽰重新输⼊
3.只输⼊账号，不输⼊密码，点击注册，提⽰重新输⼊
4. 输入正确账号密码，点击注册发送确认邮件，收到邮件后确认非最新邮件，注册失败
5.输入已注册账号，点击注册，提示重新输入
6.输入正确账号密码，点击注册，发送确认邮件时网络异常，发送邮件失败，注册失败
7.输入正确账号密码，点击注册，发送确认邮件时网络异常，邮件接收失败，注册失败
8.输入正确账号密码，点击注册，发送确认邮件时网络异常，客户端收到邮件但服务端发送状态失败，注册失败
9.输入正确账号密码，点击注册，收到确认邮件，未在24小时内确认，注册失败
10.输入正确账号密码，点击注册，收到多封确认邮件，确认的不是最新邮件，注册失败

3.2.6 错误猜测法

错误猜测法是对被测试软件设计的理解，过往经验以及个⼈直觉，推测出软件可能存在的缺陷，从而针对性地设计测试⽤例的⽅法。
这个⽅法强调的是对被测试软件的需求理解以及设计实现的细节把握，还有个⼈的经验和直觉。
错误推测法和⽬前流⾏的"探索式测试⽅法"的基本思想⼀致，这类⽅法在敏捷开发模式下的投⼊产
出⽐很⾼，被⼴泛应⽤于测试。
当我们⼀提到某个⾮常熟悉的⼈的名字，脑海会⽴刻浮现对他的评价
"武⼤郎"：憨厚，⽼实，为⼈坦诚，乐于助⼈
"潘⾦莲"：美丽，"温柔"，"疼爱丈夫"，"善于交友"，"精通制⾐"
张三要去卖⽠
⽤例1：张三这⼈不实诚，⼩⼼他缺⽄少两
⽤例2：张三这⼈粗⼼，⼩⼼他的⽠被压坏了
⽤例3：张三这⼈⼩⽓，⼩⼼不要把他惹哭了
这个⽅法的缺点是难以系统化，并且过度依赖个⼈能⼒。
还是根据邮箱账号注册的案例，根据场景法来设计测试⽤例
案例：
以注册为例

1. 输入账号 / 密码包含空格、特殊字符，校验系统是否正常识别、过滤或提示非法字符
2. 密码输入区分大小写，验证系统是否严格区分密码大小写、登录校验是否一致
3. 姓名输入特殊字符、表情、符号，校验系统是否支持 / 拦截非法格式
4. 检查密码传输、存储是否为密文加密，禁止明文传输，验证密码安全性
5. 测试账号、密码输入框，是否存在SQL 注入漏洞
6. 软件多版本环境，分别在旧版、新版客户端测试注册功能兼容性
7. 注册关联月度活动，验证当月奖励正常发放，同时兼容历史月份活动规则

注意：笔试的时候编写测试⽤例需要使⽤传统的编写⽅式，须完整写出测试⽤例以及必要要素。
⾯试的时候只需要按照思维导图模式说出测试⽤例。

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命令不会泄漏⽂件内容

练习：请你对Linux命令"cd"设计测试用例

一、功能测试

1. 切换到当前目录上级目录
2. 切换到根目录
3. 切换指定绝对路径目录
4. 切换相对路径目录
5. 切换到家目录
6. 返回上一次所在目录
7. 进入带空格名称的目录
8. 进入多级嵌套目录

二、界面测试

1. 切换后命令行路径提示符同步更新
2. 命令执行无乱码、格式显示正常
3. 报错提示文字清晰易懂

三、性能测试

1. 频繁来回切换目录响应无延迟
2. 进入深层目录执行速度正常

四、兼容性测试

1. 主流 Linux 发行版均可正常执行
2. 不同 Shell 环境适配运行
3. 大小写目录名切换符合系统规则

五、安全测试

1. 无权限目录无法进入，权限校验生效
2. 无法通过命令跳转访问受限系统目录
3. 恶意特殊字符路径执行拦截报错

六、易用测试

1. 基础简短命令输入即可完成跳转
2. 路径补全功能可辅助快速切换

---

postman的使用

使用postman来发送请求

1.请求类型。常⽤的有GET，POST
2.请求URL。填写本次要请求的链接，如：https://www.bitejiuyeke.com/index
3.发送请求按钮。请求参数填写完成之后，尝试发⼀次请求。
4.请求参数：拼接URL上的参数
5.请求头：填写必要的校验参数
6.请求体：填写必要的参数
添加请求的⽅式：
1.手动填写
2.复制请求并添加到postman中
1）打开页面开发者工具，选中要复制的接口，右键复制URL

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

3）继续点击"import"

4）最终，接⼝被成功导⼊到postman中啦

基于上面设计好的用例，在postman上尝试执行测试。
3.接口管理
是否每次都要重新执⾏⼀遍填写请求的步骤呢？只需⼀步，就可以在postman中保存经常要使⽤到
的接口

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