软件测试 (用例篇)

前言

上一篇博客讲述的是一次基本的测试过程。
在我们开始做了一段时间基础测试，熟悉了业务之后，往往会分配来写测试用例，并且在日常测试中，有时也需要补充测试用例到现有的案例库中。

在这里我们将回答以下问题

1、测试用例的基本要素
2、测试用例的设计方法
3、测试用例的有效性
4、测试用例的粒度和评价

简单来说：这篇博客就开始教大家怎么去写一个测试案例！

测试用例的基本要素

其实测试用例的基本要素就是测试用例的定义/概念：

测试用例（Test Case）是为了实施测试而向被测试的系统提供的一组集合，这组集合包含：测试环境、操作步骤、测试数据、预期结果等要素。
好的测试用例是一个不熟悉业务的人也能依据用例来很快的进行测试评价测试用例的标准：对比好坏用例的评价标准

用例表达清楚，无二义性。。
用例可操作性强。
用例的输入与输出明确。一条用例只有一个预期结果。
用例的可维护性好。
用例对需求的覆盖率高。

测试用例的设计方法

基于需求设计测试用例

我们在讲需求的时候，说过：需求是测试人员进行测试的依据。

当我们测试人员拿到需求之后，需要分析需求，验证需求的合理性与正确性。
随后，从需求中提取出测试项，再去根据测试项进行进一步的细份，提取出测试点，编写测试用例

虽然我们书写测试用例的时候是从软件功能上入手的，但是当我们进行测试的时候，最先引入眼帘的是程序界面。
因此，我们测试一般是从软件界面开始进行测试。
也就是观察界面是否符合 UI（User Interface - 用户界面）的设计稿。
这个设计稿，你可以理解为是软件的静态页面，也说是前端程序员的页面模板。
前端程序员就是按照 UI 的设计稿进行页面设计的。

软件页面测试完成之后，就是验证软件的功能。
我们可以把业务相关的功能串起来进行测试。
比如：

假设我们是阿里的员工比如:
淘宝APP的购物场景搜索商品 >> 加入购物车 >> 结算 >>付钱[大致流程]它的购物场景是由一个个功能组成的。其实这就是把业务中相关的功能串起来进行测试

紧接着，就是针对一个功能的不同输入与其相应的输出，进行测试。

比如:我们在淘宝的搜索栏中，输入一件商品的名字，页面就会输出响应的商品数据这个就是验证前端的“动态页面”的效果。

举一个例子:
QQ登录测试用例对于登录操作就属于针对同一个功能进行不同的输入，以及对应的输出(效果)

1、输入正确的用户名和密码，登录成功(输出)。

2、输入的用户名和密码，有一个，甚至两个，都是错误的情况，登录失败(输出)

3、输入的用户名和密码，有一个，甚至两个为空(没填入数据) 的情况，提示某某为空!(输出)

随后就是功能之间的交互性与异常功能的测试

功能的交互性:同一个系统中，不同角色 (功能) 之间的交互。比如:

功能角色:
        1、注册和登录[你没有注册，怎么可能登录成功? ]

        2、购物车和收藏夹[购物车满了。。多的放在收藏夹里面]

用户角色;
        网购过的朋友，都知道购买物品之后，在待收货的界面中，商品是有一个联系客服的功能此时这个功能，就相当于让买家和卖家之间进行交互。

相同的例子，还有很多! !
上面这两个只是简单的交互操作。

复杂的:买家这边一下单，卖家就会收到订单请求。卖家就根买家的订单信息进行发货，同时会给买家更新货物状态。这也是不同角色之间的交互动作。
这些功能，不管你是那个角色，都要进行测试!
尤其是和上面这种关于利益之间交互，尤为重要!需要我们仔细对待!

异常功能的测试:
就拿我们前面看到 qg登录测试用例来举例!
1、用户名和密码有一个/两个为空，有没有提示信息?
2、用户名和密码一个/两个输入错误，有没有提示信息?
这里的错误提示信息，就是异常功能[换句话来说:就是对异常情况的处理]

还有一些比较难的测试项
比如：实现功能所用到的算法，也是需要进行验证的。

关于算法的验证，你是结合代码的

而且需要开发人员辅助，告诉这个算法，它的作用与规则是什么?

然后，我们就进行针对性的，去设计一些专门和特殊的数据来测试该功能的算法

然后，就是从易用性，兼容性性能等几个方面去考虑

易用性: 软件的功能使用起来简不简单，上手度怎么样?

兼容性:软件安装在各种系统上，会不会出现“排斥”[设备的操作系统不支持运行这款软件] ?

总结

当我们进行设计测试用例的时候，我们应该从以下这几个点入手：
1、界面测试
2、验证软件的功能，把业务相关的功能串起来进行测试【每个功能都需要测试】
3、一个功能的不同输入与其相对应的不同的输出。
4、功能之间的交互性
5、异常功能的测试
6、功能所用到的算法，也需要进行验证
7、从易用性，兼容性性能等几个方面去考虑
简单来说：设计一个合格的测试用例，就是从一个软件的外在到内在的进一步分析，分析出一个个测试项。再通过这些测试项细化出一个个测试点，而测试点又可以分情况处理【即：对测试点进一步细分】。

一至六，都是针对功能性进行测试。
唯有第七条是针对非功能性测试。

有的人可能觉得有点糊，你确定是在讲 “基于需求设计测试用例”嘛？

学习测试，需要探索性思维。
你也可以理解为是一种发散思维，从不同的角度，将内容给联系起来。
你们之所以感觉有点糊，不是你们没有看懂，而是你没有捅破“那一层膜”！
膜：就是你们要主动思考两样东西的关联之处。
下面我就来给你们“开个光”！
那界面来说：
界面的功能和排版，都需要符合大众的需求。
比如：支付宝
我们在打开支付宝的时候，通常都是为了出示支付嘛，或者是收款码，进行首付款。
因此，我们希望已进入支付宝，我们就能看到这两个功能。
如果两个功能可以合并在一起，那最好。
支付宝也是这么去做的：当我们打开支付宝的时候，马上就能发现收付款的功能图案

点击它，我们首先进入是付款码，因为花钱比收钱的日子要多。
而且，工资什么的，都是直接进行银行卡转账的。
因此，默认显示付款码是很合理的！
而且，你想要收款的时候，就在付款码的下面，是有一个收款码的选项的。
以上这一些，都是根据用户的需求（习惯），衍生出来的。
而我们需要测试的地方，也就是这里。
我们点击这个收付款，首先进入的是不是付款码的界面？
这就是一个测试点啊！
为什么要测？为了符合用户的需求啊！

其它的6个点，其实你们仔细想想。
结合前面讲解的例子，就都能发现，它们都是符合用户需求（习惯）的。

实战案例 - 日历系统

上面都是一些功能性的测试，还有一些非功能性测试，这里我们这是书写一下。

易用性，兼容性，性能，安全性，可移植性，可维护性。
非功能性测试就是测试在软件本身有的功能之上做的一些限制。
比如：
QQ用户登录测试用例中的，关于登录操作的测试。
即使用户登录操作是可以进行登录的。
而非功能测试，就比如：拿性能来说

其实这句话 “非功能性测试就是测试在软件本身有的功能之上做的一些限制。”

还可以这么去理解：
这里的限制，你可以理解为是一种要求 / 指标。
这么说吧：“非功能性测试”就是为了提升用户的体验；对软件的执行没有影响。

需要注意的是：上面提到这些非功能性的测试（易用性，兼容性，性能，安全性，可移植性，可维护性），不是所有的，都要测试！

不同的应用软件对于以上非功能性的要求是不一样的！！！
比如：
1、面向客户端的软件：【画图板，office，Word，xmind】

这种软件对性能，安全性要求不高。
但是对于兼容性，可移植性，稳定性要求较高。
理由很简单，因为是面向客户端的，也就是 1v1 的服务。
面向一个客户的服务软件。
这么说吧：在你的电脑上，是访问不到我电脑的的画图板的。
不存在用户之间的交互，1 v 1 服务。
既然是 1 v 1 服务，软件只需要满足你一个人的需求即可，因此对性能的要求肯定不高。

其次，不存在客户端与服务器之间的交互，也就不存在中间人攻击的说法。
因此对于安全性的要求也不高

另外，这都是办公必备软件，因此必须在不同类型的系统上，都能安装运行。
因此对于兼容性的要求，比较高。

还有就是，我发送给你的 Word，office 之类的文件，只要对方也安装了相应的文件，也能打开使用。因此对于可移植性的要求也是比较高的。

既然这些软件都是公办必备软件，肯定是会被频繁使用的。
因此，对于软件的稳定性要求就比较高！你这软件不能用着用着就崩了，别人的数据怎么办！！！

2、面向企业内部的软件
比如：飞Q，飞书（字节跳动）。。。。这种用于企业内部员工使用的交流软件。

因为这种类型的软件，只是针对自己公司的内部人员使用。
公司可以统一电脑的操作系统，因此对于系统的兼容性要求不高
公司内部的人员，其实不是很多。
别看着几千人，其实对于计算机来说也就那样。
因此对于性能的要求也不是很高。

但是对于功能性，可靠性的要求高。
因为是公司内部人员使用，那么肯定是用来互传文件，互相沟通之类。
至少需要满足员工的一些日常操作。
因此对于功能性的要求高。

对于传文件，肯定是要求不能发生传输残缺/丢包的情况！！！
文件里都是代码，缺胳膊少腿，谁知道是哪里少了点什么？？？
因此对于可靠性的要求是比较高的！

3、大型的商用软件
比如：微信，QQ

别边看它们是免费使用的。。。
你想想会员和各种钻，还有超级版本的（更贵的）。
另外，用户基数多，说明流量多，广告商就会投资，让 QQ/微信投放他们的广告.
这是要给腾讯钱的！！！
也就是说：我们都在直接或间接的为腾讯赚钱！
奈何自己不花钱的是真的香，广告商的钱又不是我们的钱。。。

这种大型商用软件对非功能性的各个方面要求都很高。
你这么想：用户多，对软件的性能的要求就高。不然请求一多，服务器根本处理不过来。

另外，对于这种大型商用软件，尤其用户基数特别大的软件。
它不可能说，要求必须是某某系统，才能安装吧？这不是在 “作死”嘛！
摆明就是想损失用户。
因此，想这种大型商用软件对于兼容性的要求，就很高。
巴不得什么设备都能装它们的软件，这些都是钱啊！

接着，像QQ 和微信这种交流软件，对于可靠性的要求也很高。
总不能，我给 A 发消息，结果B收到了。
万一聊天内容特别劲爆，发错人就很尴尬！
另外，聊着聊着就丢包，数据无法进行传输，也是不好的。

同时对可移植性和安全性的要求，同样也很高。
可移植性体现在我们在换手机之后，进行软件搬家的时候，把软件从一个系统到另一个系统的难易程度。

对于安全性，这是最好理解。
每个人的聊天信息都属于个人隐私，没有人愿意说给一个外人看。
另外，现在的 QQ号/微信多数都是和游戏账号绑定的。
如果QQ号被盗，那么这些绑定的“财产”也就没了。

具体的设计测试用例的方法

等价类

根据输入（特殊情况下，才考虑输出），把输入划分成若干个等价类，从每一个等价类当中选择测试用例进行测试。
如果这个测试用例，测试通过了。

我们就说这个测试用例代表的等价类测试通过。

我来举个例子，帮助你们来了解等价类。
等价类，就是把同一个事物进行划分。
比如：
这里有 3只狗：哈士奇，阿拉斯加，萨摩耶，它们都是犬类动物，也就是狗吧？
此时我们就可以将它们划分到狗，这一类里面。
那么，问题就来了：狗这一类，难道只有这3种品种吗？
答案肯定不是，种类还有很多！
虽然种类繁多，但是狗的习性基本是一致的。
我们可以通过对几只共性很强的狗进行试验，而得出的结果基本上是可以代表绝大部分的犬类

这也是等价类目的：
通过将相同类型的事物，划分成一个类（等价类）。
从中提出几个典型的案例进行测试，其测试的结果就能代表这个等价类中的绝大部分情况的测试结果。
简单来说：等价类能够帮助我们解决测试用例无法进行穷举的情况

下面，我们再来举个例子，了解一下等价类的应用场景。

边界值

不知道大家还记不记得：在冒泡排序，选择排序中，有两层for循环。

里面循环变量是从0开始自增，但小于 length - 1的。

其实这里 array.length -1 ，就是边界值，为了防止数组越界，导致代码崩溃

而我们测试中的边界值，是输入和输出的边界。
我们要针对输入和输出的边界进行测试用例的设计。

tips (建议)：等价类和边界值结合在一起进行测试用例的设计。
因为等价类的测试用例中，就包含着边界值测试用例。
只不过在等价类中是分离开的，有效等价类和无效等价类。

错误猜测法

注意！不是瞎猜！！！
而是根据测试人员的经验和知识的积累，来猜测某一块功能有问题。
随后，有针对性的进行测试用例的编写。

说白了：就是程序员的经验之谈。

有的朋友可能就会有疑问：你觉得我像是有经验的佬嘛。。。
其实！我们是有经验的！！！
因为我们一直在使用各种 APP，打游戏，听音乐，看小说等等。。。。
我们具有使用经验，也就是用户体验软件的经验。
我们很容易就能 get 到用户的需求有哪些，因为我们也是用户。
也就是说：我们至少拥有用户的经验。
而我们缺少的是：站在测试的角度去看待需求的经验。

错误猜测法，有点类似于探索性测试。

针对性比较强，比较依赖测试人员个人的水平。
比如：
1、搜索查询框 - 空格
在某个软件/网页中，搜索关键字的时候，而且这个关键字，在服务器的数据库中是有对应的数据的。
只要我们在关键字的左右两侧敲一个空格（关键字：“空格 + 奥特曼 + 空格”），就搜索不到。
因为这两个空格，导致原本可以搜索到的数据，现在搜索不到了。
在Java中，String类型有一个方法 trim()，可以去除字符串前后的空格。
由这个问题引申出另外一个问题：字符串中间的空格是否要去掉？
答案：不能！
中间的空格，一般是用户刻意敲的，可能具有实际的意义。
而两侧的空格，可能是用户误敲的，没有实际的意义。

2、搜索查询出的信息：500条
每一页展示 100 条，共展示5页。
但是发现不同的页面上有相同的数据，数据ID也是一样的。
一般查询到的结果，是需要经过排序的。
排序的条件，暂且忽略。反正，就是根据某种唯一的参数进行排序。
比如：数据ID

下面我们来分析一下：

案例 - 水杯测试 - 培养的思维

这是一个在美团面试中被提到的面试题。
PS：由于题目没有给出到底是那种水杯，牵扯的范围很广。
因此，我们这个案例不是全面（覆盖性不强）。

场景设计法

很多软件不同的场景，都是基于不同事件的触发。不同事件的触发，会导致场景走向不同的时间流 / 场景。

前面讲的错误猜测法，等价类和边界值，都是针对某一个孤立的功能去进行设计。
而场景设计法就是把不同的功能点给串起来了，形成一个场景。
需要注意的是：不同的功能点有不同的输出，不同的输出就会导致不同的测试场景。
下面，我们来通过一个例子来加深对场景设计法的理解。

场景分析法，还可以认为是将一个功能集成模块给拆分成一个个单独功能模块，进行设计测试用例。

因果图法

面试会问，但是在实际工作中用的很少。
即便是在工作中用到了，你可能都没有意识到自己使用了因果图法。

因果图法，与其说是一种指导思想；
不如说是：在我们经过大量测试之后，具有了一定的测试经验，总结出来的测试方法。
和前面错误猜测法是类似的，都是经验之谈。

首先，因果图是一种逻辑图，它具有恒等，与，或，非逻辑。
用因果图来设计测试用例，就叫做因果图法。

因果图法的使用场景：

当我们有很多不同的输入的时候，不同的输入/不同的输入组合就会产生不同的输出。
这个时候我们可以用因果图法来进行测试用例的设计.
总的来说:就是因为它的输入和输出，实在是太多了!这个时候，如果不用某种方法/某种工具来进行分析的话，那我们很可能会遗漏掉一些测试用例和测试点因果图法就是起着这样的一个分析效果，其作用就是降低遗漏测试点/测试用例的概率。

下面我们再来分析因果图中所包含的那些逻辑。

下面我们来看一下：因果图法设计测试用例的步骤

1、分析出所有的输入和输出
‘2、找出输入和输出之间的组合关系
3、根据关系画出因果图
4、根据因果图画出判定表
5、根据判定表写出测试用例
‘
下面我们来通过一个例子，来加深对这五个步骤的印象

正交排列 - 了解即可

顾名思义：就是根据正交性来设计测试用例的。

它是从大量的实验（测试）数据中根据正交原则取出最优的数据的组合。
然后，根据最优数据组合实验的结果来分析整个测试的结果。

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

因素（Factor）：在一项试验(测试)中，凡欲考察的变量称为因素（变量）
水平（位级）（Level）：在试验（测试）范围内，因素被考察的值称为水平（变量的取值）

正交排列的运用场景

因果法设计用例太多怎么办？
正交法的目的是为了减少用例数目。用尽量少的用例覆盖输入的两两组合。

正交表的构成：

行数(Runs)：正交表中的行的个数，即试验的次数,用N代表。
因素数(Factors)：正交表中列的个数，用C代表。
水平数(Levels)：任何单个因素能够取得的值的最大个数。正交表中的包含的值为从0到数“水平数-1”或从1到“水平数”，用T代表。
正交表的表示形式： L=行数(水平数*因素数) L=N(TC)

正交表的两条性质：

每一列中各数字出现的次数都一样多。
任何两列中的各有序数对出现的次数都一样多。

正交法设计测试用例的步骤：

1、有哪些因素（变量）
2、每个因素有哪几个水平（变量的取值）
3、选择一个合适的正交表
4、把变量的值映射到表中
5、把每一行的各因素水平的组合作为一个测试用例
6、加上你认为可疑且没有在表中出现的用例组合

案例:

继续以注册为例（类似工具可以使用微软的PICT工具）：
1、因素：姓名、邮箱、密码、确认密码、验证码
2、水平：填写、不填写

3、表中的因素数=5；
表中至每个因素数的水平数=2
行数取最少的一个，即试验次数最少的一个
L=N(TC)=(2-1)*5+1=6(25) N=Cx(T-1)+1
L=6(25)
N试验次数
T水平数
C因素数
选择正交表，这里选择了L6_2_5。正交表不是随便选择的，而是设计好的
4、生成测试用例
思路：因素取值为填写时：正交按取值个数5-3-2-1（5已全了，3，2，1任意排列）进行排列，实验次数不够用取值为填写个数为2或3任意组合，但要满足正交的二条性质。

5、增补测试用例
姓名、邮箱、密码、确认密码、验证码都不填写

3、测试用例的有效性

1、测试用例对应的功能已删除，不可操作了。
这个测试用例没有用了，没有意义了。

微信刚出来时与QQ可互发消息，下一个版本后就不可以发消息。

2、执行一条测试用例未发现BUG，实际该处有BUG

苹果7手机微信添加了mobile单车小程序，扫码不能开锁，只能使用mobile APP开锁，测试用例未涉及到苹果7微信小程序扫码开锁
测试遗漏 / 测试用例覆盖率不高
换句话来说：就是测试用例的有效的范围没有包含到该情况。

4、执行一条测试用例发现了BUG

苹果7手机微信添加了mobile单车小程序，用例已写到了苹果7微信添加mobile小程序扫码开锁，问题被发现。
测用用例的有效性的范围包含了这个点。

5、执行一条测试用例未发现BUG，实际该处BUG已修改

苹果7手机微信添加了mobile单车小程序扫码开锁，可以正常开锁。
测用用例的有效性的范围包含了这个点，并且实际效果达到了预期的效果。

4、测试用例的粒度和评价 - 了解

测试用例的粒度

好的测试用例是一个不熟悉业务的人也能依据用例来很快的进行测试

粒度：指测试用例编写的详细程度.

测试用例可以写得很简单，也可以写得很复杂。最简单的测试用例是测试的纲要，仅仅指出要测试的内容，如探索性测试中的测试设计，仅会指出需要测试产品的哪些要素、需要达到的质量目标、需要使用的测试方法等。
而最复杂的测试用例就像飞机维修人员使用的工作指令卡一样，会指定输入的每项数据，期待的结果及检验的方法，具体到界面元素的操作步骤，指定测试的方法和工具等。

(1)测试用例写得过于复杂或详细，会带来两个问题：一个是效率问题，另一个是维护成本问题。另外，测试用例设计得过于详细，留给测试执行人员的思考空间就比较少，容易限制测试人员的思维。

(2)测试用例写得过于简单，则可能失去了测试周例的意义。过于简单的测试用例设计其实并没有进行“设计”，只是把需要测试的功能模块记录下来而已，它的作用仅仅是在测试过程中作为一个简单的测试计划，提醒测试人员测试的主要功能包括哪些而已。测试用例的设计的本质应该是在设计的过程中理解需求，检验需求，并把对软件系统的测试方法的思路记录下来，以便指导将来的测试。

大多数测试团队编写的测试用例的粒度介于两者之间。而如何把握好粒度是测试用例设计的关键，也将影响测试用例设计的效率和效果。应该根据项目的实际情况、测试资源情况来决定设计出怎样粒度的测试用例。

主要考虑可以参考如下内容：
产品的质量要求
项目对用例的要求
测试时间和资源是否充分
但是不管用例怎么简化，都不应该省略.

测试用例的评价

测试用例设计出来了，如何提高测试用例设计的质量？就像软件产品需要通过各种手段来保证质量一样，测试用例的质量保证也需要综合使用各种手段和方法。评审分为正式和非正式评审。

同行评审
用户检查
项目组评审

（1）测试用例的检查可以有多种方式但是最敏捷的应当属临时的同行评审。同行评审，尤其是临时的同行评审，应该演变成类似结对编程一样的方式。从而体现敏捷的“个体和交互比过程和工具更有价值”，要强调测试用例设计者之间的思想碰撞，通过讨论、协作来完成测试用例的设计，原因很简单，测试用例的目的是尽可能全面地覆盖需求，而测试人员总会存在某方面的思维缺陷，一个人的思维总是存在局限性。因此需要一起设计测试用例。

（2）除了同行评审，还应该尽量引入用户参与到测试用例的设计中来，让用户参与评审，从而体现敏捷的“顾客的协作比合同谈判更有价值”这一原则。这里顾客的含义比较广泛，关键在于如何定义测试，如果测试是对产品的批判，则顾客应该指最终用户或顾客代表（在内部可以是市场人员或领域专家）；如果测试是被定义为对开发提供帮助和支持，那么顾客显然就是程序员了。

(3) 由测试负责人组织协调开展会议，用例编写人对用例进行讲解，参会人员有异议的当场提出。