您可以捐助,支持我们的公益事业。

1元 10元 50元





认证码:  验证码,看不清楚?请点击刷新验证码 必填



  求知 文章 文库 Lib 视频 iPerson 课程 认证 咨询 工具 讲座 Model Center   Code  
会员   
   
 
     
   
 订阅
  捐助
测试用例设计方法
 
 
  2491  次浏览      18
 2021-9-29
 
编辑推荐:
本文主要介绍了黑盒测试的等价类划分法、边界值分析法、决策表、因果表及其他黑盒测试方法。
本文来自于CSDN,由火龙果软件Linda编辑推荐。

一、黑盒测试

也称为功能测试或数据驱动测试。通过软件的外部表现来发现其缺陷和错误。在测试时,把被测程序视为一个不能打开的盒子,在完全不考虑程序内部逻辑结构和内部特性的情况下进行。它是在已知产品所应具有的功能前提下,通过测试来检测每个功能是否都能正常使用,测试者在程序接口进行测试,它只检查程序功能是否按照需求规格说明书的规定正常使用,程序是否能够适当地接收输入数据而产生正确的输出信息,并且保持外部信息(如数据库或文件)的完整性。

黑盒测试主要用于软件确认测试。

1.1 等价类划分法

1.1.1定义

等价类测试是把所有可能的输入数据,即程序的输入域划分成若干部分(子集),然后从每一个子集中选取少数具有代表性的数据作为测试用例。它是一种重要的,常用的黑盒测试用例设计方法,适用范围广,可以适用于单元测试、集成测试。系统测试等,且容易扩展。

1.1.2 等价类划分分类

等价类划分有两种不同的情况:有效等价类和无效等价类。在设计测试用例时,要同时考虑这两种等价类。软件不仅要能接受合理的数据,也要能经受意外的考验,这样的测试才能确保软件具有更高的可靠性。

1.1.3 等价类划分原则

如果某个输入条件规定了取值范围或值的个数。则可确定一个合理的等价类(输入值在此范围内)和两个不合理的等价类(输入值或个数小于这个范围的最小值或大于这个范围的最大值)

如果规定了输入数据的一组值,而且程序对不同输入值做不同的处理,则每个允许输入值是一个合理的等价类,此外还有一个不合理的等价类,即任何一个不允许输入的值。

如果规定了输入数据必须遵循的规则,可确定一个合理的等价类(符合规则)和若干个不合理的等价类(从各种角度违法规则)

如果输入是布尔表达式,可以分为一个有效的等价类和一个无效的等价类

如果已划分的等价类中各元素在程序中的处理方式不同,则应将此等价类进一步划分为更小的等价类

等价类划分还应特别注意默认值、空值、Null、0等的情形

1.1.4 实例

【例】电话号码测试。某城市电话号码由三部分组成,分别是

地区码——空白或4位数字

前 缀——为三位数字,但不能为“1”或“0”

后 缀——4位数字

假定被测程序能接受一切符合上述规定的电话号码,拒绝所有不符合规定的电话号码。请用等价类方法进行测试,设计测试用例

如表2-2

表2-3 电话号码测试用例

1.2 边界值分析法

1.2.1 常见边界条件

数值的边界值

计算机是基于二进制进行工作的,因此,软件的任何数值运算都有一定的范围限制。比如一个字节由8位组成,一个字节所能表达的数值范围是[0,255]。表2-4 列出了计算机中常用的数值范围

表 2-4 二进制数组的边界字符的边界值

其他边界条件

1.2.2 边界值选择遵循的原则

如果输入条件规定了值的范围,可选择正好等于边界值的数据作为合理的测试用例,同时还要选择刚好越过边界值的数据作为不合理的测试用例。如输入值的取值范围是[0,99],可取-1,0,99,100等值作为测试数据

如果输入的条件指出了输入数据的个数,则按最大个数。最小个数、比最小个数少1、比最大个数多1等情况分别设计测试用例。如,一个输入文件可包括1~255个记录。则分别设计有1个记录,255个记录,以及0个记录、266个记录的输入文件来作为测试用例

如果程序的规格说明给出的输入域或输出域是有序集合(如有序列表、顺序文件等),则应选取集合的第一个元素和最后一个元素作为测试数据。例如,输出的表最多有99行,每50行为一页,则输出0行、1行、50行、51行、99行。

如果程序中使用了一个内部数据结构,则应当选择这个内部数据结构的边界上的值作为测试数据

1.2.3 实例

【例】NextDate函数边界值测试

程序有三个变量month、day、year(month、day和year均为整数值,并且满足1<=month<=12、1<=day<=31、1900<=year<=2050),分别作为输入日期的月份、日、年份,通过程序可以输出该输入日期在日历上下一天的日期。例如,输入为2005年11月29日,则该程序的输出为2005年11月30日。请用边界值分析法设计测试用例

分析各变量的取值

边界值分析测试时,各变量分别取:略小于最小值、最小值、正常值、最大值和略最大于最大值。具体取值如下:

month:-1,1,6,12,13;

day:-1,1,15,31,32;

year:1899,1900,1975,2050,2051;

设计测试用例,见表2-6

表 2-6 NextDate函数测试用例

在NextDate函数中有两种复杂性的输入来源,一是输入域的复杂性(即输入变量之间逻辑关系的复杂性),而是确定闰年的规则。

1.3 决策表

考虑输入与输出变量取值之间的关系,比较复杂,需要更多的规则

在一些数据处理问题中,某些操作是否实施依赖于多个逻辑条件的取值,在这些逻辑条件取值的组合构成的多种情况下,分别执行不同的操作。处理这类问题的一个非常有力的分析和表达工具是判定表(决策表)。决策表能够将复杂的问题按照各种可能的情况全部列举出来,简明并避免遗漏。因此,利用决策表能够设计出完整的测试用例集合。在所有的功能测试方法中,基于决策表的测试方法是最严格的

决策表通常由四个部分组成,如表2-7

1.3.1 决策表结构

(1)条件桩(Condition Stub):列出了问题的所有条件。通常认为列出的条件的次序无关紧要

(2)动作桩(Action Stub):列出了问题规定可能采取的操作。这些操作的排列顺序没有约束

(3)条件项(Condition Entry):列出了针对它左列条件的取值。在所有可能的情况下,给出真假值。

(4)动作项(Action Entry):列出在条件项的各种取值情况下应该采取的动作

1.3.2 建立判定表可遵循的步骤

1)列出条件桩和动作桩

2)确定规则的个数,用来为规则编号。

若有n个原因,且每个原因的可取值为0或者1,那么将会有2n个规则。

3)完成所有条件项的填写。

4)完成所有的动作项的填写。(得到初始判定表)

5)合并相似规则,用以对初始判断表进行简化。

有两个或者多条规则具有相同的动作,并且条件项之间存在极为相似的关系就可以进行合并。

1.3.3 实例

问题描述: “……对于功率大于50马力的机器,并且维修记录不全或已运行10年以上的机器,应给予优先的维修处理……”

条件桩:

C1:功率大于50马力吗?

C2:维修记录不全吗?

C3:运行超过10年吗?

动作桩:

A1:进行优先处理

A2:作其他处理

生成判定表:

简化判定表:

1,2合并,5,7合并,6,8合并

1.4 因果图

等价类划分和边界值分析方法都只是孤立地考虑各个输入数据的测试功能,而没有考虑多个输入条件的各种组合和输入条件之间的相互制约关系引起的错误。因此必须考虑采用一种适合于描述对于多种条件的组合,相应产生多个动作的形式来设计测试用例,这就需要利用因果图(逻辑模型),因果图方法最终生成的就是判定表,它适合于检查程序输入条件的各种组合情况

因果图中的基本符号:通常在因果图中用Ci表示原因,用Ei表示结果,各结点表示状态,可取值“0”或“1”。“0”表示某状态不出现,“1”表示某状态出现。

1.4.1 因果图法基本步骤:

找出所有的原因,原因即输入条件或输入条件的等价类。

找出所有的结果,结果即输出条件。

明确所有输入条件之间的制约关系以及组合关系。

明确所有输出条件之间的制约关系以及组合关系。

找出什么样的输入条件组合会产生哪种输出结果

把因果图转换成判定表/决策表

为判定表/决策表中的每一列表示的情况设计测试用例

1.4.2 实例

【例】某软件规格说明书中需求描述为:第一列字符必须是A或B,第二列字符必须是一个数字,在此情况下进行文件修改,但如果第一列字符不正确,则给出信息L,如果第二列字符不是数字,则给出信息M。

根据以上说明书需求分析出原因和结果

原因:

x、第一列字符是A;

y、第一列字符是B

z、第二列字符是数字

结果:

a、修改文件(即成功)

b、给出信息L

c、给出信息M

分析:

原因:

x、y、z不能同时出现(对应表规则号1)

x和y不能同时出现(对应表规则号2)

x、z可以组合(对应表规则号3)

y、z可以组合(对应表规则号5)

x、y、z可以单独出现(对应序号4、6、7)

x、y、z可以都不出现(对应表规则号1)

结果:

ab不能组合

ac不能组合

bc不能组合

a、b、c可以单独出现

根据以上分析建立判定表

软件规格说明书判定表

注意,规则1、2列是不可能同时出现的,排除,简化后即为测试用例

1.5 其他黑盒测试方法

随机测试、 错误推测、 场景测试、 综合测试

   
2491 次浏览       18
相关文章

DevOps转型融入到企业文化
DevOps 能力模型、演进及案例剖析
基于 DevOps 理念的私有 PaaS 平台实践
微软开发团队的DevOps实践启示
相关文档

DevOps驱动应用运维变革与创新
运维管理规划
如何实现企业应用部署自动化
运维自动化实践之路
相关课程

自动化运维工具(基于DevOps)
互联网运维与DevOps
MySQL性能优化及运维培训
IT系统运维管理
最新课程计划
信息架构建模(基于UML+EA)3-21[北京]
软件架构设计师 3-21[北京]
图数据库与知识图谱 3-25[北京]
业务架构设计 4-11[北京]
SysML和EA系统设计与建模 4-22[北京]
DoDAF规范、模型与实例 5-23[北京]
 
最新文章
DevOps 道法术器,立体化实施框架
DevOps 中高效测试基础架构的最佳实践
DevOps 在公司项目中的实践落地
如何基于 Kubernetes 构建完整的 DevOps 流水线
阿里云Kubernetes实战
最新课程
DevOps体系实践、工具与平台
基于Kubernetes的DevOps实践
互联网运维与DevOps
基于Kubernetes构建企业容器云
企业级DevOps工作体系与平台
更多...   
成功案例
北京 DevOps体系实践、工具与平台
神龙汽车 DevOps体系实践、工具与平台
中国移动通信 网络规划与管理
某航空公司 IT规划与企业架构
某金融公司 IT服务管理(ITIL V3)
更多...