软件测试用例的设计方法

软件测试用例的设计方法

常见的黑盒测试用例设计方法

1. 等价类划分法

把程序的输入域划分成若干部分,然后从每个部分中选取少数代表性数据作为测试用例
每一类的代表性数据在测试中的作用等价于这一类中的其他值,如果某一类中的一个例子发现了错误,这一等价类中的其他例子也能发现同样的错误。
反之,如果某一类中的一个例子没有发现错误,则这一类中的其他例子也不会查出错误
在这里插入图片描述

确定等价类的原则:
  • 在输入条件规定了取值范围或值的个数的情况下,可以确立一个有效等价类和两个无效等价类
  • 在输入条件规定了输入值的集合或者规定了“必须如何”的条件的情况下,可以确立一个有效等价类和一个无效等价类
  • 在输入条件是一个布尔量的情况下,可确定一个有效等价类和一个无效等价类
  • 在规定了输入数据的一组值(假定n个),并且程序要对每一个输入值分别处理的情况下,可确立n个有效等价类和一个无效等价类
  • 在规定了输入数据必须遵守的规则的情况下,可确立一个有效等价类(符合规则)和若干个无效等价类(从不同角度违反规则)
  • 在确知己划分的等价类中,各元素在程序处理中的方式不同的情况下,则应再将该等价类进一步地划分为更小的等价类
2. 边界值分析法

如果输入条件规定了值的范围,则应取刚达到这个范围的边界的值,以及刚刚超越这个范围边界的值作为测试输入数据
如果输入条件规定了值的个数,则用最大个数、最小个数、比最小个数少1、比最大个数多1的数作为测试数据
分析规格说明,找出其他可能的边界条件
在这里插入图片描述

边界值的选择原则:
  • 如果输入条件规定了值的范围,则应取刚达到这个范围的边界的值,以及刚刚超越这个范围边界的值作为测试输入数据
  • 如果输入条件规定了值的个数,则用最大个数、最小个数、比最小个数少1、比最大个数多1的数作为测试数据
  • 如果程序的规格说明给出的输入域或输出域是有序集合,则应选取集合的第一个元素和最后一个元素作为测试用例
  • 如果程序中使用了一个内部数据结构,则应当选择这个内部数据结构边界上的值作为测试用例。
  • 分析规格说明,找出其他可能的边界条件
3. 因果图法

因果图法是一种适合于描述对于多种输入条件组合的测试方法
根据输入条件的组合、约束关系和输出条件的因果关系,分析输入条件的各种组合情况,从而设计测试用例的方法
适合于检查程序输入条件涉及的各种组合情况。

  • 分割功能说明书
  • 识别出“原因”和“结果”,并加以编号
  • 根据功能说明书中规定的原因和结果之间的关系画出因果图

根据功能说明在因果图中加上约束条件
其中互斥、包含、唯一、要求时对原因的约束,屏蔽是对结果的约束。他们的含义如下

  • 互斥:表示不同时为1,即a,b,c中至多只有一个1
  • 包含:表示至少有一个1,即a,b,c中不同时为0
  • 唯一:表示a,b,c中有且仅有一个1
  • 要求:表示若a=1,则b必须为1。即不可能a=1且b=0
  • 屏蔽:表示若a=1,则b必须为0
4. 判定表驱动法

判定表驱动法是分析和表达多逻辑条件下执行不同操作的情况的工具。

判定表驱动法
  • 条件桩(Condition Stub):列出了问题得所有条件。通常认为列出的条件的次序无关紧要。
  • 动作桩(Action Stub):列出了问题规定可能采取的操作。这些操作的排列顺序没有约束。
  • 条件项(Condition Entry):列出针对它左列条件的取值。在所有可能情况下的真假值。
  • 动作项(Action Entry):列出在条件项的各种取值情况下应该采取的动作
建立判定表的步骤
  • 确定规则的个数
    假如有n个条件,每个条件有两个取值(0,1),故有 2n 种规则
  • 列出所有的条件桩和动作桩
    填入条件项
    填入动作项,制定初始判定表
    简化,合并相似规则或者相同动作
适合使用判定表设计测试用例的条件:
  • 规格说明以判定表的形式给出,或很容易转换成判定表
  • 条件的排列顺序不影响执行哪些操作
  • 规则的排列顺序不影响执行哪些操作
  • 当某一规则的条件已经满足,并确定要执行的操作后,不必检验别的规则
  • 如果某一规则要执行多个操作,这些操作的执行顺序无关紧要
五. 正交实验法

正交实验法就是利用排列整齐的表 -正交表来对试验进行整体设计、综合比较、统计分析,
实现通过少数的实验次数找到较好的生产条件,以达到最好效果,
这种试验设计法是从大量的试验点中挑选适量的具有代表性的点,利用已经造好的表格—正交表来安排试验并进行数据分析的方法。

六. 场景法
设计用例的步骤
  • 根据说明,描述出程序的基本流及各项备选流
  • 根据基本流和各项备选流生成不同的场景
  • 对每一个场景生成相应的测试用例
  • 对生成的所有测试用例重新复审,去掉多余的测试用例
  • 测试用例确定后,对每一个测试用例确定测试数据值

场景法适用于解决业务流程清晰的系统或功能

七. 状态迁徙图法

来源:在遇到有事务流或由于某种条件成立导致状态改变的软件时,如何进行测试用例的设计就比较麻烦。

状态迁徙图法的目标

设计足够多的测试用例达到对系统状态的覆盖、状态-条件组合的覆盖以及状态迁移路径的覆盖

状态图法步骤
  • 列出所有可能的输入事件,以ip N的方式命名(N为1,2,3,4……)
  • 把软件的打开的初始状态,定义为“空闲”状态
  • 在“空闲”状态上加所有可能的输入(只加一次!)
  • 为上一步产生的所有新状态,分别加所有可能的输入(只加一次!)
  • 循环执行上一步
    直到再没有任何新状态产生,列出所有的状态,生成状态表
  • 组合任意可能的状态组合,写出相应的测试用例
八. 测试大纲法

测试大纲法
一种着眼于需求的方法
为列出各种测试条件,将需求转换为大纲的形式

九. 其他测试用例设计方法
探索性测试法
  • 基于测试人员经验与直觉的测试方法
  • 是对测试用例设计的有效补充
  • 探索性测试也必须生成测试用例
猴子测试(随意性测试)

一种没有书面测试用例、记录期望结果、检查列表、脚本或指令的测试

缺点:
测试往往不太真实
不能达到一定的覆盖率
许多测试都是冗余的
需要使用同样的随机数才能重建测试

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

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

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

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值