一、测试用例的基本要素

二、设计测试用例的万能公式 (在没有需求文档的情况下）

1、水杯的测试用例

2、一个网站的登录测试用例

三、基于需求进行测试用例的设计

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

1、等价类

2、边界问题

3、判定表（因果图，使用场景较少）

4、场景设计法（不常见）

5、正交法（用的比较少）

🍑正交表的概念和特性

🍑根据正交表设计测试用例

6、错误猜测法

五、面试题

一、测试用例的基本要素

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

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

测试用例的给我们带来的好处

测试执行者的依据
使得工作可重复，自动化测试的基础
评估需求覆盖率
用例的复用
积累测试的方法思路以供后续借鉴

测试用例的设计是费时费力的工作，往往设计测试用例所花费的时间比执行所花费的时间还多

测试用例的设计解决如下问题：

不知道是否较全面的测试了所有功能
测试的覆盖率无法衡量
对新版本的重复测试很难实施
存在大量冗余测试影响测试效率

二、设计测试用例的万能公式 (在没有需求文档的情况下）

功能测试：产品是否实现了预期的功能

性能测试：功能测试没有问题，不代表性能好（网站速度、流畅的）

界面测试：布局、每个元素的大小、颜色、材质

兼容性测试：软件的不同版本、打开网站所用的不同浏览器
不同的系统版本、数据兼容性（不同版本数据是否展示正确且相同）

易用性测试：产品是否容易上手、提升文字（登陆时）、打开软件的操作步骤提示

安全测试：产品网站系统，用户信息，页面数据展示的是是否恰当和合适
（用户的隐式数据）
登录时候是否加密
接口返回值—SQL注入
越权问题（垂直越权和水平越权）：权限、管理员、普通用户

不同的角色对应不同的功能

1、水杯的测试用例

2、一个网站的登录测试用例

三、基于需求进行测试用例的设计

1、功能需求测试分析

2、非功能需求测试分析

详见测试 - 用例篇 - 细节狂魔_Dark And Grey的博客-CSDN博客_测试用例实战

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

实际上，在企业中我们往往都是根据需求文档来编写测试用例的，下面我们就来看看设计测试用例的具体方法。

基于需求进行测试用例的设计

1、等价类

无效等价类
有效等价类

例子

登录密码要求6<=密码长度<=18

有效等价类——测试密码长度为10

无效等价类——测试密码长度为4、20

2、边界问题

边界值——》有效边界+无效边界

还是上面的例子，测试密码长度为6、18位数的（有效边界）

无效边界为5、19长度的密码

边界是最容易出现问题的（我们程序一个不小心，就会出现边界问题)

这个时候，如果我们不测试边界的话，就会出现问题。

3、判定表（因果图，使用场景较少）

使用场景比较少

使用场景：输入条件的组合对应不同的结果

判定表设计测试用例的步骤

确认输入条件和输出条件
找到输入条件的输出条件的关系
画判定表
根据判断表编写测试用例

🌰例子

当订单使用了红包或优惠金额大于300元，则该订单是优惠订单，否则不是。

1、确认输入条件和输出条件

输入条件：使用红包、优惠金额大于300元、订单已提交

输出条件：优惠订单、非优惠订单

2、找到输入条件和输出条件的关系

输入条件之间的组合与输出条件的关系

所有的可能的组合情况

空——》非优惠订单

使用红包（没提交）——》非优惠订单

优惠金额大于300（没提交）——》非优惠订单

订单提交——》非优惠订单

使用红包+订单提交——》优惠订单

优惠大于300+订单提交——》优惠订单

使用红包+优惠大于300（没提交）——》非优惠订单

使用红包+优惠大于300+订单提交——》优惠订单

3、画判定表

4、根据判定表编写测试用例

1、无红包，优惠金额小于等于300元，订单未提交，该订单为非优惠订单

2、有红包，优惠金额小于等于300元，订单未提交，该订单为非优惠订单

3、无红包，优惠金额大于300元，订单未提交，该订单为非优惠订单

4、无红包，优惠金额小于等于300元，订单提交，该订单为非优惠订单

5、有红包，优惠金额小于等于300元，订单提交，该订单为优惠订单

6、无红包，优惠金额大于300元，订单提交，该订单为优惠订单

7、有红包，优惠金额大于300元，订单未提交，该订单为非优惠订单

8、有红包，优惠金额大于300元，订单提交，该订单为优惠订单

网上大部分书籍和资料把这种方法叫做因果图，其实上面所说的判定表和所谓的因果图是很相似的，只不过因果图多了一步叫做 ”画因果图“ （非常难，且没有一个明确的且具体的画法）

4、场景设计法（不常见）

思路引导的作用——》告诉我们不能完全参照需求文档上写的基本流程，要尽可能多的设计可能存在的意想不到的流程

比如我们去ATM取款机过程

基本事件流（主流程）

插卡——》输入密码——》选择取款功能——》输入金额——》取钞票——》退卡

备选事件流（其他流程）

卡插不进去（插卡过程中）

密码输入错误（输入密码过程中）

选择了其他功能（选择功能过程中）

输入金额的限制（输入金额过程中）

钱出不来、钱出来了没人取（取钞票过程中）

卡退不出来、卡出来了没人取（退卡过程中）

编写测试用例

基本事件流的用例

插卡——》输入密码——》选择取款功能——》输入金额——》取钞票——》退卡

备选事件流的用例

插卡——》卡插不进去——》。。。。——》退卡
插卡——》输入密码——》密码输入错误——》。。。——》退卡
插卡——》输入密码——》选择了其他功能——》。。。。——》退卡
插卡——》输入密码——》选择取款功能——》输入金额——》输入金额的限制——》。。。——》退卡
。。。。。

5、正交法（用的比较少）

正交实验法指从打大量的实验中中挑选出适量的、有代表性的点，依据”正交表“从而合理的设计出测试用例。

回顾一下我们上面讲的判断表里：3个输入条件、2个输出条件，给出来8个测试用例( $2^{3}$ )

🍑正交表的概念和特性

那么所谓的正交表是什么呢？

下面就一个正交表的例子。

该正交表可表示为 $L_{9}3^{4}$ ，它表示需作9次实验，最多可观察4个因素，每个因素均为3水平

实验次数好理解，但因素和水平又是什么东东？

🌰举个例子

正交表的特性

🍑根据正交表设计测试用例

整体步骤如下

1、找出因素数和水平数

2、生成正交表（用到了allpairs)

3、根据正交表来编写测试用例

4、补充可能存在遗漏但是非常重要的测试用例

比如我们要针对一个网站的用户注册页面来设计一个测试用例

1、找出其中的因素和水平

因素：用户名、邮箱、密码、确认密码

水平：填写、不填写

2、生成正交表（用到了allpairs)

🔔注意：

我们打开这个0115jg.txt文件

最终我们要用到的就是这一部分

通过上图我们可以看到，allpairs正交表和我们实际的正交表有出入，但仍然不影响我们用allpairs生成正交表。

3、根据正交表生成测试用例

全部填写

填写用户名，不填写邮箱、密码、确认密码

填写邮箱、确认密码，不填写用户名、密码

填写密码，不填写用户名、邮箱、确认密码

填写用户名、邮箱，不填写密码确认密码

填写确认密码，不填写用户名、邮箱、密码

4、补充可能存在遗漏但是非常重要的测试用例

加一个全都不填写

6、错误猜测法

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

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

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

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

针对性比较强，比较依赖测试人员个人的水平。

🌰比如：
1、搜索查询框 - 空格
在某个软件/网页中，搜索关键字的时候，而且这个关键字，在服务器的数据库中是有对应的数据的。
只要我们在关键字的左右两侧敲一个空格（关键字：“空格 + 奥特曼 + 空格”），就搜索不到。
因为这两个空格，导致原本可以搜索到的数据，现在搜索不到了。
在Java中，String类型有一个方法 trim()，可以去除字符串前后的空格。
由这个问题引申出另外一个问题：字符串中间的空格是否要去掉？

答案：不能！
中间的空格，一般是用户刻意敲的，可能具有实际的意义。
而两侧的空格，可能是用户误敲的，没有实际的意义。