测试 - 用例篇

复习

因为这篇博客是关于如何写测试用例,尽可能多的涵盖测试用例,所以我们要去回想一下之前讲过的什么是测试用例

测试用例实际上就是像被测系统发起的一组集合,这组集合包括测试环境,测试步骤,测试数据,预期结果

2，为什么软件测试人员要写测试用例?(1）测试用例是测试执行的依据
(2）测试用例可以复用，在进行回归测试的时候不用重新编写(3）测试用例可以衡量需求的覆盖率
(4)后人可以借鉴
(5)手工测试用例是自动化测试的依据

用例篇

主要问题就是两个
测试用例的基本要素
测试用例的设计方法
3、测试用例的有效性
4、测试用例的粒度和评价

测试用例的基本要素

测试用例（Test Case）是为了实施测试而向被测试的系统提供的一组集合，这组集合包含：测试环境、操作步骤、测试数据、预期结果等要素。
好的测试用例是一个不熟悉业务的人也能依据用例来很快的进行测试评价测试用例的标准：对比好坏用例的评价标准
用例表达清楚，无二义性。。
用例可操作性强。
用例的输入与输出明确。一条用例只有一个预期结果。
用例的可维护性好。
用例对需求的覆盖率高。

测试用例的设计方法

基于需求设计的测试用例

我们在讲需求的时候，说过：需求是测试人员进行测试的依据。；
当我们测试人员拿到需求之后，需要分析需求，验证需求的合理性与正确性。
随后，从需求中提取出测试项，再去根据测试项进行进一步的细份，提取出测试点，编写测试用例。
虽然我们书写测试用例的时候是从软件功能上入手的，但是当我们进行测试的时候，最先引入眼帘的是 程序界面。
因此，我们测试一般是从软件界面开始进行测试。
也就是观察界面是否符合 UI（User Interface - 用户界面）的设计稿。
这个设计稿，你可以理解为是软件的静态页面，也说是前端程序员的 页面模板。
前端程序员就是按照 UI 的 设计稿 进行 页面设计的。
 
软件页面测试完成之后，就是验证软件的功能。
我们可以把业务相关的功能串起来进行测试。

接下来就是针对一个功能的不同输入,对应着不同的输出

功能之间的交互性

异常信息的处理

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

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

总结:

基于需求设计的测试用例

像从易用性\兼容性能的方面去考虑 都是针对非功能行测试
练习:

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

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

但是针对不同类型的软件,要求的非功能性也是不一样的. 比如
1、面向客户端的软件：【画图板，office，Word，xmind】
这种软件对 性能，安全性要求不高。
但是对于 兼容性，可移植性，稳定性要求较高。
理由很简单，因为是面向客户端的，也就是 1v1 的服务。
面向一个客户的服务软件。
这么说吧：在你的电脑上，是访问不到我电脑的的画图板的。
不存在用户之间的交互，1 v 1 服务。
既然是 1 v 1 服务，软件只需要满足你一个人的需求即可，因此对性能的要求肯定不高。
 
其次，不存在客户端与服务器之间的交互，也就不存在中间人攻击的说法。
因此对于 安全性 的要求也不高
 
另外，这都是办公必备软件，因此必须在不同类型的系统上，都能安装运行。
因此对于 兼容性 的要求，比较高。
 
还有就是，我发送给你的 Word，office 之类的文件，只要对方也安装了相应的文件，也能打开使用。因此对于可移植性的要求也是比较高的。
 
既然这些软件都是公办必备软件，肯定是会被频繁使用的。
因此，对于软件的 稳定性 要求就比较高！你这软件不能用着用着就崩了

2、面向企业内部的软件
比如：飞Q，飞书（字节跳动）。。。。这种用于企业内部员工使用的交流软件。
因为这种类型的软件，只是针对自己公司的内部人员使用。
公司可以统一电脑的操作系统，因此对于 系统的兼容性要求不高
公司内部的人员，其实不是很多。
别看着几千人，其实对于计算机来说也就那样。
因此对于 性能的要求 也不是很高。
 
但是对于功能性，可靠性的要求高。
因为是公司内部人员使用，那么肯定是用来 互传文件，互相沟通之类。
至少需要满足 员工 的一些日常操作。
因此对于功能性的要求高。
 
对于传文件，肯定是要求不能发生 传输残缺/丢包 的情况！！！
文件里都是代码，缺胳膊少腿，谁知道是哪里少了点什么？？？
因此对于 可靠性的要求 是比较高的！

3、大型的商用软件
比如：微信，QQ
别边看它们是免费使用的。。。
你想想会员和各种钻，还有超级版本的（更贵的）。你敢说你没往里面砸一分钱？
另外，用户基数多，说明流量多，广告商就会投资，让 QQ/微信 投放 他们的广告.
这是要给腾讯钱的！！！
也就是说：我们都在直接或间接的 为腾讯赚钱！
奈何自己不花钱的是真的香，广告商的钱又不是我们的钱。。。
 
这种大型商用软件对 非功能性 的 各个方面要求都很高。
你这么想：用户多，对软件的性能的要求就高。不然请求一多，服务器根本处理不过来。
 
另外，对于这种大型商用软件，尤其用户基数特别大的软件。
它不可能说，要求必须是某某系统，才能安装吧？这不是在 “作死”嘛！
摆明就是想损失用户。
因此，想这种大型商用软件 对于 兼容性的要求，就很高。
巴不得什么设备都能装它们的软件，这些都是钱啊！
啊。不。这些都是衣食父母啊！！
 
接着，像QQ 和 微信 这种交流软件，对于 可靠性的要求也很高。
总不能，我给 A 发消息，结果B收到了。
万一聊天内容特别劲爆，发错人就很尴尬！
另外，聊着聊着就丢包，数据无法进行传输，也是不好的。
 
同时对 可移植性 和 安全性 的要求，同样也很高。
可移植性 体现在 我们在换手机之后，进行软件搬家的时候，把软件从一个系统到另一个系统的难易程度。
 
对于安全性，这是最好理解。
每个人的聊天信息都属于个人隐私，没有人愿意说给一个外人看。
另外，现在的 QQ号/微信 多数都是和游戏账号绑定的。
如果QQ号被盗，那么这些绑定的“财产”也就没了。

等价类

根据输入（特殊情况下才考虑输出)，把输入划分成若干个等价类)从每一个等价类当中选择测试用例进行测试，如果这个测试用例测试通过，我们就说这《测试用例代表的等价类测试通过。
等价类帮助我们解决测试用例无法穷举的情况。

边界值

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

错误猜测法

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

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

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

针对性比较强，比较依赖测试人员个人的水平。
比如：
1、搜索查询框 - 空格
在某个 软件/网页 中，搜索关键字的时候，而且这个关键字，在服务器的数据库中是有对应的数据的。
只要我们在关键字的左右两侧敲一个空格（关键字 ：“空格 + 奥特曼 + 空格”），就搜索不到。
因为这两个空格，导致原本可以搜索到的数据，现在搜索不到了。
在Java中，String类型有一个方法 trim()，可以去除 字符串 前后的 空格。
由这个问题引申出另外一个问题：字符串中间的空格是否要去掉？
答案：不能！
中间的空格，一般是用户刻意敲的，可能具有实际的意义。
而两侧的空格，可能是用户误敲的，没有实际的意义。
 
2、搜索查询出的信息：500条
每一页展示 100 条，共展示5页。
但是发现不同的页面上有相同的数据，数据ID也是一样的。
一般查询到的结果，是需要经过排序的。
排序的条件，暂且忽略。反正，就是根据某种唯一的参数进行排序。
比如：数据ID
 
下面我们来分析一下：

美团面试题:水杯测试用例

![

场景法

很多软件不同的场景，是基于不同的事件的触发，不同事件的触发，导致场景走向不同的事件流。
不同的功能点串起来形成一个场景。不同的功能点又有不同的输出，不同的输出导致不同的测试场景。

ATM取款情景:
插卡 —> 输入密码 —> 输入取款数 —> 取款 —> 退卡

1. 插卡

插错卡 (公交卡,会员卡等等)
卡插反
卡损坏
停电吞卡
卡号冻结,账号锁死
网络不好,无法识别卡号

2）输入密码

输入正确的密码
输入错误的密码（密码格式不正确)不输入密码，直接点击确认
密码输入错误超过三次，账户锁定
密码第一次输入错误，第二次或第三次输入正确密码
输入框是否支持删除输入操作
测试密码是否加密
是否支持不同字符的输入

3)输入取款钱数

输入小于卡余额的钱数
输入等于卡余额的钱数
输入大于卡余额的钱数
输入非整百的数
不输入直接按取钱按钮（取钱按钮置灰)
多久不操作超时

4)取款

输入小于等于银行卡余额的钱数时，取款成功
输入大于银行卡余额的钱数，取款失败，并提示“余额不足”
超过每日取款余额的上线
超过每日取款次数的上线

5)退卡

取钱后正常退卡
操作超时,吞卡

6)ATM机

ATM机正常
ATM一切正常
ATM余额不足
ATM断网，断电，硬件故障软件系统崩溃
发生异常情况ATM机是否支持事务回滚

因果图法