首页 > 编程知识 正文

如何设计测试用例(软件单元测试用例)

时间:2023-05-03 07:04:00 阅读:66304 作者:1100

首先,让我们考虑一个问题。 在单元测试中,哪个环节更重要?

要回答这个问题,首先需要知道单元测试有哪些部分。 读到这里后,请暂停一分钟,回想一下平时的单元测试实践(请最小化浏览器)。

单体测试可分为什么阶段,你有自己的认识吗?

我自己的理解是,怎么分都行。 编辑根据自己的经验,将其分为以下几个环节。

分析业务

用例的设计

实现用例

重建

持续整合

接下来,暂停一分钟,想想这五个环节中哪个更重要(请最小化浏览器)。

一分钟的思考结果,我相信你有自己的认识。

针对这个问题,小编似乎不能确定哪个环节更重要,需要各个环节的良好配合才能发挥各个环节的最大作用。

这篇文章的内容是这五个环节中的设计用例环节。

练习

请针对以下业务设计用例。 (假设有返回true或false的方法,请接受字符串并根据定义的规则进行检查。 )

暂停三分钟,想想尽可能多的用例。 (请最小化浏览器。

如果你以前没有任何测试经验,用例中可能包含这样的内容:

等价分类

对于这个问题我们可以把输入的情况分类如下。

这样分类的话,可以看出每个范畴区间的输入都具有相同的意义,这就是等价类分类。

等价类划分可以分析业务边界,明确哪些用例实际有效,避免不必要的无效用例。

等价类的划分可以分为有效等价类和无效等价类

有效等价类是对程序规格说明来说合理且有意义的输入数据构成的集合。

无效等价类:无效等价类是指程序规格说明不合理或无意义的输入数据组成的集合。

在本练习中,“6-18个字符、数字或字符”属于有效等价类,其他两个区间属于无效等价类。

在划分等价类时,这两个等价类都是必不可少的。

边界值分析法

设计用例时,边界值必须特别敏感,因为边界值通常会导致更多错误。 边界值分析法是指测试输入或输出的边界值。 通常,边界值分析法是对等价类划分法的补充。

在本练习中,边界值至少包括以下情况:

在业务描述中抓住关键点有助于确定业务边界值。 例如,如果业务包含以下说明,则通常需要注意边界值:

最大XX (最小/大、最快/慢、最高/底……) ) ) )。

超重

在里面

相邻的

.

识别边界值时,越界的用例设计非常必要,这是对程序健壮性的验证。

短了就短/长了就长

第1至1/最后加1

更少/更多

正好超过/正好在里面

经过等价类划分和边界值分析,设计了几种用例,但尚未考虑业务中的“数字、字母或符号”。 由于无法推测用户的输入状况,所以有可能存在多个组合,如果随便考虑,很容易忽略该组合。 接下来使用的判定表的分析是为了解决这样的问题。

判定表

在本练习中,您只能将输入的字符分为字母、数字、英语字符、非英语字符和图标。 需要考虑这些情况的组合。 如果没有判定表的话,我会头痛。

判定表的定义:判定表是分析和表现在多逻辑条件下进行不同操作的情况的工具。

在此,以判定表一部分的截图为例;

通过判定表,可以清楚罗列各种情况,降低遗漏的可能性。

分类可能非常多,判定表可能会变得庞大。 不需要把细节作为一个项目,可以把一个维度、一个类别作为一个分类。 进而减少测试用例维护的麻烦。

结果

经过上述几种方法的透析,可以得到以下用例表。

此表包含此业务的大多数用例(本来就没有完美的用例工具包)。

上面介绍的三种方法不一定要按照前面介绍的顺序使用。 在设计用例时,我们认为有这些方法,如果可以用这些方法进行分析,就可以涵盖大部分情况。

理想是美丽的,现实往往是苦涩的。 重新分析具体业务,用上述方法分析,可能找不到合适的等价类划分方法,边界识别也很模糊,可能被我们忽略。

仔细分析上述三种方法,就会发现其中包含了变量识别这一重要步骤。

变量识别

变量识别是指识别业务中可变的关键点,通过不断改变这些关键点来构建用例。

吓得发抖

业务说明:如何对当前系统用户仅在首次调用时执行委托。

对于该说明,

咱们再暂停三分钟,请思考其中的变量,以及其可变化的情况(请最小化浏览器)。

三分钟过后,你是不是识别到了其中的变量呢?

小编识别到了这么些变量;

当前系统用户:如果不是当前系统用户会怎样?

第一次调用:如果不是第一次调用会怎样?

委托:这个委托是有返回值呢,还是没返回值?如果委托中抛出了异常会怎样?

你是不是比小编识别到更多变量呢?做个练习,请针对下面的业务描述识别变量,并设计用例。

“ 执行所有事件,在执行过程不抛出异常,在全部运行之后如果有异常则抛出所有异常”

错误推测

除了上面介绍的方法,还有一种基于经验的用例设计方法:错误推测。

所谓错误推测,基于经验和直觉推测程序中所有可能存在的各种错误, 从而有针对性的设计测试用例的方法。

错误猜测大多基于经验,需要从边界值分析等其他技术获得帮助。这种技术猜测特定软件类型可能发生的错误类型,并且设计测试用例查出这些错误。

对有经验的工程师来说,错误猜测有时是唯一最有效发现Bug的测试设计方法。

但是经验是需要积累的,是需要时间的,对于一个新人来讲,快速获得经验是提升的法宝,对于老人来讲,把经验传递给新人,帮助新人快速成长,应该是义不容辞的责任。

所以,老人把经验都记录下来对自己和新人都会非常受益。

总结

在这边文章中,我们介绍了如下设计用例的方法:

等价类划分

边界值识别

判定表分析

变量识别

错误推测

每种方法都不复杂,也都能帮我们解决问题,如果能够在每次设计用例的时候想到这些方法,基本用例设计就比较全了。

上文内容不用于商业目的,如涉及知识产权问题,请权利人联系博为峰小编(021-64471599-8017),我们将立即处理。

版权声明:该文观点仅代表作者本人。处理文章:请发送邮件至 三1五14八八95#扣扣.com 举报,一经查实,本站将立刻删除。