收藏本站 收藏本站
积木网首页 - 软件测试 - 常用手册 - 站长工具 - 技术社区
软件测试 > 用例设计 > 正文

首页 | 领域细分: 游戏测试 安全测试 手机测试 Web测试 | 技术研究: 单元测试 入门教程 用例设计 性能测试 功能测试 | 测试职场: 面试精选 职场发展 面试试题

测试管理: 配置及流程 - 需求管理 - 质量验收 - 缺陷管理 - 其它管理相关 | 开发语言: PHP技巧 - PHP基础 - PHP实例 - PHP错误代码

测试工具: LoadRunner JiRa QuickTestPro RoBot WinRunner TestDirector 其它测试工具 | 数据库: Mysql数据库 Oracle数据库 CSS/DIV基础 HTML基础

常用测试用例设计方法之间的微妙联系

来源:互联网 日期:2014-01-28 16:30

  最近半个月利用工作之余一直学习常用的测试用例设计方法:等价划分法,边界值法,域分析法,输出域分析法,场景法,正交试验法,组合分析法,分类树法,因果图法,判定表法,状态迁移法,错误推测法等,学的有点杂,感觉也有点乱,最近几天一直在思考这些常用设计方法之间到底存在着何种关系,又有什么不同。

  总体给我的感觉就是测试用例的设计思路是:先从穷举法开始,如果测试特性输入不是太多,我们可以用穷举法把每一种可能的情况都测试一遍,以达到100%的覆盖率,但是我们知道,在测试行业,达到100%的测试覆盖率几乎是不可能的。一是现实中测试特性的输入一般都是很多,用穷举法测试代价太大,执行起来也不现实;二是即使是很少的测试特性输入,但是要把现实中的各种情况都测试一遍,执行起来也比较困难。这个时候,就出现了各种测试用例设计方法,利用这些方法对大量的测试用例进行裁剪,达到我们可以接受的范围,当然这是以牺牲测试充分性为代价的,我们要做的就是用尽可能少的测试用例来达到最大的测试充分性。这里要注意尽可能少的测试用例不是指越少越好,有时候我们为了提高测试覆盖率,就不得不增加测试用例数;这里指将测试用例裁剪到我们现实中可以执行完成的范围,达到这个范围后,再考虑测试覆盖率的问题,在测试用例数和测试覆盖率之间寻求一种平衡。

  先来看等价划分法,它是对系统的输入域进行等价划分为若干部分,然后从这若干部分中选择少数测试输入数据代表该部分执行测试,以减少大量的测试用例。使用此方法我们有4个有用的分解数据的启发式关注点:数值的范围,变量的相似度,唯一数值和特定数值。但是用这种方法设计的测试用例不充分,因为它没有考虑输入域划分时的边界情况,这时就可以用边界分析法对其进行补充,以提高测试覆盖率。为达到上面同样的效果,有人将等价划分法和边界值分析法结合起来便形成了现在的域分析法,域分析法通过引入上点,离点和内点的概念可以用更少的测试用例达到与等价类和边界值分析法相同的测试效果。为了提高测试的充分性,可以在测试过程中引入输出域分析法对测试用例进行必要的补充。

  这里简要说一下域分析法与输出域分析法的关系,域分析法是针对输入域进行的,输出域分析法是通过输出反推输入,以达到对测试特性输入域的测试进行补充,提高测试覆盖率。

  上面的设计方法主要是针对单个因子输入的情况,但是现实中我们经常遇到需要覆盖多个变化参数因子的场景测试,更多的是要求对各组合的测试。组合分析和正交试验法就是对多输入因子的设计方法,组合分析原理是每个参数的每个值只需要和其他参数至少配对一次就行了,侧重在随机组合,即把每个因子的状态列出来,用PICT工具完成随机组合,把这些组合转化为测试用例;而正交试验法更多是对任意多个因素取值组合实施“等概率”覆盖,以便我们得到的实验样本均匀的分布在样本空间,即把每个因子的状态罗列出来,对其进行加权,为减小测试用例,删减权值较小的,再对照正交表,把各因子的状态填到正交表中,即可得到各测试用例。有时候,分类树方法也可以用在多因子输入设计测试用例中,先对各因子对象进行分析,然后分析每个因子的输入空间,对其输入空间进行分类,画出分类树,组合测试用例,这个过程中掺杂着对单个因子输入情况的测试用例设计方法:等价类,边界值以及域分析法。对于多个变化参数因子的场景测试也可以用分类树法,先识别出测试对象并分析输入空间,再对测试对象的输入空间进行分类,最后画出分类树组合测试用例。分类树法更加直观,再辅以分类树工具CTE,设计测试用例更加方便实用。

  以上不管是对单个因子输入还是多因子输入情况的测试用例分析方法,更多的关注的是对输入域的分析。这些分析方法不需要深入了解测试对象的执行流程及各输入因子以及输入输出之间的联系,但这会给后期执行测试用例带来一些麻烦,当执行测试用例过程中,如果发现了bug,不好定位问题,各测试因子之间的联系不直观,不知道哪个环节出现了问题。这时可以用一些侧重于图形化或者流程的测试用例设计方法,如流程分析法,因果图法,判定表,状态转换法等。

  对于系统测试,感觉流程分析法与状态转化法,除了在画流程图和状态转换图中遵循的规则不同外,差别不大。可能流程分析法,更多关注流的流向,状态转换法注重测试对象的各个状态和转换条件,有时候感觉状态转换法要考虑的测试对象更多,这两种方法都要求对测试对象的执行流程很熟悉。各个因子之间的关系也很直观明了,有助于对后期执行测试用例发现BUG后,定位bug。

  因果图法一般是和判定表结合使用的,因果图法的结果就是产生判定表。对于多输入因子的测试对象,先标识输入和输出(包括各种情况)----》画出因果图----》将因果图转换为判定表---》简化判定表-----》生成测试用例。这个过程中也可以单独使用判定表,根据条件桩和动作桩写出各种条件项和动作项,这个过程跟穷举法类似,然后通过把无效的测试用例去除,并把相似的列进行合并,减少测试用例。单独使用判定表过程简单,但是对各输入因子之间,输入输出之间的约束关系不够直观明确;使用因果图法+判定表的结合方法,过程有点繁琐,但是输入输出,以及输入和输出之间的因果关系,输入和输入之间的约束关系比较明确。这个要根据个人喜好,选择其设计方法。

  最后介绍下场景法和错误推测法,这两种方法可以对采用上面方法设计的测试用例进行补充,以达到充分测试。软件是用事件触发达到控制流程的,事件触发时的情景形成场景,而同一事件不同的触发顺序和处理结果形成事件流,这个事件流就是场景法。有些人认为场景法可以作为独立的测试用例设计方法,我不赞同这种看法,场景法要求测试人员充分发挥对用户实际业务场景的想象,但是人毕竟不是机器,再缜密的想象也很难设计出覆盖性较强的测试用例,可以把它作为其他他测试用例设计方法的补充,利用测试人员的实际业务场景的想象思维,对测试用例的遗漏点进行必要的补充。错误推测法,是一种基于测试人员经验和直觉来推测软件中可能存在的各种错误,从而有针对性的设计测试用例的方法。利用错误推测checklist,对测试用例进行补充。

  通过上面分析知道,当穷举法设计的测试用例在现实中不可能执行时,我们就应该采用其他设计方法在尽量不影响测试覆盖率的情况下对测试用例进行裁剪。各种方法有各种方法的特点,使用时考虑的角度,考虑的点不同,总的来讲就是在设计测试用例中,不断的优化设计流程,用最少的测试用例达到最大的测试覆盖率。上面只是对常用测试用例简单做了总结,要深入了解还得在实际项目测试中不断去摸索,思考,总结。

本周排行

别人正在浏览

强悍的草根IT技术社区,这里应该有您想要的!
Copyright © 2010 Gimoo.Net. All Rights Rreserved  京ICP备05050695号