测试用例与常用测试用例设计方法

个人站点地址: https://www.devtester.cn/

1. 测试用例

测试用例(Test Case)是指对一项特定的软件产品进行测试任务的描述,体现测试方案、方法、技术和策略。其内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等,最终形成文档。简单地认为,测试用例是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果,用于核实是否满足某个特定软件需求(百科)
测试用例通常包含用例标题,前置条件,测试步骤,测试数据,预期结果和实际结果以及测试人员信息与被测对象信息等
用例标题
根据内部组织定义的用以区分测试模块或类别的编号, 如T-登录-001,通过用例标题可以快速明确测试模块或功能
前置条件
测试步骤之前所需要执行的步骤,比如需要先重置设置,或者如回复评论需要先登录,那么前置条件可以写用户已登录
测试步骤与测试数据
测试执行的步骤,通常结合测试数据一起
期望结果
由需求文档或测试需求文档提取的结果,换而言之,是我们想要的符合需求文档的结果
实际结果
实际结果即根据测试步骤与测试数据,程序实际输出(展现)的结果,其通常由通过或失败组成,也会有记录具体数据行为,尤其在实际结果与期望结果不一致时,需要列明实际结果,进行分析,尽可能协助定位原因,并提交至缺陷管理工具
测试人员信息
通常包括测试执行人的信息与执行时间
被测对象信息
包括版本或版本日期,平台,所属模块等
用例版本记录
部分用例如果有变更记录,需要写明变更人,变更时间与变更原因

测试用例分类

简单划分可以分为功能性测试用例与非功能性测试用例。

功能性测试用例是基本的测试用例,保证用例能够覆盖功能所需;非功能用例,在功能测试用例上拓展,考虑安全性,性能,兼容性等需求的用例

好的测试用例需要具备的特征

  1. 整体完备:是有效测试用例组成的集合,能够完全覆盖测试需求
  2. 准确划分等价类:每个等价类都能保证只要其中一个输入测试通过,其他输入也一定通过
  3. 等价类集合完备:保证所有可能的边界值与边界条件都已经正确识别。

2. 常用测试用例设计方法

常用测试用例设计方法有很多,诸如等价类划分法、边界值分析法、错误推测法、测试大纲法、因果图法、判定表法、正交实验表方法、功能图法、场景设计法等等。但从实际工作中,使用频率最高的仍属等价类划分法、边界值分析法与错误推测法。在涉及业务流程时,会使用到场景设计法,对业务流程的各种场景进行划分与测试。在熟悉新产品、新系统时,则会使用测试大纲法,快速熟悉系统各个模块与数据流向。
下面着重介绍等价类划分法与边界值分析法:

等价类划分法

由于测试用例的不可穷尽性,我们需要从大量的测试数据中来选取最具代表性的数据来进行测试,将这些代表性的数据分类后,从每一个类别中选出的任一数据,对于揭露程序错误都具有同等效果。等价类分为有效等价类与无效等价类。

有效等价类

有效等价类是由需求说明书定义,有意义且合理的输入数据的集合,用以检验程序实现是否符合需求定义。在实际测试中,所有的有效等价类一定是明确定义的!

无效等价类

当需求说明书已定义无意义、不合理的输入数据时,则无效等价类是包括这些数据以及需求说明书为声明在有效等价类的数据的集合,换言之,合法输入以外的数据都将归属于无效等价类的某一类别

案例

假设一个年龄输入框,只能输入0到150的正整数,且系统会根据输入的年龄判定未成年人(小于18岁)与成年人(大于等于18岁),那么:
有效等价类

  • 0~17的任意整数
  • 18~150的任意整数

无效等价类

  • 小于0的数
  • 大于150的整数
  • 0~150的任意浮点数
  • 其他任意非数字字符

边界值分析法

边界值分析法是等价类划分法的补充,因为在实际测试中,我们会发现很多程序错误都发生在边界之上,比如上面的案例,说好输入0~150,可是0和150怎么也输不进去,18岁又被判成了未成年人,若是在用例执行时,恰好又没有选则0,150和18,那我们的程序可就带着隐患上线了。

边界值,见名知意,是处在边界上的值。在提取边界值时,我们往往会询问的一个点便是“这是开区间还是闭区间?”、“包括边上的两个值能取到吗?”等等。同时,我们不仅对于输入范围有边界提取,对于输入长度也同样需要关注边界,更进一步,对于表格、Buffer大小、索引等同样需要关注边界。比如在一个二维表上便曾发现一个问题,将鼠标聚焦在最后一行最后一列时,再点击“下一个”时,焦点并没有保持在原为或者跳到第一行第一列,而是程序直接崩溃了。

回归案例,我们能够提取的边界值应该包括:-1,0,1,17,18,19,149,150,151

错误推断法

错误推断法往往依靠测试工程师对系统的理解、个人经验以及直觉,其理念与探索测试不谋而合,并且能够在测试过程中有高效产出,但缺点是难以系统化,或者在编写用例时,逻辑组织会相比于其他用例更为抽象,甚至于难以形容。

但我们确实需要对其足够关注,形成文字记录,这不仅对自身,对测试团队而言都是一笔宝贵的财富。

综述

测试用例基于由需求提取的测试需求说明书,所以在设计用例前首先需要保证正确提取测试需求,并且深入理解需求的目的。在设计与编写用例时综合运用等价类划分法,边界值分析法与错误推断法,使我们的用例完备性更高,同时去除不必要的冗余部分。

  • 0
    点赞
  • 2
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值