51Testing软件测试论坛

标题: 因果图在测试中的实用价值有多大?(10-12-6)(获奖名单已公布) [打印本页]

作者: 默默巫    时间: 2010-12-6 13:15
标题: 因果图在测试中的实用价值有多大?(10-12-6)(获奖名单已公布)
因果图在测试中的实用价值有多大?
在系统测试的用例设计方法中,许多书籍和文章都提到了因果图的方法,但总是拿几个案例在反复的引用(自动售
货机、字母判断、象棋...),很少见到在具体应用软件中的案例。
因果图的方法在具体软件中的实用价值有多大,其适用范围及能否用更简单的方法替代,最好有实例说明。

如果你也有问题想提出来和大家一起讨论,请点击此处>>
说不定下期讨论的问题就是由你提出的哦,请快快参与吧!



本次奖项空缺
作者: zj4064    时间: 2010-12-6 13:37
我们公司的测试,估计没人用因果图
作者: TIB    时间: 2010-12-6 16:43
因果图有助于分析业务规则,理清因果关系,画因果图不是最终目的,通过画因果图帮助我们分析,最终导出决策表,从决策表得到测试用例
作者: wy71884688    时间: 2010-12-6 17:20
因果图是为了辅助分析业务关系,虑清关系,减少路径复杂度。它能让我们在利用判定表时去除无限用例。
作者: goal1860    时间: 2010-12-6 18:23
实际业务场景的因果图会变得非常庞大,不方便分析,而且可以用其他方法替代。所以有书上将因果图称作“鸡肋”也是可以理解的。
作者: XZTest    时间: 2010-12-6 18:57
谁能提供一些在测试过程中使用的案例
对于业务分析,活动图和状态图是很通用的,那么因果图的优势在哪里?
作者: nelsonhan    时间: 2010-12-7 10:08
我在测试案例和测试需求编写时基本不用,真的是很鸡肋。
老实说,测试工作一向是很紧张的,经常是被开发进度压的测试只有一点时间,如果还要花费大量时间在因果图上,那测试工作基本就开展不下去了。
作者: davy_chen    时间: 2010-12-7 11:13
要搞清楚因果图究竟有多少实用价值,就要明白因果图的作用和副作用是什么。
因果图能够保证组合逻辑的完整覆盖,因此能够对于质量有很大的保证,但是其副作用就是最终生成用例数量庞大。
所以在当下追求投入产出比而忽略软件质量的年代,就很少被人所使用了。但是如果真的不计投入的保证质量,那么因果图就一定会是首选方法之一。
作者: davy_chen    时间: 2010-12-7 11:16
另外案例就那么几个是因为很多人并不清楚它的真正特性,只要知道了其特点,创造更多的事例只是是否愿意的事情了。
作者: 布布    时间: 2010-12-8 10:59
话说 我只有在面试的时候 画过因果图
工作的过程中 还真没画过
是挺鸡肋的
作者: mvvztt    时间: 2010-12-8 13:05
学过,但从来没用过,主要还是业务分析
作者: gongtao_87    时间: 2010-12-8 14:56
路过,学习。
作者: fanjianmin    时间: 2010-12-8 16:52
因果图个人理解就是能快速,清晰的理解业务,对整体流程的认识有一个感观上的认识,有助力于测试用例的点的提炼
作者: fanjianmin    时间: 2010-12-8 16:54
有谁实际用过,给大家说一下,共同提高吗,呵呆
作者: lilycheng1986    时间: 2010-12-9 15:39
我们连边界值都很少用到,更何况因果图呢。
有时候用一下边界值或等价类划分吧,组长还要跟我说,你不要这么纠结……
作者: zllphoenix    时间: 2010-12-10 14:55
因果图还是很有用的,关键是看怎么用,当来了一个新项目进行测试而又没有头绪的时候,用它来理理思路还是很不错的,因果图更适合于分析,而不是最后的设计
作者: fsyj000    时间: 2010-12-10 16:12
其实书中强调了另一个方面的问题,你的测试项目->业务的复杂性,决定你是否使用因果图。如本人在测试ERP项目,如仓库管理这块,会涉及到仓库、库区、储位之间逻辑关系,一个厂区有多个仓库,一个仓库对应多个库区,一个库区有多个储位,材料的入库、发放,需要根据厂区、事业部、公司、车间来判断,并且不同事业部之间会存在材料的调拨,供应商送给仓库的材料有几千种,几百种大类,需要设计算法控制,分别入到对应储位上以及入库、移库等过程。使用因果图,理清之间的逻辑关系,设计比较可行的测试用例,可以尝试多种情况的可能性,另外就是时间上花得很久,所以也比较赞同上述网友的说法,我本人观点,跟业务流程有关。
作者: XZTest    时间: 2010-12-11 17:49
业务流程的分析UML的方法已经很通用了,如状态图、活动图,时序图等等,而用因果图来分析业务的话,如果业务复杂,那么因果图的线条数量会很多,甚至出现大量交叉,看起来非常不直接,如果不是用来得出用例,仅仅分析业务的话,正确性不容易保证,而且拿来评审的话,开发和用户更不容易看不懂了。谁那里有以前的案例能拿来分享讨论么?
作者: 大雁南飞    时间: 2010-12-12 22:40
刚好前几天为了给组里的同事讲解一下因果图法,自己做了一个简单的判定表例子,感觉比默默巫提到的几个例子(自动售货机、字母判断、象棋...)更容易理解一点,给大家分享一下[attach]67084[/attach]
作者: XZTest    时间: 2010-12-13 14:38
回复 19# 大雁南飞

    首先感觉原因的划分上存在冗余,“部门非末级”和“部门为末级”可以合并为一个原因,“人员为空”和“人员不为空”也可以合并为一个原因,在画因果图的时候直接用“非”的关系就可以了(减少了约束关系);
    另外,在程序处理的时候,考虑效率原因,为空的判断一般在其他判断上层,因此第一和第二个测试用例其实走的是相同的路径,第三和第五条用例也同样
    因此,如果从流程图的角度去分析这个需求感觉比因果图更加方便和直观
作者: zllphoenix    时间: 2010-12-13 21:16
回复  大雁南飞

    首先感觉原因的划分上存在冗余,“部门非末级”和“部门为末级”可以合并为一个原因 ...
XZTest 发表于 2010-12-13 14:38


正解,这个问题用因果图总感觉反而麻烦了
作者: 大雁南飞    时间: 2010-12-13 22:12
回复 20# XZTest

感谢ZTtest的建议,可我试了半天也没按你说的做出来,能给个具体原因和约束关系吗?我重新修改一下
作者: XZTest    时间: 2010-12-14 11:54
这个需求感觉用流程分析比较好,画了一张图你看看是否可行吧
作者: 大雁南飞    时间: 2010-12-14 12:41
这个需求用因果图,确实有大炮打蚊子的感觉,不过用作举例比较容易理解,今天给大家讲解的时候发现约束混乱,重新整理了一下,显的清楚一些。谁喜欢画图,给做个因果图,就完整了。XTTest流程图很简明,加上部门非空,人员为空的分支就完美了。
[attach]67097[/attach]
作者: XZTest    时间: 2010-12-14 14:13
“部门为空”和“部门非末级”的E关系并不准确(R也不准确),但是没有别的关系好用了
作者: kunty    时间: 2010-12-14 22:09
回复 15# lilycheng1986


    不是吧?我们老大还想让我们用这些理论,不然设计的测试用例似乎没有说服力
作者: 大雁南飞    时间: 2010-12-15 22:30
XZTest画的因的果图加上了,还画蛇添足的配了个图形解读.虽然比较烦琐,却也是思考问题的一种好方法
[attach]67124[/attach]
作者: zllphoenix    时间: 2010-12-16 20:17
把XZTest画的因的果图加上了,还画蛇添足的配了个图形解读.虽然比较烦琐,却也是思考问题的一种好方法
大雁南飞 发表于 2010-12-15 22:30


有了错误不用怕,有了问题不用怕,咱们就地解决,我们都是热爱学习的好孩子
作者: zhifei.xie    时间: 2010-12-17 16:52
什么因果图都是理论一套一套的,在实际的项目中根本就用不到!理论只能作为指导,不能依葫芦画瓢!
作者: jiangxinlu    时间: 2010-12-20 17:28
很久都没来逛论坛了,我也来凑个热闹吧。
作者: jiangxinlu    时间: 2010-12-20 17:40
不同的测试方法只是我们的测试手段不一样,每一种测试方法都有一定的局限性,也有一定的优点。
就拿因果图来说,因果图可以帮助我们理解业务,捋清楚思路。
根据目前所掌握的信息,因果图在计算和测试报表时候很适用,我们根据实际业务找到所有影响预期结果、测试对象的因素,分析这些因素的状态、活动、时序图,就可以得到我们想要的测试用例了
作者: zbjie    时间: 2010-12-23 15:34
刚学完因果图,自我感觉在规模很小项目里或小模块里用还行,如果是总体来搞,几乎不可能,单单一个售货机的图,把人都画二了。需要很专业的人才能搞懂。所以用它来做小项目可以,大项目绝对不行,太费时间。
作者: wyfyan    时间: 2010-12-24 16:48

我也没用过耶
作者: ailen1986    时间: 2010-12-24 16:59
我们公司好像也没有用因公图黑盒测试方法额
作者: mcfnhm    时间: 2010-12-24 21:13
手动功能测试  路过
作者: mcfnhm    时间: 2010-12-24 21:15
手机软件测试官方群 110925696
做手机测试的朋友们欢迎加入,共同学习交流
【加入时,验证信息处写上常用的两种测试方法,否则不通过】
作者: 阿七    时间: 2010-12-27 10:57
本帖最后由 阿七 于 2010-12-27 11:00 编辑

这个问题要和 等价类 和 边界值 比较来看了...
     等价类划分方法和边界值分析法都是着重考虑输入条件,并没有考虑到输入情况的各种组合,也没考虑到各个输入情况之间的相互制约关系。如果在测试时必须考虑输入条件的各种组合,可能的组合数将是天文数字。因此必须考虑描述多种条件的组合,相应地产生多个动作的形式来考虑设计测试用例,这就需要利用因果图。
     以QQ登录界面为例,我们一开始只是关注到QQ帐号或QQ密码这两个输入框,是分别进行分析和测试用例设计的,但当我们突然发现,要是把两个输入框一起进行测试的话,那么该怎么测试呢?好象两个输入框之间要同时进行测试的话,要考虑的问题就不是只关注一个输入框那么简单了。
     我们设想一下,要考虑全面的话,那么QQ登录界面上有两个输入框,把每个输入框的等价类拿过来:
    (一)QQ帐号
                       有效的:(1)长度在6-10位之间       (2)类型是0-9自然数
                       无效的:(1)长度小于6       (2)长度大于10       (3)负数        (4)小数       (5)英文字母       (6)字符       (7)特殊字符        (8)中文       (9)编程语言中的转义字符       (10)空         (11)空格
    (二)QQ密码
                       有效的:(1)6-16位       (2)空格       (3)负数       (4)小数       (5)英文字母       (6)字符       (7)特殊字符         (8) 编程语言中的转义字符   
                       无效的:(1)<6位       (2)>16位         (3)空         (4)保留字          (5)功能键(ESC、ENTER、TAB、SHIFT、CTRL、Caps Lock、Backspace、Alt)        (6)汉字
     如果把两个输入框的等价类进行组合的话,需要多少个测试用例呢?  13*14=182个,是不是很多啊?要知道,用最少的测试用例去进行最大的测试覆盖,这种组合就很多了,效率也低。

     下面拿教科书上的一段话来看看因果图的原理吧:
      (一) 因果图法的来源 
              大家熟悉的等价类划分法和边界值分析法,都是着重考虑输入条件,但未考虑输入条件之间的联系,相互组合等;
              但是,如考虑所输入条件之间的相互组合,会由于组合情况数目相当大,需要大量的测试用例;因果图法,是一种帮助人们系统地选择一组高效率测试用例的方法。
      (二) 因果图法的特点 
              考虑输入条件间的组合关系;
              考虑输出条件对输入条件的信赖关系,即因果关系;
              测试用例发现错误的效率高;
              能检查出功能说明中的某些不一致或遗漏;
              因果图方法最终生产的就是判定表,它适合于检查程序输入条件和各种组合情况。
      (三) 因果图法基本步骤
             1. 分割功能说明书对于规模比较大的程序来说,由于输入条件的组合数太大,所以很难整体上使用一个因果图。我们可以把它划分为若干部分,然后分别对每个部分使用因果图。例如,测试编译程序时,可以把每个语句作为一个部分。
             2. 识别出“原因”和“结果”,并加以编号所谓原因,是指输入条件或输入条件的等价类;而结果则是指输出条件或输出条件的等价类。每个原因或结果都对应于因果图中的一个节点。当原因或结果成立(或出现)时,相应的节点取值为1,否则为0。
             3. 根据功能说明书中规定的原因和结果之间的关系画出因果图因果图的基本符号如图1所示:
                                         [attach]67526[/attach]
                                                       因果图的基本符号
         图中左边的节点表示原因,右边的节点表示结果。恒等、非、或、与的含义:
                     恒等:若a=1,则b=1;若a=0,则b=0;
                     非:若a=1,则b=0,若a=0,则b=1;
                     或:若a=1或b=1或c=1,则d=1;若a= b= c=0,则d=0;
                     与:若a= b= c=1,则d=1;若a=0或b=0或c=0,则d=0。
          画因果图时,原因在左,结果在右,由上而下排列,并根据功能说明书中规定的原因和结果之间的关系,用上述基本符号连接起来。在因果图中还可以引入一些中间节点。
               4. 根据功能说明在因果图中加上约束条件由于语法或环境限制,有些原因与原因之间、原因与结果之间的组合情况不可能出现。为表明这些特殊情况,在因果图上用一些记号表明约束或限制条件。因果图的约束条件如图所示:      
                                                  [attach]67527[/attach]
        其中互斥、包含、唯一、要求时对原因的约束,屏蔽是对结果的约束。他们的含义如下:
              互斥E:表示不同时为1,即a,b,c中至多只有一个1;
              包含I:表示至少有一个1,即a,b,c中不同时为0;
              唯一O:表示a,b,c中有且仅有一个1;
              要求R:表示若a=1,则b必须为1。即不可能a=1且b=0;
              屏蔽M:表示若a=1,则b必须为0
              5. 根据因果图画出判定表画判定表的方法一般比较简单,可以把所有原因作为输入条件,每一项原因(输入条件)安排为一行,而所有的输入条件的组合一一列出(真值为1,假值为0),对于每一种条件组合安排为一列,并把各个条件的取值情况分别添入判定表中对应的每一个单元格中。   (关于这个方法的实例,可以看下19楼---大雁南飞的xls.)   
              6. 为判定表的每一列设计一个测试用例即为从因果图中导出的判定表中的每一列设计一个测试用例。

总结: 因果法在实际的应用中,还是比较少用的.大部分人使用了等价类基本上就可以应付过去了.但是要指出的是,如果遇到情况很多的时候,可以先使用因果图组合过滤掉一些用列,这样可以节省一些时间并且提高了覆盖率.
作者: theyoungest    时间: 2011-1-9 22:28
回复 37# 阿七
不错。
作者: liujing6616    时间: 2011-1-11 09:14
初步了解了因果图法,谢谢!
作者: 061001    时间: 2011-1-11 09:45
实际中没有用到过
作者: 会飞的11年    时间: 2011-2-23 10:39
学习了
作者: a5914361    时间: 2011-11-22 15:48
对于业务复杂或者输入非常多的软件,使用因果图得到用例是很困难的,输入条件多导致中间状态也很多,最后画的非常混乱,自己都找不到北了。




欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/) Powered by Discuz! X3.2