软件测试用例（沉淀中）

本篇重点

测试⽤例的概念
设计测试⽤例的万能思路
设计测试⽤例的⽅法
◦ 基于需求的设计⽅法
◦ 具体的设计⽅法
▪ 等价类
▪ 边界值
▪ 判定表法
▪ 正交法
▪ 场景法
▪ 错误猜测法

1. 测试⽤例

1.1 概念

什么是测试⽤例？
测试⽤例（Test Case）是为了实施测试⽽向被测试的系统提供的⼀组集合，这组集合包含：测试环境、操作步骤、测试数据、预期结果等要素。
设计测试⽤例原则⼀：
测试⽤例中⼀个必需部分是对预期输出或结果进⾏定义
什么是要素？我们在编写测试⽤例的时候，每个⽤例需要给出这些要素对应的信息。

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

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

以下内容包括⽇常⽤例练习都是⽤思维导图/脑图进⾏编写。

重要
笔试的时候写测试用例题，需要按照excel表格的方式来答题（会涉及到测试用例的要素）
而面试的时候回答测试用例题，按照思维导图的方式一一到来即可。（不会涉及到测试用例要素）
eg：
execel

思维导图

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如何构造弱⽹条件

这里弱网设置的数字越大，传输速率越慢。
举例：打开京东的响应速度
当上行速率是350，下行速率是150.响应很迅速

当上行速率是3500，下行速率是1500.响应很慢

安装卸载测试
eg:
xmind,王者荣耀，微信，QQ，这些都会涉及到安装和卸载。
安装：安装包是否可以安装，卸载之后是否可以继续安装，重新安装…
软件更新后安装是否成功。
卸载：安装完成后卸载，安装一半进行卸载，卸载一次后继续安装继续卸载，卸载一半停止后是否还可以继续卸载…

针对需要进⾏部署的软件，除了软件功能外，我们还需要关注软件的能够成功安装和卸载
使⽤万能公式对⽔杯进⾏⽤例的设计

作业：请你对⽔杯设计测试⽤例

3. 设计测试⽤例的⽅法

3.1 基于需求的设计⽅法

基于需求的设计⽅法也是总的设计测试⽤例的⽅法，在⼯作中，我们需要参考需求⽂档/产品规格说明书来设计测试⽤例。
测试⼈员接到需求之后，要对需求进⾏分析和验证，从合理的需求中进⼀步分析细化需求，从细化的需求中找出测试点，根据这些测试点再去设计测试⽤例。
以该注册邮箱账号需求为例，我们来设计测试⽤例

基本事件流：通用流程，绝大多数用户的操作流程/主流程

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

提示：
1、在界面测试中，注册账号这类，可以思考到 协议界面，注册界面，激活界面，登录界面。
2、建议把弱网测试单独放在外面。
3、在易用性测试中，可以考虑到，数据兼容性，eg：手机号注册，微信注册，…邮箱注册。在这里，考虑邮箱注册之后，个人手机号是否可以登录。
eg：数据兼容性的其他例子：在网页有这样一句话，今天客流量300人，若今后数据增加到百万，千万等宽度，展示是否正常。

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

注册邮箱账号测试用例：

3.2 具体的设计⽅法

这些具体的方法旨在提高我们的测试思路+提高我们设计测试用例的能力

3.2.1 等价类

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

依据需求将输⼊（特殊情况下会考虑输出）划分为若⼲个等价类，从等价类中选出⼀个测试⽤例，如果 这个测试⽤例测试通过，则认为所代表的等价类测试通过，这样就可以⽤较少的测试⽤例达到尽量多的 功能覆盖，解决了不能穷举测试的问题。
⽣活中等价类的案例：
因材施教的例⼦:
原则上讲, ⽼师应该依据每个学⽣⾃⾝的情况, 指定符合的学习⽅案. 但是实际上学⽣太多⽼师管不过
来, 只能分成⼏类: 优等⽣强调知识⾯的扩展和综合能⼒的提升; 中等⽣强调夯实基础, 查缺补漏; 差等⽣强调 优先掌握重点, 暂时跳过难点…
思路：输⼊的集合是⽆穷的, 不能全都覆盖到

等价类分类：
• 有效等价类：对于程序的规格说明书是合理的、有意义的输⼊数据构成的集合，利⽤有效等价类验 证程序是否实现了规格说明中所规定的功能和性能 （测试软件是否做了应该做的）
• ⽆效等价类：根据需求说明书，不满⾜需求的集合。（是否做了其不应该做的）
根据等价类设计测试⽤例的⽅式：
1.确定有效等价类和⽆效等价类
2.编写测试⽤例，设计具体测试数据
练习：根据学到的边界值将上述未完成的⽤例进⾏完善

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

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⾏
   eg：
   边界值即给定返回的左数据和右数据
   选择次边界值的时候需要根据边界值的有效无效情况来定
   （1）若边界值为有效等价类中的数据，则次边界值为无效等价类中的边界。
   （2）若边界值为无效等价类中的数据，则次边界值为有效等价类的边界。

（1）有效范围是[6,15]
边界值： 6 15 （有效）
次边界值： 5 16 （无效）
（2）有效范围是(6,15)
边界值： 6 15 （无效）
次边界值：7 14 （有效）

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

根据边界值法把测试用例补齐：

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. 补充遗漏的重要测试⽤例
   继续以邮箱注册为例， 采⽤正交法补全剩下的测试⽤例。
5. 找到因素和⽔平
   因素：姓名、电⼦邮箱、密码、确认密码、验证码
   ⽔平：填写、不填写
6. ⽤allparis⼯具⽣成正交表
   
   
   （建议使用微软自带的Execel软件）

使用excel能保证顺序
a. 将因素和⽔平写⼊Excel表格中
b. allparis⽬录下创建新的⽂本⽂件0714.txt，复制Excel中的因素和⽔平，直接粘贴到⽂本中保
存并退出
c. 使⽤allparis命令⽣成正交表：allparis.exe 0714.txt>0714jg.txt（将⽣成的正交表数据放⼊
0714jg.txt⽂件中）

8. 根据正交表编写测试⽤例

9. 补充遗漏的重要测试⽤例

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

实践：
实际运用

文件夹显示


生成正交表：

根据正交表来编写测试用例：
（1）姓名填写，电子邮箱填写，密码填写，确认密码填写，验证码填写
（2）姓名填写，电子邮箱不填写，密码不填写，确认密码不填写，验证码不填写
（3）姓名不填写，电子邮箱填写，密码不填写，确认密码填写，验证码不填写
（4）姓名不填写，电子邮箱不填写，密码不填写，确认密码不填写，验证码填写
（5）姓名填写，电子邮箱填写，密码填写，确认密码不填写，验证码不填写
（6）姓名填写，电子邮箱不填写，密码不填写，确认密码填写，验证码填写
（7）姓名不填写，电子邮箱不填写，密码不填写，确认密码不填写，验证码不填写（全部不填写需要自己手动添加）

作业：请你对“淘宝购物⻋”设计测试⽤例

3.2.4 判定表法

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

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

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

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

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

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

3. 画判定表

4. 根据判定表编写测试⽤例
   确认了步骤后，我们使⽤判定表法进⼀步对上述需求进⾏测试⽤例的设计：

5. 确认需求中输⼊条件和输出条件
   输⼊条件：账号包含admin字符（a）、内部注册链接(b)、点击注册按钮©
   输出条件：管理员（1）、⽆管理员（2）

6. 找出输⼊条件和输出条件之间的关系
   输⼊条件：ac ab bc abc a b c ⾮abc
   对应结果：1 2 1 1 2 2 2 2

7. 画判定表

8. 

9. 根据判定表编写测试⽤例
   a. 账号包含admin，⾮内部注册链接，点击注册按钮，为管理员⾝份
   b. 账号包含admin，内部注册链接，不点击注册按钮，⾮管理员⾝份
   c. 账号不包含admin，内部注册链接，点击注册按钮，为管理员⾝份
   d. 账号包含admin，内部注册链接，点击注册按钮，为管理员⾝份
   e. 账号包含admin，⾮内部注册链接，不点击注册按钮，⾮管理员⾝份
   f. 账号不包含admin，⾮内部注册链接，点击注册按钮，⾮管理员⾝份
   g. 账号不包含admin，⾮内部注册链接，不点击注册按钮，⾮管理员⾝份

3.2.5 场景法

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

该⽅法可以⽐较⽣动地描绘出事件触发时的情景，有利于测试设计者设计测试⽤例，是测试⽤例更容
易理解和执⾏。
典型的应⽤是是⽤业务流把各个孤⽴的功能点串起来，为测试⼈员建⽴整体业务感觉，从⽽避免陷⼊
功能细节忽视业务流程要点的错误倾向

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

编写测试⽤例：
1.输⼊正确的账号密码，点击注册后系统发出确认邮件并在24H内确认，注册成功。
2.不输⼊账号密码，点击注册，提⽰重新输⼊
3.只输⼊账号，不输⼊密码，点击注册，提⽰重新输⼊
4…

结论：
新活动上线，旧活动不受影响（新增加的代码对旧代码没有影响）

3.2.6 错误猜测法

错误猜测法是对被测试软件设计的理解，过往经验以及个⼈直觉，推测出软件可能存在的缺陷，从⽽
针对性地设计测试⽤例的⽅法。
这个⽅法强调的是对被测试软件的需求理解以及设计实现的细节把握，还有个⼈的经验和直觉。
错误推测法和⽬前流⾏的“探索式测试⽅法”的基本思想⼀致，这类⽅法在敏捷开发模式下的投⼊产
出⽐很⾼，被⼴泛应⽤于测试。
当我们⼀提到某个⾮常熟悉的⼈的名字，脑海会⽴刻浮现对他的评价
“武⼤郎”：憨厚，⽼实，为⼈坦诚，乐于助⼈
“潘⾦莲”：美丽，“温柔”，“疼爱丈夫”，“善于交友”，“精通制⾐”
张三要去卖⽠

⽤例1：张三这⼈不实诚，⼩⼼他缺⽄少两
⽤例2：张三这⼈粗⼼，⼩⼼他的⽠被压坏了
⽤例3：张三这⼈⼩⽓，⼩⼼不要把他惹哭了
这个⽅法的缺点是难以系统化，并且过度依赖个⼈能⼒。
还是根据邮箱账号注册的案例，根据场景法来设计测试⽤例
案例：
以注册为例
1、校验中特殊字符空格的处理?
2、密码校验中的⼤⼩写？
3、姓名中的特殊字符？
4、密码发送是否明⽂
eg：
密码：是否加密，是否具有安全性
获取用户输入：是否存在SQL注入的情况
软件存在多版本：多版本都要测试
活动每个月都存在但是每个月的奖励不一样：兼容前面月份活动。
…

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

练习
“登陆功能”设计测试⽤例
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 web程序

博客系统是咱们在javase课程阶段练习过的项⽬，现在我们对博客系统的博客详情⻚接⼝进⾏测试⽤
例的设计
接⼝：http://192.168.47.135:8080/blog_system/blog?blogId=10
接⼝请求⽰例如下：

how如何打开开发者工具？
1、页面鼠标右键选择“检查”
2、通过快捷键：Ctrl+shift+i

对接口进行测试：http://192.168.47.135:8080/blog_system/blog?blogId=10 ](http://192.168.47.135:8080/blog_system/blog?blogId=10
请求方法：URL,请求参数，响应。
通过curl命令我们可以在命令⾏上请求接⼝，并对接⼝进⾏测试。
如何对当前接⼝设计测试⽤例呢

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

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

postman的使⽤
1.postman介绍
2.使⽤postman来发送请求

.请求类型。常⽤的有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”对应⽂件夹下找到接⼝即可。
eg：

扩展（Request Headers解析）
最重要的的是
user_token_header: eyJhbGciOiJIUzI1NiJ9.eyJpZCI6MiwidXNlck5hbWUiOiJsaXNpIiwiZXhwIjoxNzU3MjEyOTI5fQ.Su4bxNm2jqbu4054kZgelTfkfCEW-VTEwJDtanStnJs

（2）自定义认证头
Cookie 保存的是当前用户的登录状态。

（3）在postman上发表修改内容

练习1：请你对Linux命令“cd”设计测试⽤例

cd命令
功能测试：
功能：测试将当前工作目录改变到指定目录下
cd … 当前指令是否能切换到上级路径
cd+指定路径 是否能正常切换
cd +绝对路径 是否能正常切换
cd~ 是否能进入家目录
cd - 是否能返回最近访问目录
性能测试：
在弱网的情况下，能正常切换到指定目录下吗
cd大写能正常切换吗
cd后面不加空格能正常切换到指定目录下吗
cd指令在CentOS与Ubuntu能正常使用吗
切换到包含大量文件/子目录的目录：响应速度
连续多次快速切换目录：测试稳定性
切换到深层次：测试处理能力
易用性测试：
cd命令有使用帮助教程，如：使用help cd命令下会展示如何使用。
界面测试：
目录切换成功命令行提示是否美观
目录切换失败命令行提示是否友好
兼容性测试：
cd命令在多系统上使用，如Windows,Linux,mac
在不同shell环境下的测试：bash，zsh，sh，csh等
安全测试：
使用cd命令不会泄露文件内容
切换到包含敏感信息的系统目录是否受权限控制
使用cd命令是否可能触发路径遍历漏洞
切换到符号链接指向的受限目录时的权限检查

总结

以上就是软件测试 用例（沉淀中）的全部内容了，有很多练习及测试用例值得反复练习，喜欢博主写的内容可以一键三连，支持博主！！！！