编写测试用例

在学习本课程之前,一定要先联系老师,安装好 课程示例里面 的被测系统

然后点击这里下载该系统的需求文档

概述

点击这里,边看视频讲解,边学习以下内容

分派给测试人员的任务中,最重要之一 的就是 编写测试用例

采用什么方法才能写出比较完善的测试用例呢?

要做好两类事情

  • 不断地 搜集需求,整理需求

  • 采用一定的方法,根据整理的需求编写测试用例。

搜集、整理需求

过程描述

点击这里,边看视频讲解,边学习以下内容

在编写测试用例前,最重要的前提是什么?

就是要尽可能的 搜集 完整系统的 需求、设计

但是注意:即使开发人员给的需求、设计文档看起来已经比较全面,规范了,测试人员仍然要自己 整理、分类、组合 需求。

因为 实践证明,开发人员 不可能 给出 详细到、格式规范到 可以直接对应 产生测试用例 的 需求、设计文档。

里面肯定 有遗漏、或者细节不清楚 的地方,甚至会有 矛盾、错误

所以我们在 需求整理 过程中:

  • 寻找是否有遗漏的 需求点(测试点)

    有不少隐含 需求点(测试点) ,是需求文档中没有提到的,需要你自己找出来

    或者 有的功能点 文档 只是一带而过,细节没有描述清楚,必须要搞清楚

  • 发现需求设计 有 矛盾错误的地方,及时和 产品组、开发人员 沟通

  • 不断的将需求进行 合理的 分类、组合, 记录在你自己的测试需求文档中

    需求文档中,功能的分类组织的形式,并不一定是最好的,甚至可能是不正确的,测试人员需要根据自己的经验重新组织

    而且,我们需要把前面发现 开发人员给的需求设计文档中 的 遗漏、细节不清楚的地方 在自己的 测试需求文档中记录下来。


知道了这些要点后,具体怎么操作呢?

  • 反复看需求文档几遍,先搞懂文章中的各个功能点的含义

  • 创建自己的 测试需求文档,重新整理、分类记录功能点

    整理记录过程中,详细的品读需求,思考,有意识的 关注上面说到的注意点

  • 上面的过程 从 需求阶段 到 测试阶段不断迭代

    因为产品的整个开发过程中,决定 会 不断的改变,前面的需求设计文档里面的内容未必是有效的。

    所以要根据 搜集到的 改变的信息,不断的重复上面的过程。

    实际上,测试需求文档 和 测试用例 是 直到测试过程中,都应该不断更新的。

最终的 测试需求文档,就是做为 测试用例 的输入材料。

操作示例

具体操作示例,点击这里,观看 视频讲解

编写测试用例

需求整理好以后,采用什么方法才能写出比较完善的测试用例呢?

网上流传的编写测试用例方法有很多,我们总结最重要的就是

  • 根据测试需求建立用例分类

  • 边界值法

  • 错误猜测法

  • 因素/场景组合法

建立用例分类

点击这里,边看视频讲解,边学习以下内容

很好理解,就是根据前面 整理的测试需求 对应写出测试功能点分类

参见视频讲解。

边界值

点击这里,边看视频讲解,边学习以下内容

边界值往往是系统处理最容易出问题的地方。

边界值法 就是 对测试输入的边界内、边界上、边界外 的三种取值 都做覆盖的测试。

比如用户注册功能,要求用户名的长度为6-20个字符, 那么就应该对 用户名字符串长度为 0,3,5,6,7,15,19,20,21,1000 等这些取值都进行覆盖,比较稳妥。

需求设计文档,往往对边界情况没有明确写出来,需要测试人员 和 开发 人工沟通确定后,写出测试需求。

错误猜测

点击这里,边看视频讲解,边学习以下内容

其实上面讲的边界值法,就是典型的错误猜测。

还有其他的错误猜测

比如:

测试管理员登录功能, 那么系统中是否 有老师、学生 账号,对管理员登录是否有影响呢?

再比如,在 老师 登录界面,却输入 学生 账号、密码,系统是否能正确提示呢?

不好说,所以这些也可以在写测试用例时,作为考虑因素。可以标记为测试优先级 较低。


有些场景的错误猜测类型的测试用例,是通用的,可以作为经验 记录下来。

比如,用户注册功能,测试 用户名中是否包含中文、标点符号等。

再比如,用户登录功能,测试 用户不从登录界面登录,直接访问登录成功后的页面。


错误猜测,虽说 是凭 经验 和 直觉,实际上 和 你对系统实现内部机制 了解程度 紧密相关的。

你越了解系统的实现细节和原理,越了解相关基础知识,错误猜测的 直觉 越准确,写的测试用例越有针对性。

比如这个功能说明

创建题目时,可以为题目添加解题视频,解题视频格式只支持 mp4 格式的视频。

一般测试人员可以想到,编写测试用例涵盖上传 mp4格式的视频 和 其他格式的视频。

但是如果你了解多媒体的知识,就会知道 mp4 只是一个多媒体容器格式(container)。里面的视频 还有多种压缩格式,比如 MPEG-H Part 2 (H.265/HEVC), MPEG-4 Part 10 (H.264/AVC) 和 MPEG-4 Part 2。

那么这些格式的视频是不是也应该都测试一下呢,测试用例优先级有多高呢?

如果 你了解 产品 的实现原理, 就可以做出准确的判断

如果你没有这方面的基础知识,是无论如何想不到这样的 测试用例的,并且不能做出比较准确的判断的。

所以前面课程,我们说,测试人员也要尽可能的了解 系统的内部实现,并且学习相关基础知识。

因素/场景组合

边观看下面两个视频,边学习本节内容

因素组合法-1

因素组合法-2

因素/场景组合法,类似网上流传的 判定表 方法。

测试用例 本质上 就是 描述:

某种场景条件 下,对系统的进行怎样的操作(输入),系统应该有什么的反映(输出)。

所谓 某种场景 ,就是系统处于什么样 的 环境 ,包括 外部环境内部数据环境

  • 外部环境

    比如:硬件(CPU/内存/硬盘/网卡 等)配置、网络带宽配置、温度、操作系统、数据库、缓存软件系统 等

    外部环境通常是对 性能测试 影响比较大。

  • 内部数据环境

    指 软件系统的内部数据设置。

    比如: 数据库关键记录 数量的设置 对 性能测试 影响 至关重要。

    而对 功能测试 来说,一个功能,其相关业务数据状态,对行为的影响是 决定性的。

    比如:

    要测试 老师创建作业任务 要下发给学生 这个功能 ,那么 老师所在班级的有没有学生 这个数据状态 就是 影响 行为的 重要场景/因素。

    再比如:

    要测试 老师 编辑、删除作业的功能, 那么 该作业是否已经发布给学生就是 影响 行为的 重要场景/因素。


所以 测试用例的完善性,很大情况下,取决于你能找到多少 产品在使用过程中的 ,导致系统行为的 场景 或者 因素

因素组合法,就是 尽可能多的找到 这些 因素,记录下来,在写测试用例的时候 进行 组合

其实上面说的错误猜测法,有人认为 就是属于 因素组合法 的一部分, 因为错误猜测就是 找到影响系统行为的因素。

具体的操作示例,请看视频中的讲解演示。


上一页