因果图在测试中的实用价值有多大？（10-12-6）（获奖名单已公布）
因果图在测试中的实用价值有多大？在系统测试的用例设计方法中，许多书籍和文章都提到了因果图的方法，但总是拿几个案例在反复的引用（自动售
货机、字母判断、象棋...），很少见到在具体应用软件中的案例。
因果图的方法在具体软件中的实用价值有多大，其适用范围及能否用更简单的方法替代，最好有实例说明。
如果你也有问题想提出来和大家一起讨论，请点击此处>>
说不定下期讨论的问题就是由你提出的哦，请快快参与吧！
http://bbs.51testing.com/attachments/month_0811/20081125_650d7dccd46be6244f27oXDjE0HoDhyX.gif
本次奖项空缺 我们公司的测试，估计没人用因果图 因果图有助于分析业务规则，理清因果关系，画因果图不是最终目的，通过画因果图帮助我们分析，最终导出决策表，从决策表得到测试用例 因果图是为了辅助分析业务关系，虑清关系，减少路径复杂度。它能让我们在利用判定表时去除无限用例。 实际业务场景的因果图会变得非常庞大，不方便分析，而且可以用其他方法替代。所以有书上将因果图称作“鸡肋”也是可以理解的。 谁能提供一些在测试过程中使用的案例
对于业务分析，活动图和状态图是很通用的，那么因果图的优势在哪里？ 我在测试案例和测试需求编写时基本不用，真的是很鸡肋。
老实说，测试工作一向是很紧张的，经常是被开发进度压的测试只有一点时间，如果还要花费大量时间在因果图上，那测试工作基本就开展不下去了。 要搞清楚因果图究竟有多少实用价值，就要明白因果图的作用和副作用是什么。
因果图能够保证组合逻辑的完整覆盖，因此能够对于质量有很大的保证，但是其副作用就是最终生成用例数量庞大。
所以在当下追求投入产出比而忽略软件质量的年代，就很少被人所使用了。但是如果真的不计投入的保证质量，那么因果图就一定会是首选方法之一。 另外案例就那么几个是因为很多人并不清楚它的真正特性，只要知道了其特点，创造更多的事例只是是否愿意的事情了。 话说 我只有在面试的时候 画过因果图
工作的过程中 还真没画过
是挺鸡肋的 学过，但从来没用过，主要还是业务分析 路过，学习。 因果图个人理解就是能快速，清晰的理解业务，对整体流程的认识有一个感观上的认识，有助力于测试用例的点的提炼 有谁实际用过，给大家说一下，共同提高吗，呵呆 我们连边界值都很少用到，更何况因果图呢。
有时候用一下边界值或等价类划分吧，组长还要跟我说，你不要这么纠结…… 因果图还是很有用的，关键是看怎么用，当来了一个新项目进行测试而又没有头绪的时候，用它来理理思路还是很不错的，因果图更适合于分析，而不是最后的设计 其实书中强调了另一个方面的问题，你的测试项目－>业务的复杂性，决定你是否使用因果图。如本人在测试ERP项目，如仓库管理这块，会涉及到仓库、库区、储位之间逻辑关系，一个厂区有多个仓库，一个仓库对应多个库区，一个库区有多个储位，材料的入库、发放，需要根据厂区、事业部、公司、车间来判断，并且不同事业部之间会存在材料的调拨，供应商送给仓库的材料有几千种，几百种大类，需要设计算法控制，分别入到对应储位上以及入库、移库等过程。使用因果图，理清之间的逻辑关系，设计比较可行的测试用例，可以尝试多种情况的可能性，另外就是时间上花得很久，所以也比较赞同上述网友的说法，我本人观点，跟业务流程有关。 业务流程的分析UML的方法已经很通用了，如状态图、活动图，时序图等等，而用因果图来分析业务的话，如果业务复杂，那么因果图的线条数量会很多，甚至出现大量交叉，看起来非常不直接，如果不是用来得出用例，仅仅分析业务的话，正确性不容易保证，而且拿来评审的话，开发和用户更不容易看不懂了。谁那里有以前的案例能拿来分享讨论么？ :) 刚好前几天为了给组里的同事讲解一下因果图法,自己做了一个简单的判定表例子,感觉比默默巫提到的几个例子(自动售货机、字母判断、象棋...）更容易理解一点,给大家分享一下 回复 19# 大雁南飞
首先感觉原因的划分上存在冗余，“部门非末级”和“部门为末级”可以合并为一个原因，“人员为空”和“人员不为空”也可以合并为一个原因，在画因果图的时候直接用“非”的关系就可以了（减少了约束关系）；
另外，在程序处理的时候，考虑效率原因，为空的判断一般在其他判断上层，因此第一和第二个测试用例其实走的是相同的路径，第三和第五条用例也同样
因此，如果从流程图的角度去分析这个需求感觉比因果图更加方便和直观
