做软件测试的朋友应该都听过因果图法它是黑盒测试里非常经典的一种用例设计方法也是软件测试面试题里反复出现的高频考点。尤其是准备银行外包项目、金融类系统的朋友面试官特别喜欢拿因果图法来试探你的逻辑分析能力。这篇文章我就用自己的实战经验把因果图法的原理、完整步骤、真实项目案例、面试答题思路和踩过的坑一次讲清楚不管你是刚入行的测试新人还是已经工作几年想补基础的同学都能直接照着用。因果图法本质上解决的是一个很现实的问题当被测功能的输入条件不止一个、且条件之间存在组合逻辑关系时靠等价类划分和边界值分析很难把所有重要场景覆盖全而盲目做全排列组合又会让测试用例数量爆炸。因果图法通过分析“输入条件”和“输出结果”之间的逻辑关系把需求里的隐藏规则显式化再用判定表把组合情况系统展开最终用最少的用例覆盖最全的逻辑分支。这里面每一步都有讲究下面我按实际做事的顺序慢慢拆。1. 因果图法到底解决什么问题1.1 一次让我翻车的面试我第一次面试软件测试岗位的时候面试官问了一句“你用过因果图法吗”我当时把定义背得滚瓜烂熟什么“分析输入与输出之间的因果关系”之类结果他让我现场对一个登录功能画因果图再列出测试用例。我当场卡住因为我就没真正拿它分析过需求只是背了概念。那次面试之后我才明白因果图法不是用来背的是用来“拆需求”的。后来进了项目组接手一个银行转账模块需求文档里写了七八条手续费规则产品经理还不停补充特殊情况。我刚开始用等价类加边界值硬写用例写了几十条自己心里都没底总感觉有组合规则漏掉了。后来老测试带我用因果图法重新梳理了一遍需求逻辑才把规则一条条理顺。从那以后凡遇到“多条件、多分支、规则之间还有优先级”的需求我都习惯性用因果图法的思路去拆。1.2 黑盒测试全家桶里的“组合专家”软件测试中常用的黑盒测试用例设计方法有这么几个等价类划分、边界值分析、因果图法、判定表驱动法、正交试验设计、错误推测法、场景法等。它们各有分工。等价类和边界值主要解决“单个输入条件取什么值”的问题错误推测法靠的是测试人员的经验而因果图法和判定表法专门解决“多个输入条件之间组合逻辑怎么覆盖”的问题。我举个简单例子一个下单页面有优惠券状态、是否满足起送价、配送时段三个条件每个条件都有两种状态。全排列组合3个条件2个取值一共2的3次方总共8种组合你靠脑子一个个列可能还列得清。但如果条件变成6个每个条件3种取值全组合就是729种你不可能全部手测也没必要全测。这时候需要用逻辑分析方法把真正会对结果产生影响的组合筛出来。因果图法就是干这个的。它和判定表法又是什么关系呢理解可以这样因果图负责把需求里的“逻辑关系”可视化让人看清哪个原因影响哪个结果判定表负责把这种关系系统地展开成“条件组合 动作结果”的二维表格方便直接生成测试用例。因果图是分析工具判定表是输出格式两者配合使用因果图法才会有落地的效果。2. 因果图法的核心原理拆解2.1 四个必须知道的基本符号因果图法里最基础的内容是四种逻辑关系分别表示“原因”和“结果”之间不同的影响方式。刚学的时候觉得这些符号很抽象其实对应到业务需求里非常直观。符号关系名称逻辑含义口语化理解实际例子恒等原因出现结果就出现条件成立结果必然发生勾选“同意协议”输入框解锁非原因不出现结果才出现条件不成立结果反而发生不勾选“自动登录”登录后不记住密码或∨或任一原因出现结果就出现满足任意一个结果就发生手机号或邮箱任一已验证可绑定账号与∧与所有原因都出现结果才出现几个条件都满足结果才发生账号存在且密码正确登录才成功这里要注意“非”关系是最容易忽略的。需求里经常出现“如果用户不满足某某条件则执行某某逻辑”这种表述翻译成因果图就是“非”关系。很多新手画图只会在“正向条件”之间连逻辑忘了处理取反的分支结果漏掉一整个测试场景。2.2 五种约束关系这才是画图的灵魂基本逻辑关系只是第一步真正让因果图法产生价值的是原因与原因之间、结果与结果之间的约束关系。约束关系解决的是“现实中哪些组合允许存在”的问题。约束名称含义业务例子E互斥Exclusive两个原因不能同时成立支付方式里的“余额支付”和“银行卡支付”不能同时选I包含Inclusive至少一个原因必须成立购买保险时必须选择至少一种附加险O唯一One有且只有一个原因成立还款渠道只能从三个渠道中选择一个R要求Required一个原因成立时另一个也必须成立选择“对公转账”必须填写“收款单位账号”M屏蔽Mask一个原因成立时另一个被屏蔽选择“现金支付”时“使用优惠券”选项被屏蔽我见过很多测试同学画因果图逻辑符号画得挺标准但完全不考虑约束关系结果判定表里列出了大量现实中根本不可能出现的组合。比如一个支付页面的“支付方式”同时选了余额和银行卡这在界面上根本无法操作你把这种组合写进测试用例既浪费执行时间又无法真实复现。所以约束关系不是额外加分项而是必须处理的核心环节。2.3 因果图到判定表为什么要“两步走”有人问因果图画出来了逻辑也清楚了为什么还要转成判定表直接根据图写用例不行吗现实原因是因果图虽然直观但“从图到用例”的过程缺少一个可检查的中间产物。画图的人觉得看懂了换一个人来看可能理解又不一样。判定表的好处是结构化。它由四部分组成条件桩所有的输入条件、动作桩所有的输出结果、条件项每个条件的取值组合、动作项每种组合对应的输出动作。把因果图里的逻辑关系填进判定表每一个组合对应一条规则规则清晰可审查。判定表还可以化简。如果两条规则的“条件项”里只有一个条件取值不同、其他条件相同而且对应的“动作项”完全相同那这两条规则可以合并不同取值的那个条件标记为“-”不关心。化简之后测试用例数量会明显减少同时逻辑覆盖不丢。这一步是因果图法的核心价值所在。3. 完整实战银行转账手续费怎么用因果图法设计用例3.1 需求原文与初步分析我这里用一个我在银行类项目里反复用过的经典场景说明因果图法怎么落地。假设有一个手机银行转账功能需求描述如下转账金额在5万元含以下手续费为0转账金额超过5万元超出部分按0.05%收取手续费最低1元最高50元贵宾客户VIP转账免收手续费免收范围不受金额限制用户选择“实时到账”方式时额外加收2元加急费加急费不因VIP身份减免。先不要急着写用例按因果图法的流程来提取原因和结果画因果图加约束转判定表最后生成用例。初步分析这个需求能发现几个关键点手续费是否收取和“转账金额”以及“是否VIP”有关金额又分“5万及以下”和“5万以上”两种状态加急费只和“是否选择实时到账”有关和VIP身份没有关系。这些就是原因与结果之间逻辑关系的起点。3.2 提取原因和结果我把输入条件拆成原子条件并给每个条件编号方便后面画图和建表。原因输入条件C1转账金额在5万元含以下C4转账金额超过5万元C2用户是贵宾客户VIPC3用户选择“实时到账”方式这里特意把“金额在5万以下”和“金额超过5万”拆成了两个条件目的是为了在因果图里展示“互斥约束”。如果只用一个条件“金额是否超过5万”那逻辑上也能表达但就无法演示互斥约束的用法了而且实际需求文档里两条规则是分开描述的拆开更贴近需求原文。结果输出结果E1手续费为0E2按超出部分比例收取手续费最低1元最高50元E3加收2元加急费3.3 画因果图和约束关系我一般习惯把原因放左边结果放右边中间用逻辑门连接。这个需求的核心逻辑表达式可以写成E1 C1 OR C2 E2 (NOT C2) AND C4 E3 C3 约束C1 与 C4 互斥E约束含义分别是手续费为0的条件要么金额不满5万要么是VIP用户两者满足一个即可按比例收费的条件必须是非VIP用户且金额超过5万两个条件同时成立才触发加急费只和到账方式有关条件成立就触发。如果画成文本示意图大概是这个样子C1(金额≤5万) ------ --- [或] --- E1(手续费为0) C2(VIP用户) ------- C2(VIP用户) ---[非]--- --- [与] --- E2(按比例收费) C4(金额5万) -------- C3(实时到账) ---------------------- E3(加收加急费) 约束C1 互斥 C4实际画图时用ProcessOn、draw.io或者Visio都可以图形符号按照因果图法的标准来。画图的顺序建议是先把每个结果节点往前找原因节点找到后判断是“与”“或”还是“非”的关系最后再统一检查原因与原因之间有没有约束关系。不要一上来就乱连线不然画到一半自己就乱了。3.4 生成并化简判定表因果图画完接下来转成判定表。条件桩是C1、C4、C2、C3动作桩是E1、E2、E3。我按这个顺序列出所有有效组合。由于C1和C4互斥也就是“金额≤5万”和“金额5万”不可能同时成立所以实际有效条件组合是C11时C40C10时C41不会出现C1和C4同时为1的情况。这样一共有8种有效组合对应规则如下规则C1(≤5万)C4(5万)C2(VIP)C3(实时)E1(免手续)E2(比例收费)E3(加急费)场景描述11000100普通用户转2万普通到账21001101普通用户转2万实时到账31010100VIP转2万普通到账41011101VIP转2万实时到账50100010普通用户转10万普通到账60101011普通用户转10万实时到账70110100VIP转10万普通到账80111101VIP转10万实时到账可以看到规则1和规则3除了C2取值不同其他条件都一样动作项也完全一致可以合并C2标记为“-”表示该条件不管取哪个值结果都一样。规则2和规则4也可以同样合并。化简后得到6条规则规则C1C4C2C3E1E2E3A10-0100B10-1101C0100010D0101011E0110100F0111101注意化简不等于让你少测。实际设计用例时规则A虽然C2标记为“-”但为了确认VIP用户和非VIP用户在界面提示或系统日志上有没有细微差异我一般还是会分别执行一遍。逻辑等价的规则在测试执行上可以合并但“逻辑等价”不代表“系统表现完全一致”这一点后面讲坑的时候还会展开。3.5 从判定表到可执行的测试用例判定表里的每条规则都能直接映射成一条或几条测试用例。我在生成用例时会根据规则A到F补充上具体的测试数据。金额选择要考虑边界值比如刚好5万、超过5万一点点、超出部分收费结果触发最低值或封顶值。对应测试用例如下用例编号转账金额用户身份到账方式预期结果TC-0130000.00普通用户普通到账手续费0元TC-0230000.00普通用户实时到账手续费0元 加急费2元TC-0330000.00VIP普通到账手续费0元TC-0430000.00VIP实时到账加急费2元TC-05100000.00普通用户普通到账手续费25元TC-06100000.00普通用户实时到账手续费25元 加急费2元TC-07100000.00VIP普通到账手续费0元TC-08100000.00VIP实时到账加急费2元TC-0950000.00普通用户普通到账手续费0元金额边界TC-1050001.00普通用户普通到账手续费1元最低收费TC-111100000.00普通用户普通到账手续费50元封顶收费TC-05的25元怎么来的转账10万超出部分5万按0.05%计算是50000乘以0.0005等于25元。TC-10是超过5万1块钱理论上超出部分1元乘以0.05%等于0.0005元不足最低收费1元所以按规则要收最低1元手续费。TC-11里超出部分105万乘以0.05%是525元超过50元封顶线所以按50元收。这些边界值用例是等价类边界值分析的补充实际做测试时通常会把因果图法、等价类划分、边界值分析三个方法搭配着用面试时主动说出这个组合是很加分的。4. 常见问题与排查技巧实录4.1 新手最容易踩的6个坑第一个坑把“原因”拆得过粗或过细。拆得太粗比如把“输入正确且点击确认”当成一个原因逻辑关系就分析不清楚拆得太细比如把“点击确认按钮”拆成“鼠标按下”和“鼠标释放”又完全没有必要。我的经验是一个原因对应一个可以独立判断真假的业务条件拿到需求文档找“如果…那么…”这种句子每个“如果”后的最小条件就是一个原因。第二个坑只画因果图不转判定表。很多新手画完图就觉得自己分析完了直接凭感觉写用例因果图的价值等于没体现。因果图能让你看清逻辑判定表才能让你系统列出所有条件组合两步缺一不可。哪怕不画正式的因果图也要把判定表列出来这是底线。第三个坑漏掉约束关系。这是最普遍的。判断标准很简单你列的判定表里有没有“现实中不可能出现”的规则如果有说明约束没分析全。画完因果图回头逐个检查条件与条件之间是否存在互斥、包含、唯一、要求、屏蔽中的某一种关系。第四个坑把“结果”当“原因”。初学者容易把“手续费为0”这种结果又当作“用户可能选择免手续费通道”的原因导致因果图出现循环。其实结果和原因看方向就行原因是测试人员能控制的输入结果是系统根据输入产生的输出分清楚边界图就不会乱。第五个坑忘记结合边界值。因果图法本身不关心具体数值的边界但实际缺陷经常出现在边界上。上面的转账案例里5万、50001、110万这些金额就是关键边界。因果图法确定“逻辑组合”边界值法确定“数值边界”两者配合才是完整方案。第六个坑合并过度。判定表化简确实能减少规则数量但有一种情况不能乱合并两个条件取值不同、动作结果虽然相同但系统内部处理路径不同比如需要走不同接口、记录不同日志、展示不同提示。这种情况下盲目合并用例出了问题很难定位。4.2 面试被问因果图法这样答不丢分面试官问因果图法通常不是想听你背定义而是想确认你有没有真正用逻辑分析过需求。我总结了一个两分钟答题框架你可以直接套用。先一句话定义因果图法是一种黑盒测试用例设计方法通过分析输入条件与输出结果之间的逻辑关系来设计测试用例适用于多个条件之间存在组合逻辑的场景。然后说核心步骤提取原因和结果画因果图加约束关系转判定表化简后生成测试用例。最后一定要给一个你熟悉的例子哪怕是很简单的登录功能。如果面试官追问“因果图和判定表有什么区别”可以这样回答因果图是可视化分析工具侧重让人看懂逻辑关系判定表是结构化的表格侧重系统列出所有条件组合。实际项目里通常先用因果图理清关系再转成判定表生成用例。如果追问“条件很多判定表很大怎么办”可以回答先梳理约束关系把不可能出现的组合排除再考虑合并动作项相同的规则。如果条件仍然非常多说明这个功能过于复杂可以考虑用正交试验法或者基于风险的测试策略来缩短组合数量不一定非要追求穷举。4.3 不用软件也能画因果图有测试新人问一定要用专业工具才能画因果图吗其实不用。我在实际工作里大部分情况下根本不打开画图软件需求逻辑不复杂时我直接在需求文档旁边列出逻辑表达式再用Excel拉一个判定表效率更高。Excel做判定表有个小技巧把条件桩和动作桩做成列用0和1表示真假然后用IF、AND、OR组合公式去校验“动作项”是否符合预期。比如在动作项那一列写类似IF(OR(C11,C21),1,0)的公式系统会自动判断当前行的条件组合对应什么结果比自己肉眼检查快得多也避免人工出错。如果确实需要画因果图ProcessOn、draw.io、Visio都行XMind也能画类似的结构图。工具不重要重要的是把“原因、结果、逻辑、约束”四个要素梳理清楚。画图本身不是目的搞清楚需求逻辑才是。5. 写在最后个人体会和一条建议我个人在实际项目里最大的感受是因果图法最有价值的地方不是那张图画得多漂亮而是它逼着你把需求里“隐藏的逻辑”显式化。很多需求文档里的规则看起来清清楚楚翻译成“与或非”的时候你才会发现自己对某条规则的理解是模糊的。我在需求评审阶段用过好几次因果图法把画好的因果图或者判定表发给产品经理确认经常能提前发现需求逻辑漏洞这个价值比测试用例本身的覆盖面还要大。最后给一条建议不要为了画图而画图。如果被测功能只有两三个输入条件直接列判定表就够了画因果图反而显得啰嗦只有当条件多、关系复杂、还有优先级和互斥约束的时候才值得完整走一遍“因果图加判定表”的流程。软件测试的核心思路要比工具方法更优先只要建立了“找原因、找结果、找关系、找约束”的思维习惯哪怕不画图也能把测试用例设计得比大多数人系统。
因果图法实战：从原理到判定表的测试用例设计全攻略
做软件测试的朋友应该都听过因果图法它是黑盒测试里非常经典的一种用例设计方法也是软件测试面试题里反复出现的高频考点。尤其是准备银行外包项目、金融类系统的朋友面试官特别喜欢拿因果图法来试探你的逻辑分析能力。这篇文章我就用自己的实战经验把因果图法的原理、完整步骤、真实项目案例、面试答题思路和踩过的坑一次讲清楚不管你是刚入行的测试新人还是已经工作几年想补基础的同学都能直接照着用。因果图法本质上解决的是一个很现实的问题当被测功能的输入条件不止一个、且条件之间存在组合逻辑关系时靠等价类划分和边界值分析很难把所有重要场景覆盖全而盲目做全排列组合又会让测试用例数量爆炸。因果图法通过分析“输入条件”和“输出结果”之间的逻辑关系把需求里的隐藏规则显式化再用判定表把组合情况系统展开最终用最少的用例覆盖最全的逻辑分支。这里面每一步都有讲究下面我按实际做事的顺序慢慢拆。1. 因果图法到底解决什么问题1.1 一次让我翻车的面试我第一次面试软件测试岗位的时候面试官问了一句“你用过因果图法吗”我当时把定义背得滚瓜烂熟什么“分析输入与输出之间的因果关系”之类结果他让我现场对一个登录功能画因果图再列出测试用例。我当场卡住因为我就没真正拿它分析过需求只是背了概念。那次面试之后我才明白因果图法不是用来背的是用来“拆需求”的。后来进了项目组接手一个银行转账模块需求文档里写了七八条手续费规则产品经理还不停补充特殊情况。我刚开始用等价类加边界值硬写用例写了几十条自己心里都没底总感觉有组合规则漏掉了。后来老测试带我用因果图法重新梳理了一遍需求逻辑才把规则一条条理顺。从那以后凡遇到“多条件、多分支、规则之间还有优先级”的需求我都习惯性用因果图法的思路去拆。1.2 黑盒测试全家桶里的“组合专家”软件测试中常用的黑盒测试用例设计方法有这么几个等价类划分、边界值分析、因果图法、判定表驱动法、正交试验设计、错误推测法、场景法等。它们各有分工。等价类和边界值主要解决“单个输入条件取什么值”的问题错误推测法靠的是测试人员的经验而因果图法和判定表法专门解决“多个输入条件之间组合逻辑怎么覆盖”的问题。我举个简单例子一个下单页面有优惠券状态、是否满足起送价、配送时段三个条件每个条件都有两种状态。全排列组合3个条件2个取值一共2的3次方总共8种组合你靠脑子一个个列可能还列得清。但如果条件变成6个每个条件3种取值全组合就是729种你不可能全部手测也没必要全测。这时候需要用逻辑分析方法把真正会对结果产生影响的组合筛出来。因果图法就是干这个的。它和判定表法又是什么关系呢理解可以这样因果图负责把需求里的“逻辑关系”可视化让人看清哪个原因影响哪个结果判定表负责把这种关系系统地展开成“条件组合 动作结果”的二维表格方便直接生成测试用例。因果图是分析工具判定表是输出格式两者配合使用因果图法才会有落地的效果。2. 因果图法的核心原理拆解2.1 四个必须知道的基本符号因果图法里最基础的内容是四种逻辑关系分别表示“原因”和“结果”之间不同的影响方式。刚学的时候觉得这些符号很抽象其实对应到业务需求里非常直观。符号关系名称逻辑含义口语化理解实际例子恒等原因出现结果就出现条件成立结果必然发生勾选“同意协议”输入框解锁非原因不出现结果才出现条件不成立结果反而发生不勾选“自动登录”登录后不记住密码或∨或任一原因出现结果就出现满足任意一个结果就发生手机号或邮箱任一已验证可绑定账号与∧与所有原因都出现结果才出现几个条件都满足结果才发生账号存在且密码正确登录才成功这里要注意“非”关系是最容易忽略的。需求里经常出现“如果用户不满足某某条件则执行某某逻辑”这种表述翻译成因果图就是“非”关系。很多新手画图只会在“正向条件”之间连逻辑忘了处理取反的分支结果漏掉一整个测试场景。2.2 五种约束关系这才是画图的灵魂基本逻辑关系只是第一步真正让因果图法产生价值的是原因与原因之间、结果与结果之间的约束关系。约束关系解决的是“现实中哪些组合允许存在”的问题。约束名称含义业务例子E互斥Exclusive两个原因不能同时成立支付方式里的“余额支付”和“银行卡支付”不能同时选I包含Inclusive至少一个原因必须成立购买保险时必须选择至少一种附加险O唯一One有且只有一个原因成立还款渠道只能从三个渠道中选择一个R要求Required一个原因成立时另一个也必须成立选择“对公转账”必须填写“收款单位账号”M屏蔽Mask一个原因成立时另一个被屏蔽选择“现金支付”时“使用优惠券”选项被屏蔽我见过很多测试同学画因果图逻辑符号画得挺标准但完全不考虑约束关系结果判定表里列出了大量现实中根本不可能出现的组合。比如一个支付页面的“支付方式”同时选了余额和银行卡这在界面上根本无法操作你把这种组合写进测试用例既浪费执行时间又无法真实复现。所以约束关系不是额外加分项而是必须处理的核心环节。2.3 因果图到判定表为什么要“两步走”有人问因果图画出来了逻辑也清楚了为什么还要转成判定表直接根据图写用例不行吗现实原因是因果图虽然直观但“从图到用例”的过程缺少一个可检查的中间产物。画图的人觉得看懂了换一个人来看可能理解又不一样。判定表的好处是结构化。它由四部分组成条件桩所有的输入条件、动作桩所有的输出结果、条件项每个条件的取值组合、动作项每种组合对应的输出动作。把因果图里的逻辑关系填进判定表每一个组合对应一条规则规则清晰可审查。判定表还可以化简。如果两条规则的“条件项”里只有一个条件取值不同、其他条件相同而且对应的“动作项”完全相同那这两条规则可以合并不同取值的那个条件标记为“-”不关心。化简之后测试用例数量会明显减少同时逻辑覆盖不丢。这一步是因果图法的核心价值所在。3. 完整实战银行转账手续费怎么用因果图法设计用例3.1 需求原文与初步分析我这里用一个我在银行类项目里反复用过的经典场景说明因果图法怎么落地。假设有一个手机银行转账功能需求描述如下转账金额在5万元含以下手续费为0转账金额超过5万元超出部分按0.05%收取手续费最低1元最高50元贵宾客户VIP转账免收手续费免收范围不受金额限制用户选择“实时到账”方式时额外加收2元加急费加急费不因VIP身份减免。先不要急着写用例按因果图法的流程来提取原因和结果画因果图加约束转判定表最后生成用例。初步分析这个需求能发现几个关键点手续费是否收取和“转账金额”以及“是否VIP”有关金额又分“5万及以下”和“5万以上”两种状态加急费只和“是否选择实时到账”有关和VIP身份没有关系。这些就是原因与结果之间逻辑关系的起点。3.2 提取原因和结果我把输入条件拆成原子条件并给每个条件编号方便后面画图和建表。原因输入条件C1转账金额在5万元含以下C4转账金额超过5万元C2用户是贵宾客户VIPC3用户选择“实时到账”方式这里特意把“金额在5万以下”和“金额超过5万”拆成了两个条件目的是为了在因果图里展示“互斥约束”。如果只用一个条件“金额是否超过5万”那逻辑上也能表达但就无法演示互斥约束的用法了而且实际需求文档里两条规则是分开描述的拆开更贴近需求原文。结果输出结果E1手续费为0E2按超出部分比例收取手续费最低1元最高50元E3加收2元加急费3.3 画因果图和约束关系我一般习惯把原因放左边结果放右边中间用逻辑门连接。这个需求的核心逻辑表达式可以写成E1 C1 OR C2 E2 (NOT C2) AND C4 E3 C3 约束C1 与 C4 互斥E约束含义分别是手续费为0的条件要么金额不满5万要么是VIP用户两者满足一个即可按比例收费的条件必须是非VIP用户且金额超过5万两个条件同时成立才触发加急费只和到账方式有关条件成立就触发。如果画成文本示意图大概是这个样子C1(金额≤5万) ------ --- [或] --- E1(手续费为0) C2(VIP用户) ------- C2(VIP用户) ---[非]--- --- [与] --- E2(按比例收费) C4(金额5万) -------- C3(实时到账) ---------------------- E3(加收加急费) 约束C1 互斥 C4实际画图时用ProcessOn、draw.io或者Visio都可以图形符号按照因果图法的标准来。画图的顺序建议是先把每个结果节点往前找原因节点找到后判断是“与”“或”还是“非”的关系最后再统一检查原因与原因之间有没有约束关系。不要一上来就乱连线不然画到一半自己就乱了。3.4 生成并化简判定表因果图画完接下来转成判定表。条件桩是C1、C4、C2、C3动作桩是E1、E2、E3。我按这个顺序列出所有有效组合。由于C1和C4互斥也就是“金额≤5万”和“金额5万”不可能同时成立所以实际有效条件组合是C11时C40C10时C41不会出现C1和C4同时为1的情况。这样一共有8种有效组合对应规则如下规则C1(≤5万)C4(5万)C2(VIP)C3(实时)E1(免手续)E2(比例收费)E3(加急费)场景描述11000100普通用户转2万普通到账21001101普通用户转2万实时到账31010100VIP转2万普通到账41011101VIP转2万实时到账50100010普通用户转10万普通到账60101011普通用户转10万实时到账70110100VIP转10万普通到账80111101VIP转10万实时到账可以看到规则1和规则3除了C2取值不同其他条件都一样动作项也完全一致可以合并C2标记为“-”表示该条件不管取哪个值结果都一样。规则2和规则4也可以同样合并。化简后得到6条规则规则C1C4C2C3E1E2E3A10-0100B10-1101C0100010D0101011E0110100F0111101注意化简不等于让你少测。实际设计用例时规则A虽然C2标记为“-”但为了确认VIP用户和非VIP用户在界面提示或系统日志上有没有细微差异我一般还是会分别执行一遍。逻辑等价的规则在测试执行上可以合并但“逻辑等价”不代表“系统表现完全一致”这一点后面讲坑的时候还会展开。3.5 从判定表到可执行的测试用例判定表里的每条规则都能直接映射成一条或几条测试用例。我在生成用例时会根据规则A到F补充上具体的测试数据。金额选择要考虑边界值比如刚好5万、超过5万一点点、超出部分收费结果触发最低值或封顶值。对应测试用例如下用例编号转账金额用户身份到账方式预期结果TC-0130000.00普通用户普通到账手续费0元TC-0230000.00普通用户实时到账手续费0元 加急费2元TC-0330000.00VIP普通到账手续费0元TC-0430000.00VIP实时到账加急费2元TC-05100000.00普通用户普通到账手续费25元TC-06100000.00普通用户实时到账手续费25元 加急费2元TC-07100000.00VIP普通到账手续费0元TC-08100000.00VIP实时到账加急费2元TC-0950000.00普通用户普通到账手续费0元金额边界TC-1050001.00普通用户普通到账手续费1元最低收费TC-111100000.00普通用户普通到账手续费50元封顶收费TC-05的25元怎么来的转账10万超出部分5万按0.05%计算是50000乘以0.0005等于25元。TC-10是超过5万1块钱理论上超出部分1元乘以0.05%等于0.0005元不足最低收费1元所以按规则要收最低1元手续费。TC-11里超出部分105万乘以0.05%是525元超过50元封顶线所以按50元收。这些边界值用例是等价类边界值分析的补充实际做测试时通常会把因果图法、等价类划分、边界值分析三个方法搭配着用面试时主动说出这个组合是很加分的。4. 常见问题与排查技巧实录4.1 新手最容易踩的6个坑第一个坑把“原因”拆得过粗或过细。拆得太粗比如把“输入正确且点击确认”当成一个原因逻辑关系就分析不清楚拆得太细比如把“点击确认按钮”拆成“鼠标按下”和“鼠标释放”又完全没有必要。我的经验是一个原因对应一个可以独立判断真假的业务条件拿到需求文档找“如果…那么…”这种句子每个“如果”后的最小条件就是一个原因。第二个坑只画因果图不转判定表。很多新手画完图就觉得自己分析完了直接凭感觉写用例因果图的价值等于没体现。因果图能让你看清逻辑判定表才能让你系统列出所有条件组合两步缺一不可。哪怕不画正式的因果图也要把判定表列出来这是底线。第三个坑漏掉约束关系。这是最普遍的。判断标准很简单你列的判定表里有没有“现实中不可能出现”的规则如果有说明约束没分析全。画完因果图回头逐个检查条件与条件之间是否存在互斥、包含、唯一、要求、屏蔽中的某一种关系。第四个坑把“结果”当“原因”。初学者容易把“手续费为0”这种结果又当作“用户可能选择免手续费通道”的原因导致因果图出现循环。其实结果和原因看方向就行原因是测试人员能控制的输入结果是系统根据输入产生的输出分清楚边界图就不会乱。第五个坑忘记结合边界值。因果图法本身不关心具体数值的边界但实际缺陷经常出现在边界上。上面的转账案例里5万、50001、110万这些金额就是关键边界。因果图法确定“逻辑组合”边界值法确定“数值边界”两者配合才是完整方案。第六个坑合并过度。判定表化简确实能减少规则数量但有一种情况不能乱合并两个条件取值不同、动作结果虽然相同但系统内部处理路径不同比如需要走不同接口、记录不同日志、展示不同提示。这种情况下盲目合并用例出了问题很难定位。4.2 面试被问因果图法这样答不丢分面试官问因果图法通常不是想听你背定义而是想确认你有没有真正用逻辑分析过需求。我总结了一个两分钟答题框架你可以直接套用。先一句话定义因果图法是一种黑盒测试用例设计方法通过分析输入条件与输出结果之间的逻辑关系来设计测试用例适用于多个条件之间存在组合逻辑的场景。然后说核心步骤提取原因和结果画因果图加约束关系转判定表化简后生成测试用例。最后一定要给一个你熟悉的例子哪怕是很简单的登录功能。如果面试官追问“因果图和判定表有什么区别”可以这样回答因果图是可视化分析工具侧重让人看懂逻辑关系判定表是结构化的表格侧重系统列出所有条件组合。实际项目里通常先用因果图理清关系再转成判定表生成用例。如果追问“条件很多判定表很大怎么办”可以回答先梳理约束关系把不可能出现的组合排除再考虑合并动作项相同的规则。如果条件仍然非常多说明这个功能过于复杂可以考虑用正交试验法或者基于风险的测试策略来缩短组合数量不一定非要追求穷举。4.3 不用软件也能画因果图有测试新人问一定要用专业工具才能画因果图吗其实不用。我在实际工作里大部分情况下根本不打开画图软件需求逻辑不复杂时我直接在需求文档旁边列出逻辑表达式再用Excel拉一个判定表效率更高。Excel做判定表有个小技巧把条件桩和动作桩做成列用0和1表示真假然后用IF、AND、OR组合公式去校验“动作项”是否符合预期。比如在动作项那一列写类似IF(OR(C11,C21),1,0)的公式系统会自动判断当前行的条件组合对应什么结果比自己肉眼检查快得多也避免人工出错。如果确实需要画因果图ProcessOn、draw.io、Visio都行XMind也能画类似的结构图。工具不重要重要的是把“原因、结果、逻辑、约束”四个要素梳理清楚。画图本身不是目的搞清楚需求逻辑才是。5. 写在最后个人体会和一条建议我个人在实际项目里最大的感受是因果图法最有价值的地方不是那张图画得多漂亮而是它逼着你把需求里“隐藏的逻辑”显式化。很多需求文档里的规则看起来清清楚楚翻译成“与或非”的时候你才会发现自己对某条规则的理解是模糊的。我在需求评审阶段用过好几次因果图法把画好的因果图或者判定表发给产品经理确认经常能提前发现需求逻辑漏洞这个价值比测试用例本身的覆盖面还要大。最后给一条建议不要为了画图而画图。如果被测功能只有两三个输入条件直接列判定表就够了画因果图反而显得啰嗦只有当条件多、关系复杂、还有优先级和互斥约束的时候才值得完整走一遍“因果图加判定表”的流程。软件测试的核心思路要比工具方法更优先只要建立了“找原因、找结果、找关系、找约束”的思维习惯哪怕不画图也能把测试用例设计得比大多数人系统。
+Skills部署，零基础2分钟搞定QQ集成｜TaoToken统一Key接入)
