软件测试——用例篇

在前一篇文章中软件测试——Bug篇-CSDN博客，我们学习到了bug的相关知识，这一篇将教大家如何设计测试用例去寻找bug。

本节课重点目标

• 测试用例的概念
• 设计测试用例的万能思路设计测试用例的方法
• 基于需求的设计方法
• 具体的设计方法
  1. 等价类
  2. 边界值
  3. 判定表法
  4. 正交法
  5. 场景法
  6. 错误猜测法

1. 测试用例

什么是测试用例？

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

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

比如说，我们现在新买了一个电视 ，要对这个电视进行测试

对电视设计测试用例，往往是根据个人经验，比如：测试能否正常开机，测试能否切换频道，调整分辨率，测试网络功能是否可以使用，测试蓝牙功能等等。我们往往不会将要测试的内容写在纸上，或者以文字的形式记录下来。

但是当我们测试软件时，涉及到的特性太多，仅通过头脑风暴是无法完成一次完整的测试的。所以我们就需要编写测试案例，将想到测试的内容记录下来，并且可以一次次更新测试用例，使得测试的功能覆盖率更高即可。

编写测试用例也是有讲究的，每一个测试用例的编写如下：

当有多个测试用例时，使用excel表格方式编写测试用例，如下：

使用excel表格来编写和管理测试用例时非常的麻烦，这种方式在以前使用的比较多，而现在使用的比较多的是思维导图的方式，思维导图可以直观清晰的展示测试案例。

• 在笔试的时候编写测试用例题，需要按照excel表格的形式来回答（设计到测试用例的要素）
• 而面试的时候回答测试用例题，按照思维导图的方式来回答即可（不涉及测试用例的要素）

所以说，虽然在工作中不使用excel表格了，但是我们需要笔试，所以还是需要了解一下。

使用思维导图编写测试案例，如下：

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

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

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

测试用例的出现就是解决这些问题。

2. 如何设计测试用例

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

你可能会根据门锁的功能，质量尺寸等设计测试用例，如下：

如上能够设计的测试用例整体来说，测试用例不够具体，太笼统了，正常的测试工作中是不会这样设计测试用例的。

2.1 设计测试用例的思维

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

设计测试用例的原则⼆：

• 1.测试用例的编写不仅应当根据有效和预料到的输入情况，而且也应该根据无效和未预料到的输入情况。
• 2.检查程序是否“未做其应该做的”仅是成功的⼀半，测试的另⼀半是检查程序是否“做了其不应该做的”。（是上⼀条原则的必然结果）
• 3.计划测试工作时不应默许假定不会发现错误。

根据上面的思想，我们可以将门锁的测试用例中的功能部分进行如下扩展，是不是一下就多了很多可以写的。

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

2.2 万能公式

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

功能测试

功能测试是⼀个试图发现程序与其外部规格说明之间存在不⼀致的过程。外部规格说明是⼀份从最终用户的角度对程序行为的精确描述。功能测试通常是⼀项黑盒操作。在进行功能测试时，需要对规格说明进行分析以提炼测试用例，本文中讨论的具体设计测试用例的方法尤其适用于功能测试。

然而，不仅是工作中还是面试中，可能会存在需求不明确的功能？这种情况下该如何进行功能测试？

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

界面测试

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

• 整体界面测试界面的实现与设计图要求⼀致。
• 界面中所有元素都需要测试

性能测试

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

兼容性测试

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

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

选取标准：

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

易用性测试

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

安全测试

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

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

根据万能公式，尝试对水杯进行测试用例的设计，你能设计多少呢？

有了大概方向，我们就可以详细的设计测试案例了。

可以看到使用万能公式设计测试用例时，可以设计的的用例就非常多，并且是非常全面的。

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

2.3 弱网测试

弱网测试的目的就是尽可能保证用户体验（为了覆盖各种网络场景），关注的关键点包括：

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

那么，如果说我要在2G的环境下测试，那么就需要一张2G的手机卡；如果要在3G的环境中测试，需要一张3G的手机卡，那么在测试时就需要很多个手机，非常麻烦。但是实际上是不需要这样做的，只需要用一台设备模拟出2G/3G环境即可，这里推荐使用fiddler。

在未使用抓包软件对网络进行限速时，打开csdn大概只需要1,2秒就能加载出所有的页面，现在我们对csdn进行限速抓取。

1.先打开弱网设置

2.更改弱网脚本（设置速度）

3.使用Ctrl+f搜索m_simulateModem

4.更改上行和下行速度，上行速率指的是请求发送到服务器的速率，下行速率指的是将服务器响应给客户的速率。这个速率指的是传输1kb需要多少ms（所以上行/下行数字越小，速度越快）

我们将上行速率改成1000，下行速率改成1500

改好了之后，重新csdn，可以发现过了一分钟才能显示出来，前一分钟网页一直处于加载中，并没有出现什么错误，在加载完成后，页面可以完整的显示出来，所以csdn在弱网环境下是没什么问题的。

以上就是通过抓包工具来模拟弱网环境。

2.4 安装卸载测试

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

比如说微信，QQ等软件，都会涉及到安装和卸载，那么我们需要考虑：

• 安装：安装包是否可以安装，卸载之后是否可以重新安装，能否重复安装，软件更新后安装是否成功等.......
• 卸载：安装完成后卸载，安装一半后卸载，卸载一次后继续安装再卸载，卸载一半后停止是否还可以继续卸载等.....

3. 设计测试用例的方法

3.1 基于需求的设计方法

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

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

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

1.在阅读了需求文档后，我们可以明确需求中的功能点：账号注册，账号登陆。

2.根据万能公式，设计测试案例

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

3.2 具体的设计方法

3.2.1 等价类

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

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

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

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

在生活中也有等价类的例子，比如老师在上课时，会随机喊一个人问他听懂了吗，如果这个人回答听懂了，那么老师就会认为整个班的人都听懂了。

等价类分类：

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

比如在“姓名必填，6~15位的字符类型”这个例子中，姓名在6-15的就是有效等价类，姓名小于6位或者大于15位的就是无效等价类。

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

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

3.2.2 边界值

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

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

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

边界值即为给定的范围中的左数据和右数据，在选择边界值时需要根据边界值的有效无效情况来定。

• 1）如果边界值为有效等价类中的数据，则次边界值为无效等价类中的边界。
• 2）如果边界值为无效等价类中的数据，则次边界值为有效等价类中的边界。

比如说，取值范围在[6, 15] （数学中的闭区间，即6 <= x <= 15），求边界值和次边界值

那么边界值就是6和15，次边界值根据边界值的情况决定，边界值是有效等价类中的，所以次边界值就要取无效等价类，所以次边界值就是5和16。

再比如，取值范围在(6, 15) （数学中的开区间，即6 < x < 15)，求边界值和次边界值

边界值是6和15，由于边界值        取得是无效等价类中的数据，所以次边界值就要去有效等价类的边界，即7和14。

通过边界值和此边界值，我们就能对上面的“姓名必填，6~15位的字符类型”进行扩充。

除了边界值和此边界值，还可以取一些其他的数据，如上面的10位字符，1位字符和20位字符，保证边界值以外的区域是没问题的。

3.2.3 正交法

通过等价类和边界值方法我们完成了部分用例的补充

当前还剩下⼀个场景的用例未补充完成，“只填写部分选项”，这里到底要设计多少测试用例呢？通常来说，为了保证系统的测试覆盖率，我们⾸先能够想到的就是排列组合。

假如当前有两个选项A和B，可以设计出都填写、都不填写、填写A、填写B四个测试用例（2²）。假如当前有三个选项A、B、C，通过设计可以得到8个测试用例（2³）。假如当前可选的选项是5个，分别是，姓名、电子邮箱、密码、确认密码、验证码，按照排列组合设计出来的用例是32个.....

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

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

3.2.3.1 认识正交表

• 红框内的叫做表头，表头中的每一项叫做因素，表示存在的条件，上图中一共有11种因素。
• 绿框中的是每个因素对应的数据，称之为水平。
• 蓝框内的是行号，表示一共有多少行。

3.2.3.2 正交表的写法

如图最简单的正交表是L4(2³)，含意如下：

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

那么上面的正交表就可以写成L12(2¹¹)。

3.2.3.3 正交表的特性

• 每⼀列中，不同的数字出现的次数相等。
• 任意两列中数字的排列方式齐全而且均衡（每一列中每个数字出现出现的次数是相同的）。

3.2.3.4 设计正交表

根据正交表的性质，一般人很难通过手动设计出正交表，所以我们需要借助allpairs工具来实现。

下载链接：Windows Search: allpairs

下载好就是下面这样的

此时点击allpairs.exe应用程序没什么反应，那是因为allpairs工具不是这样使用的。

正确的使用方式：（以选项为5个，分别是，姓名、电⼦邮箱、密码、确认密码、验证码为例）。

1）根据需求确定因素以及水平

2）将因素和水平写入到excel表格中（建议使用微软自带的excel）

3）在allparis.exe同级文件夹下创建一个txt文件，将excel表格中的内容复制到txt文件中

4）使用allparis.exe工具对txt文件生成正交表

在当前目录下打开cmd

在cmd下输入allpairs.exe test01.txt > res-test01.txt。

生成了正交表

其中的~表示的是任意选项，所以~填写既可以表示填写也可以表示不填写。

allparis工具生成的正交表和实际的正交表会有一定的出入（如上图中的~填写，如果都为填写，则第一列的填写数量比不填写多），但是不影响整体的情况。

5）根据生成好的正交表来编写测试用例，继续将重要的用例补全

前面6个是根据正交表填写出来的，第7个是我们自己补充的。

那么现在就可以将原来的32（2^5）个测试用例缩减到7个了。

注意：

为什么一定要使用excel，而不直接在txt文件中编写因素和水平？因为allparis工具对格式的要求非常严格，使用命令生成正交表会存在格式校验错误的情况。

3.3.4 判定表法

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

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

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

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

判定表

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

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

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

• 1. 确认需求中输入条件和输出条件
• 2. 找出输入条件和输出条件之间的关系
• 3. 画判定表
• 4. 根据判定表编写测试用例

确认了步骤后，我们使用判定表法进⼀步对上述需求进行测试用例的设计：

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

                输入条件：账号包含admin字符（a）、内部注册链接(b)、点击注册按钮(c)

                输出条件：管理员（1）、无管理员（0）

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

                输入条件的组合：ac，bc，ab，abc，非abc，a，b，c

                对应的输出结果： 1，  1， 0，   1，     0，    0， 0， 0

• 3.画判定表        
• 4.根据判定表编写测试用例

1. 账号包含admin，非内部注册链接，点击注册按钮，为管理员身份
2. 账号包含admin，内部注册链接，不点击注册按钮，非管理员身份
3. 账号不包含admin，内部注册链接，点击注册按钮，为管理员身份
4. 账号包含admin，内部注册链接，点击注册按钮，为管理员身份
5. 账号包含admin，非内部注册链接，不点击注册按钮，非管理员身份
6. 账号不包含admin，非内部注册链接，点击注册按钮，非管理员身份
7. 账号不包含admin，非内部注册链接，不点击注册按钮，非管理员身份

3.3.5 场景法

场景法就是在⼀个常规的流程中，某些阶段可能会出现⼀些意想不到的情况，常规流程是基本流，从阶段中分析出来的不同情况被称之为备选流。

以商场买衣服为例：

基本流就是：逛街->到达服装店->选衣服->买衣服。但是在每一个流程中都可能出现意外，使得我们必须先将意外处理好，才能继续执行基本流，这些意外被称为备选流。

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

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

案例：

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

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

1.确定基本流

• 输入账号密码，点击注册，发送确认邮箱，确认邮箱，注册成功。

2.确定备选流

• 账号密码输入异常，网络异常，未在24H内确认邮箱。

3.编写测试用例

1. 基本流：输入正确的账号密码，点击注册，发送确认邮箱，在24H内确认邮箱，注册成功。
2. 备选流：输入错误的账号密码后重新输入正确的账号密码，点击注册，发送确认邮箱，在24H内确认邮箱，注册成功。
3. 备选流：输入错误的账号密码后重新输入正确的账号密码，点击注册网络异常，重新点击注册，发送确认邮箱，在24H内确认邮箱，注册成功。
4. .........

3.2.6 错误猜测法

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

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

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

• “武大郎”：憨厚，老实，为人坦诚，乐于助人
• “潘金莲”：美丽，“温柔”，“疼爱丈夫”，“善于交友”，“精通制衣”

2）当我们需要测试输入密码的时候，直觉告诉我们就应该测试一下输入密码时是否加密，是否具备安全性

3）当存在多个版本时，经验告诉我们每个版本都需要测试。

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

3.3 更多用例

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程序

现在我们对csdn的接口进行测试，假如测试在CSDN的输入框中搜索Linux，得到如下接口：

接口：https://so.csdn.net/so/search?spm=1000.2115.3001.4498&q=Linux&t=&u=

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

不同的请求方式：

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

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

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

不同的参数格式：

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

接口性能：

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

我们可以使用Postman工具来帮助我们进行测试

下载链接：Download Postman | Get Started for Free

下载完成后进行登陆，就会出现如下页面。

点击+号创建一个http请求页面

将地址输入进去

点击send，出现如下页面则说明成功收到了http响应。

我们可以修改http请求来进行对接口的测试，如我们将请求方法改成post。

进行send后，可以发现给我们返回了一个405页面，说明csdn对post方法进行处理过，不允许用户进行post方法。

再如q中保存的是我们要搜索的Linux，我们将他修改成windows，看能否给我返回结果。

最终给我返回了下面这个响应，这个响应和直接搜索Windos返回的响应是一样的。