软件测试:用例篇

本文详细介绍了软件测试中的测试用例设计,包括基本要素、设计方法如基于需求、等价类、边界值、因果图、正交排列、场景设计和错误猜测法,以及测试用例的有效性、粒度和评价标准。强调了测试用例在测试执行、自动化测试、需求覆盖率和复用中的作用,同时指出其耗时和覆盖率难以衡量的缺点。
摘要由CSDN通过智能技术生成

软件测试:用例篇

本节主要内容
- 测试用例的基本要素
- 测试用例的设计方法
- 测试用例的有效性
- 测试用例的粒度和评价

测试用例的基本要素

测试用例(Test Case)是为了实施测试而向被测试的系统提供的一组集合,这组集合包括:测试环境、操作步骤、测试数据、预期结果等要素。

评价测试用例好坏的标准:
- 用例表达性清楚,无二义性。
- 用例可操作性强
- 用例的输入与输出明确。一条用例只有一个预期结果。
- 用例的可维护性好。可维护性好包含两个方面:用例的可读性好、用例易修改。
- 用例对需求的覆盖率高。需求的覆盖率=用例的条数/功能点的个数。
- 暴露程序Bug的能力强。

测试用例的优点
- 测试执行者的依据
- 自动化测试的基础
- 评估需求覆盖率
- 用例的复用
- 基类测试的方法思路以供后续借鉴

测试用例的缺点
- 费时费力,往往在设计测试用例时花费的时间比执行是花费的时间还多。
- 测试的覆盖率无法衡量,不知道是否较全面的测试了所有功能。
- 对新版本的重复测试很难实施,存在大量冗余测试影响测试效率。

测试用例具体的设计方法

设计方法有5种:基于需求的设计、等价类、边界值、因果图、正交排列、场景设计法、错误猜测法。

基于需求的设计

RBT是基于需求的测试方法,会使测试更加有效,因为它使测试专注于质量问题产生的根源,即需求。

基于需求的测试是一种最根本的软件测试,主要关注以下两个问题:
1. 验证需求是否正确、完整、无二义性,并且逻辑一致。
2. 要从“黑盒”的角度,设计出充分并且必要的测试集,以保证设计和代码都能完全符合需求。

案例:

等价类

依据需求将输入划分为若干个等价类,从等价类中选出一个测试用例,如果这个测试用例通过,则认为所代表的等价类测试通过,这样就可以用较少的测试用例达到尽量多的功能覆盖,解决了不能穷举测试的问题。

  • 有效等价类:对于程序的规格说明来说是合理的、有意义的输入数据构成的集合,利用有效等价类验证程序是否实现了规格说明中所规定的功能和性能。
  • 无效等价类:根据需求说明书,不满足需求的集合。

    案例:
    超市买水果
    有效等价类:苹果、桃子、香蕉…
    无效等价类:牛奶、青菜…

边界值

边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法。通常边界值分析法是作为对等价类划分法的补充,这种情况下,其测试用例来自等价类的边界。

案例一:
1.[1,50]:0,1,50,51
2.(1,50):1,2,49,50
3.(1,50]:1,2,50,514.[1,50):0,1,49,50

在实际的测试设计中,会将等价类和边界值结合起来使用。

案例二:
以注册邮箱的软件需求为例子
用户名要求长度为6-15位
边界值上点为:5,6,15,16 全了吗?
答案是:NO&#
  • 2
    点赞
  • 18
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值