测试用例是怎么写的？

2023-04-03 18:22 作者:黑马测试 0人读过 | 我要投稿

PS：本文转载自黑马测试知乎高赞文章

链接：https://www.zhihu.com/question/272193009/answer/2962583197

测试用例对于测试人员而言，虽说是最最基础的技能，但却非常重要。测试用例是支撑我们在测试道路上进一步学习其他测试技能的基本功。

那测试用例如何撰写，完整来说应该包含两部分内容：

内容1：测试用例撰写（按照八大要素）；
内容2：测试用例（测试点）分析（尽量让测试用例更全面，少遗漏测试场景）。

如果不懂如何进行“测试用例撰写”，建议同学们看下这篇文章，绝壁是“手把手”教大家撰写测试用例（围绕测试用例八大要素展开），请狠狠点击下方文章：

《感觉测试用例好难写怎么办?9 赞同 · 5 评论回答》

https://www.zhihu.com/question/393584042/answer/2957750770

所以本篇文章讲跳过测试用例撰写，重点目标是阐述 ”如何进行测试用例分析“。

为了让各位同学对本文章全局了解，先将文章行文结构介绍如下：

1、拿到软件后，该如何分析测试用例；
2、抖音案例_如何通过业务场景分析测试用例；
3、抖音案例_单功能模块如何深入分析测试用例；
4、总结+测试用例系列学习资源分享

好，开始。

一、拿到软件后，该如何分析测试用例？

直接说出答案，那就是应该从"全局->局部" 去分析测试用例。

拿到一个软件，就如同走到一个迷宫的入口。为走出迷宫，完成迷宫游戏，如果我们不对迷宫的整体先做分析，而直接进入到迷宫局部去深入了解的话，那就很难找到一条最优的游戏路径。所以玩迷宫游戏，需要从全局到局部。

对应到一个项目中，比如下图的TP商城（web商城本质上也是一款软件），密码麻麻很多菜单，很多功能项，该如何下手测试才能保证软件质量？那就和上面的迷宫一样，先要从全局去对软件进行全面理解，然后再深入局部。也就是需要从全局到局部。

对于软件而言，全局指的是业务流程，局部指的是功能模块。

业务流程，代表用户使用你软件的最高商业价值（下方还会详细介绍）

如何了解软件全局（业务流程）呢，我们这个时候需要借助一个重要的核心的参考文档，那就是产品经理撰写的《产品需求文档》（product requirement document，简称PRD）。

PRD文档的作用是：

1）对软件需求进行规划、定义、描述和展示的工具
2) 是设计/研发/测试过程中的指导纲领

软件测试人员在设计测试用例前，可重点查看RPD文档第5部分，以了解产品全局。

二、如何通过业务场景分析测试用例

上节说道，测试用例分析，要有“从全局到局部”的思路。

那怎么从全局出发呢，还得从“业务场景”说起。

1、什么是业务场景

业务场景，代表用户使用你软件的最高商业价值

不好理解的话，我们举例来说明。

以淘宝商城为例，它的商业价值实现，就是吸引用户在淘宝购买商品。为实现这个目标，淘宝需要提供下列一系列的功能。

而上述截图中展现的一系列功能，就是淘宝店业务场景。

所以业务场景我们还可以这么理解：

1）业务场景，代表用户使用你软件的最高商业价值。
2）业务场景，是多个功能的组合。
总结业务场景，是用户为实现某个软件的最高商业价值，而产生的一序列活动。

所以我们拿到软件产品，首先要分析业务场景，要测试业务场景，要优先确保用户使用软件的全局功能都能走通，达成软件目标。所以业务场景测试是全面测试的基础。

那应该如何通过业务场景撰写测试用例呢？有下面两种方法：流程图法和泳道图法。

下面就讲。

2、业务场景撰写测试用例_流程图法

先介绍此方法的操作4步骤，如下所示：

1、根据产品需求文档拿到（或自绘）流程图
2、流程图路径分析
3、撰写测试场景-测试点
4、测试用例设计

步骤讲完，我们再跑个案例，以大家都熟悉的抖音项目发布视频为例，来给大家举例。

业务场景: 用户使用抖音发布视频

1）根据产品需求文档拿到（或自绘）抖音项目发布视频

PRD文档，对于该业务场景的文字描述如下：

①入口：首页点击+号进入视频拍摄
②视频类型：日常视频仅一天可见/作品视频永久可见

将PRD文档流程图截图如下

2）流程图路径分析

①从开始到结束为一条路径，
②技巧分享：路径数=判定接点数（菱形）+1

所以，抖音项目发布视频总路径数=判定数+1=4

3）撰写4个路径的“测试场景-测试点”

① 场景一：未登录发布视频
② 场景二：发日常视频
③ 场景三：发草稿视频
④ 场景四：发布作品视频

4）测试用例设计

如何撰写测试用例，可以直接查看文章（围绕测试用例八大要素展开），点击下方文章：

《感觉测试用例好难写怎么办?9 赞同 · 5 评论回答》

https://www.zhihu.com/question/393584042/answer/2957750770

在此不再赘述，直接放上测试用例表格：

3、业务场景撰写测试用例_泳道图法

上方的“用户通过抖音发布视频”案例，业务场景中，角色只是一个人，所以用流程图就可以。

但当业务场景中涉及多个角色，流程图就表达不了，就需要泳道图。

但泳道图测试路径的分析方法与流程图是相同的，也是下面的4步骤：

1) 根据产品需求文档拿到（或自绘）流程图
2) 流程图路径分析
3) 撰写测试场景-测试点
4) 测试用例设计

接下来我们也来跑个案例，举例抖音商城的退款。

业务场景: 用户使用抖音商城退款

1) 根据产品需求文档拿到（或自绘）流程图

PRD文档，对于该业务场景的文字描述如下：

①普通用户发起退款申请

②商家进行审核，审核通过进行退款，审核不通过拒绝退款，退款成功用户账户收到退款项，售后

详情显示已退款

③商家拒绝退款后，用户确认售后结果，退款流程结束，售后详情显示已结束。

④商家拒绝退款后，用户可以向平台申诉，平台审核后可根据实际情况决定退全款/部分退款/拒绝退款，平台结果为终审结果。

将PRD文档流程图截图如下：

2）流程图路径分析

①从开始到结束为一条路径，
②技巧分享：路径数=判定接点数（菱形）+1

所以，抖音商城退款业务总路径数=判定数+1=5

3）撰写“抖音商城退款业务”，5个路径的“测试场景-测试点”

① 场景一：商家审核不通过
② 场景二：商家审核通过
③ 场景三：平台审核不通过
④ 场景四：平台审核全额退款
⑤ 场景五：平台审核部分退款

4）“抖音商城退款业务”测试用例设计

如何撰写测试用例，可以直接查看文章：

《感觉测试用例好难写怎么办?9 赞同 · 5 评论回答》

https://www.zhihu.com/question/393584042/answer/2957750770

在此不再赘述，直接放上测试用例表格：

总结：要从全局到局部的思路去设计测试用例。全局，就是从业务场景去表达的。从流程图（泳道图）去分析，最后转化成测试用例，执行测试。

整体的主营业务介绍完了，那具体的功能模块该如何设计测试用例呢？下面就讲。

三、单功能模块该如何深入分析测试用例

针对局部功能展开详细测试，一般也叫模块测试。

模块功能测试也是有测试思路的，共分为三步，先来介绍下：

1. 根据产品需求文档（又名PRD文档）拿到模块介绍
① 功能说明
② 页面原型
③ 需求描述

2.根据PRD文档梳理功能需求
需求梳理设计思路：
① 业务规则：该规则对用户价值最大，优先级最高
② 元素规则：考虑元素长度/类型/操作
③ 页面布局默认值：元素排版+默认值显示
④ 数据逻辑：数据来源、数据处理和输出（此点需要数据库知识，先跳过）

3.编写测试点
测试点的设计思路
① 业务规则：正向（符合需求）+ 反向（不符合需求）
② 元素规则：正向 + 反向
③ 页面布局默认值

4.完善测试点
① 一条用例尽可能多覆盖正向测试点
② 每个反向测试点使用一条用例覆盖

5. 测试点转化为测试用例

以上思路，不理解没有关系，我们走个案例，同学们就会有感知了。

我们以业务场景中的第一个模块，登录模块来举行说明。

第一步：根据产品需求文档（又名PRD文档）拿到“抖音登录模块”介绍

① 功能说明 ② 页面原型 ③ 需求描述

1）功能说明

用户登录方式：手机号和验证码/手机号和密码/第三方登录

2）页面原型

3）需求描述

第二步：根据PRD文档梳理功能需求（使用xmind梳理）

① 业务规则：该规则对用户价值最大，优先级最高
② 元素规则：考虑元素长度/类型/操作
③ 页面布局默认值：元素排版+默认值显示

1）梳理业务规则：该规则对用户价值最大，优先级最高

业务规则：手机号未注册时，自动注册并登录

2) 元素规则：考虑元素长度/类型/操作

元素规则，是找产品中所有元素，梳理这些元素的长度、类型、时间、操作方面需求

根据PRD文档中的页面原型和需求描述，梳理如下：

3）页面布局默认值：元素排版+默认值显示

第三步：编写测试点

① 业务规则：正向（符合需求）+ 反向（不符合需求）
② 元素规则：正向 + 反向
③ 页面布局默认值

1）业务规则编写测试点（正反向）

2) 元素规则：正向 + 反向

协议选择单选按钮和登录按钮操作，写不出正向反向，可以不写

3）页面布局默认值

因为“页面布局默认值”，没有正向反向，所以不需要写。跳过。

第四步：完善测试点

① 一条用例尽可能多覆盖正向测试点
② 每个反向测试点各自使用一条用例覆盖

1）一条用例尽可能多覆盖正向测试点

一条用例尽可能多覆盖正向测试点，意思就是将梳理的所有正向测试点，写入到一条用例中，测试能否跑成功

case01: 手机号已注册，登录成功

2 ) 每个反向测试点各自使用一条用例覆盖

case02: 手机号未注册，自动注册并登录
case03: 手机号非11位
case04: 手机号非数字
case05: 验证码非4位
case06: 验证码非数字
case07: 验证码有效期大于3分钟
case08: 验证“获取验证码按钮超过60s后是否恢复可点击状态”

3 ) 补充“操作按钮”+“页面布局默认值”

case09: 验证“协议单选按钮点击切换选中状态”
case10: 验证“手机号/验证码/协议单选按钮，缺少任意一个，置灰不可点击”
case11: 验证页面布局默认值

注意：以上测试点我们会发现一个问题，那就是测试点撰写的不够严谨，比如，手机号非11位，那是指手机号非11位，都要测试吗？那就麻烦了，因为这样看，测试数据就“无法穷举”。这时就需要使用等价类划分法来晚上测试点。

4）用“等价类划分法”，来完善测试点

等价类划分法：将测试数据按照某种共同特征划分为“若干子集”，这些子集就叫“等价类”。
应用场景：测试数据无法穷举

完善测试点，需要借助“等价类表”，如下图所示：

ps：上表字段中的“有效等价类”，指的是满足需求的数据集合。“无效等价类”，指的是“不满足需求的数据集合”

等价列表的使用方法共计3步骤：

step1. 从需求中找出输入条件。”
step2. 为输入条件划分等价类（等价类表），案例中，
step3. 设计测试用例

结合登录案例中的元素规则，我们就能得到下面这张填写完成的表格：

所以，上方简陋的测试点优化后如下：

case01: 手机号已注册，登录成功
case02: 手机号未注册，自动注册并登录
case03: 手机号非11位
case03-1: 手机号大于11位
case03-2: 手机号小于11位
case03-3: 手机号为空
case03-4: 11位数字非手机号
case04: 手机号非数字
case05: 验证码非4位
case05-1: 验证码大于4位数字
case05-2: 验证码小于4位数字
case05-3: 验证码为空
case05-4: 错误的4位验证码
case06: 验证码非数字
case07: 验证码有效期大于3分钟
case08: 验证“获取验证码按钮超过60s后是否恢复可点击状态”
case09: 验证“协议单选按钮点击切换选中状态”
case10: 验证“手机号/验证码/协议单选按钮，缺少任意一个，置灰不可点击”
case11: 验证页面布局默认值

PS:相信有些同学看到这里后，还会有疑问，那就是等价类表中的填写的测试数据。举例“大于11位数字”，表中为什么14位，而不是15位，13位，或是12位....?

这就涉及到另一个问题：等价类如何取值更有代表性？

那就要再引入一个知识点：边界值法。

5）用“边界值法”，让等价类取值更具代表性

边界值法：选测试数据的时候，有区间的时候，选择临界点两侧的数据。
使用方法：选取正好等于、刚好大于、刚好小于边界的值，作为测试数据。
原因：边界上的值更容易出错。

所以图表中的数据，根据边界值的思想，我们来优化下取值，如下截图所示：

测试点更细致了，取值也更有代表性了，那测试点还有别的问题吗？

有。

举例case10: 验证“手机号/验证码/协议单选按钮，缺少任意一个条件，置灰不可点击” ，这里只考虑缺失一个条件就置灰。

那是不是也要考虑同时缺失2个条件，同时缺失3个条件的测试点呢？所以现在的测试点还只是关注了单个输入条件的测试点，并未考虑多个输入条件之间的组合关系。

解决办法：需要引入“判定表分析法”。

6）用“判定表分析法”，进一步优化测试点

判定表：以表格形式表示“多条件组合”下，得到的不同结果的分析工具。

绘制判定表主要经过下面3个步骤：

1）列出动作
2）填写条件项，对条件进行组合
3）根据条件项的组合确定动作
有n个条件，每个条件项有2种取值，最大条件项组合为：2的n次方
4）简化合并相似规则

让我们来结合登录案例来操作下。

①动作项有两个：登录按钮可点击，登录按钮置灰
②条件项共有3个：手机号为空，验证码为空，协议单选按钮为空。
③确定的最大条件项组合为：2的3次方=8，表格要预留8列

得到表格如下：

④简化合并相似规则

当动作输出完全相同的两列或多列，若动作输出无关条件，则可合并，如下图所示：

则上方的判定表可以优化如下，从8个测试点降低为5个测试点：

则最终的测试点编写如下：

case01: 手机号已注册，登录成功
case02: 手机号未注册，自动注册并登录
case03: 手机号非11位
case03-1: 手机号大于11位
case03-2: 手机号小于11位
case03-3: 手机号为空
case03-4: 11位数字非手机号
case04: 手机号非数字
case05: 验证码非4位
case05-1: 验证码大于4位数字
case05-2: 验证码小于4位数字
case05-3: 验证码为空
case05-4: 错误的4位验证码
case06: 验证码非数字
case07: 验证码有效期大于3分钟
case08: 验证“获取验证码按钮超过60s后是否恢复可点击状态”
case09: 验证“协议单选按钮点击切换选中状态”
case10: 验证“手机号/验证码/协议单选按钮，缺少任意一个，置灰不可点击”
case10-1: 验证“手机号为空+验证码为空，登录按钮置灰不可点击”
case10-2: 验证“手机号为空+验证码不为空，登录按钮置灰不可点击”
case10-3: 验证“手机号不为空+验证码为空，登录按钮置灰不可点击”
case10-4: 验证“手机号不为空+验证码不为空+协议选择按钮为空，登录按钮置灰不可点击”
case10-5: 验证“手机号不为空+验证码不为空+协议选择按钮不为空，登录按钮可点击” case11: 验证页面布局默认值