软件测试：黑盒测试用例篇

本节课重点⽬标

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

一：测试⽤例

1.1 概念

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

设计测试⽤例原则⼀：
测试⽤例中⼀个必需部分是对预期输出或结果进⾏定义
什么是要素？我们在编写测试⽤例的时候，每个⽤例需要给出这些要素对应的信息。

通过excal编写和管理测试用例（以前）
现在都是思维导图使用Xmind

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

二：设计测试⽤例的万能公式（发散思维）

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

面试的时候设计测试用例题型考查的到底是测试用例的数量还是质量呢？
面试官通常就是一句哈，让你想测试用例，质量在短时间内是很难保证的，我们只用发散思维去做，数量越多越好。工作的时候，质量越多越好。

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

测试原则：不要假定产品没有质量问题
设计测试⽤例的原则⼆：
1.测试⽤例的编写不仅应当根据有效和预料到的输⼊情况，⽽且也应该根据⽆效和未预料到的输⼊情况。
2.检查程序是否“未做其应该做的”仅是成功的⼀半，测试的另⼀半是检查程序是否“做了其不应该做的”。（是上⼀条原则的必然结果）既要做应该做的，也要逆向去做不应该做的
3.计划测试⼯作时不应默许假定不会发现错误

2.2 万能公式

打开思维后，能够设计处理的测试用例会稍微多一点，但是没有正确的引导，设计出来的测试用例数量是不容乐观的
就比如这样：

有思维有引导
设计测试⽤例的万能公式：功能测试+界⾯测试+性能测试+兼容性测试+易⽤性测试+安全测试。
功能测试：从产品功能角度出发，验证产品功能正确性
界面测试：肉眼可以看到的都是界面，界面上所有的元素都需要测试，元素（锁的例子：大小，颜色，形状，材质）
性能测试：通常在极端的情况下测试，比如突然几千几万的客户端访问服务器，出现卡顿，响应时间太长，这就是性能不太好，
兼容性测试：如果是软件，那就看不同浏览器测试。不同版本兼容性，数据的兼容性
易用性测试：产品是否具备简单易上手的熟悉（引导教程）（方法教程）（用户说明数）
安全测试：安全测试和性能测试⼀样都是⽐较⼤的领域。常⻅的安全问题如：
隐私数据明⽂显⽰。
参数未强校验导致SQL注⼊。（用户给定恶意的输入内容，导致数据泄露）
越权：垂直越权：普通⽤⼾也可以执⾏管理员权限的操作。
      水平越权：不可以看到同等级的信息资料

做一个水杯测试用例

想要设计更多更好的测试用例：正确的思维+正确的方法+勤加练习

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

弱⽹测试（3G、2G以下，网络环境不太好）
就是我们在弱网情况下，我们做的软件前端，有没有应对的策略。
又因为我们需要制造弱网的情况，耗费的资源还是比较多，特定的手机、卡、环境
所以我们就需要使用抓包工具模拟弱网环境。

弱⽹测试的⽬的就是尽可能保证⽤⼾体验，关注的关键点包括：

1.⻚⾯响应时间是否可以接受，关注包括热启动、冷启动时间、⻚⾯切换、前后台切换、⾸字时间，⾸屏时间等。

2.⻚⾯呈现是否完成⼀致。

3.超时⽂案是否符合定义，异常信息是否显⽰正常。

4.是否有超时重连。

5.安全⻆度：是否会发⽣dns劫持、登陆ip更换频繁、单点登陆异常等。

6.⼤流量事件⻛险：是否会在弱⽹下进⾏更新apk包、下载⽂件等⼤流量动作。

弱⽹需要借助⼯具来构造弱⽹，这⾥推荐使⽤fiddler
1）fiddler配置代理
2）fiddler进⾏抓包（桌⾯/移动端）
3）fiddler如何构造弱⽹条件

然后ctrl+f搜索m_SimnulateModem设置弱网

安装卸载测试
检查是否可以安装
检查是否可以卸载
安装卸载后再重新安装，是否可以正常安装（卸载不干净）
卸载重装后，数据是否仍然保留

三：设计测试⽤例的⽅法

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

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

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

1.明确需求中的功能点

账号注册，账号登陆
2.结合万能公式设计测试点

在测试的时候，想要覆盖所有浏览器或者系统以及版本，基本是不可能的，执行兼容性测试的时候如何选择版本或者型号呢？
工作中有数据统计看板，获取到的使用频率最高的前几个版本，对这些版本测试进行。

上面的叫做根据测试用例先初步设计测试用例，而部分用例还需要细化
红色的需要细分

3.2 具体的设计⽅法

3.2.1 等价类

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

测试的时候通过穷举法来测试6位、7位、8位......14位，15位是否测试通过，这样的⽅法能够满⾜测试的要求吗？若此时把范围从“6~15位”改成“6~150位呢”？试想⼀下这样⼀个简单的测试点需要测试多久呢，显⽰是不符合企业测试要求的。
⽽等价类法的出现就解决了穷举法不能解决的问题

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

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

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

根据等价类设计测试⽤例的⽅式：

1.确定有效等价类和⽆效等价类

2.编写测试⽤例，设计具体测试数据
练习

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

3.2.2 边界值

边界值分析法就是对输⼊或输出的边界值进⾏测试的⼀种⿊盒测试⽅法。通常边界值分析法是作为对等价类划分法的补充，这种情况下，其测试⽤例来⾃等价类的边界

⽇常语⾔中的"边界"漏洞
考完试发成绩了, ⽼师布置寒假作业: 超过60分的, 所有题⽬抄写1遍, 低于60分的, 所有题⽬抄写3遍.于是⼩明就没有写作业~ 因为他刚好60分

边界值包含：边界值+次边界值
例子：
1）有效范围时[6,15]
边界值（有效）：6    15
此边界值（无效）：5，16
2）有效范围时（6，15）
边界值：6-15（无效）
此边界值：7 14（有效）
边界值即给定范围的左数据和右数据
次边界值，需要根据边界值的有效和无效情况来判断来定：
1）若边界值是有效等价类中的数据，则次边界值为无效类中的边界
2）若边界值是无效等价类中的数据，则次边界值为有效等价类中的边界值

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

正交表的构成：因素数、⽔平数、⾏数。

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

⽔平：因素对应的可选项

正交表的性质：
每⼀列中，不同的数字出现的次数相等。
任意两列中数字的排列⽅式⻬全⽽且均衡

如果水平不同就没办法使用
行数如何计算：正交表行数（N）=（水平数-1）* 因素数+1
正交表还是不好设计的，要保证性质，所以需要借助工具来完成。allparis
根据正交表实现用例的编写

步骤：
1：根据需求找到因素和水平
因素：姓名、电子邮箱、密码、确认密码、验证码
水平：填写、不填写
2：将因素和水平写入到Excel表格中（不需要保存）
使用微软自带的excal（因为allparis对文字要求很高，）

3：在allparis.exe同级下创建一个txt文件，将excal表格中的内容复制到txt文件中直接保存，不要有其他操作
4：使用allparis.exe工具对txt文件来生成正交表文件，使用命令行。

text.txt 源文件   result.txt 结果文件（正交表）（不需要提前创建，如果创建了一定要保证txt为空）
出现空行什么成功了

点击result.txt文件这就是我们的正交表

~ 表示：可以是任意水平
allpairs工具生成的正交表和实际的正交表有出入，但是不影响整体的情况
5：根据生成的正交表编写测试用例

3.2.4 判定表法

概念：
判定表法又称[决策表]，判定表法(Decision table)同因果图法一般也是一种表达逻辑判断的工具。
判定表是一种以表格形式分析和表达多逻辑条件下执行不同操作的工具。

它能够将复杂的问题按照各种可能的情况全部列举出来，因此，利用判定表能够设计出完整的测试用例集合。

例子：⽤⼾输⼊的账号中包含admin字符，或者通过内部链接进⼊注册⻚⾯，提交注册按钮成为管理员⾝份；反之⽆管理员⾝份。
根据判定表发设计测试用例的步骤：
1：确定需求中输入条件和输出条件
输入条件：账号包含admin1（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.编写测试⽤例（先写基本流、然后按顺序写备用流）

3.3 更多⽤例练习（zip/web）

上⾯介绍设计测试⽤例以及⽅法已经介绍过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命令不会泄漏⽂件内容
2）使用zip命令不会破坏源文件的内容

3.3.2 web程序

对接口进行编写测试用例
明确接口的组成、请求头、请求参数、返回数据（响应）

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

postman的使⽤
1.postman介绍

2.使⽤postman来发送请求

手动添加：
先geturl
然后填写Headers：

1.请求类型。常⽤的有GET，POST
2.请求URL。填写本次要请求的链接，
3.发送请求按钮。请求参数填写完成之后，尝试发⼀次请求。
4.请求参数：拼接URL上的参数
5.请求头：填写必要的校验参数
6.请求体：填写必要的参数
运行结果就出现200ok

还有一种方式将现有的请求自动导入 就是直接import
1）打开⻚⾯开发者⼯具，选中要复制的接⼝，右键复制URL

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

3）继续点击“import”（name会自动导入）

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