扫码获取 VIP 码
添加管理员微信获取 VIP 码
因果图法（Cause-Effect Graphing）是黑盒测试用例设计方法中一种以图形化和逻辑化为核心的经典技术。它从软件规格说明书中提取"原因"和"结果"两类要素，用图形化的方式把输入条件与输出结果之间的逻辑关系表达出来，再将这种图形转化为判定表，最终由判定表逐列生成测试用例。在软考的语境下，因果图法被归入基于规格说明的功能测试方法大类，与等价类划分法、边界值分析法、判定表法、场景法等并列，是软件评测师、软件设计师、系统架构设计师等多个科目反复考查的知识点。
要准确理解因果图法，必须先厘清两个最基础、也最容易混淆的概念。第一个概念是"原因"（cause），它指的是软件的输入条件，或者输入条件的等价类划分结果。例如一个登录功能，用户名是否为空、密码是否为空、密码是否正确，这三项各自就是一个原因。第二个概念是"结果"（effect），它指的是软件的输出结果，或者系统状态的改变。例如登录成功、提示用户名不能为空、提示密码错误、账户被锁定，这些就是结果。这里特别需要强调的是，结果并不等同于"程序打印出来的返回值"，系统内部状态的迁移同样属于结果，这一点是命题人经常设置的隐性考查点。
因果图法之所以在众多黑盒测试方法中占有独特地位，是因为它解决了一个其他方法难以覆盖的问题：当多个输入条件之间存在逻辑组合关系时，如何系统性地、既不遗漏也不冗余地把所有有效组合都枚举出来。等价类划分法一次聚焦于单个输入条件的有效等价类和无效等价类，边界值分析法则聚焦于输入取值在边界附近的特殊情况，它们都默认输入条件之间是相互独立的。然而现实中的功能需求往往不是这样，一个结果的出现常常同时依赖于多个输入条件的组合。因果图法正是为了应对这种"组合依赖"而诞生的，它借助布尔逻辑把原因与结果之间的与、或、非、异或等关系显式地画出来，从而把复杂的逻辑组合转化为可穷举、可核查的判定表。
从起源上看，因果图法最早由 IBM 的工程师 William Elmendorf 于 1973 年正式提出，最初的目标就是为测试人员提供一种能够从规格说明中自动推导测试用例的系统化手段。经过几十年的演进，因果图法虽然在实际工程中逐渐被判定表法、成对测试、组合测试等工具所替代，但它在软考考试体系中的地位始终稳固。原因在于，因果图法最能体现"从需求逻辑出发设计测试"的方法论思想，考试命题也正是看中了它这种"逻辑推导"的特质，把它作为考查考生是否理解黑盒测试本质的试金石。
因果图法的底层原理，本质上是把自然语言描述的功能需求，翻译成布尔代数的逻辑表达式，再通过逻辑运算的穷举来覆盖所有可能的组合。整个过程可以抽象为"提取——画图——约束——转表——生成用例"五个阶段，其中最关键、也最体现技术含量的，是"画图"与"转表"这两个环节。
因果图使用四类基本符号来表达原因与结果之间的逻辑关系。第一类是恒等（identity），它表示原因成立时结果就成立，原因不成立时结果就不成立，二者是直接的对应关系。第二类是非（NOT），它表示原因成立时结果反而不成立，原因不成立时结果反而成立，是一种取反的对应关系，在图中通常用一个圆圈或斜杠加在连线上表示否定。第三类是或（OR），它表示多个原因中只要有任意一个成立，结果就成立，对应布尔代数中的逻辑或运算。第四类是与（AND），它表示必须所有相关原因同时成立，结果才成立，对应布尔代数中的逻辑与运算。这四种符号构成了因果图法的全部表达能力，任何复杂的业务逻辑，都可以通过这四种关系的组合来刻画。
除了原因与结果之间的基本逻辑符号，因果图还引入了一组约束符号，用于刻画输入条件之间、输出结果之间存在的天然限制。这组约束是因果图法区别于普通逻辑表达式的地方，也是考试中最容易丢分的细节。输入端的约束有三种：互斥约束（E 约束，Exclusive）表示多个原因中至多只能有一个成立；包含约束（I 约束，Inclusive）表示多个原因中至少有一个成立；唯一约束（O 约束，One and only one）表示多个原因中有且仅有一个成立。输出端的约束有两种：要求约束（R 约束，Require）表示当某个结果成立时，另一个结果也必须成立；屏蔽约束（M 约束，Mask）表示当某个结果成立时，另一个结果必然不能成立。这些约束符号的引入，使得因果图能够精确地排除那些在现实中不可能出现的组合，从而大幅压缩判定表的规模。
判定表（decision table）是因果图法的核心中间产物，也是最终生成测试用例的直接依据。把因果图转换为判定表，通常遵循三个步骤。第一步是列全组合：把图中所有的原因作为条件项，穷举这些原因取真值或假值的全部组合，每一行代表一种原因的真假取值组合。第二步是判定结果：针对每一种原因组合，依据因果图上的逻辑符号与约束符号，推导出对应的结果取值，填入结果项。第三步是化简合并：把那些原因组合不同、但产生的结果完全相同的列合并，或者把由约束条件排除掉的非法组合删除，从而得到精简后的判定表。判定表的每一列，最终就对应一条测试用例——原因的真假取值就是这条用例的输入条件设定，结果的取值就是这条用例的预期输出。
需要特别指出的是，判定表通常被拆分为四个区域：条件桩（列出所有输入条件）、条件项（每一列中各个条件的取值）、动作桩（列出所有可能的输出动作）、动作项（每一列中各个动作是否执行）。因果图法所生成的判定表，其条件桩就是原因，动作桩就是结果，条件项与动作项则分别对应原因的真假取值和结果的成立与否。理解了这层对应关系，就能明白为什么教材中常说"因果图法可以看作是生成判定表的一种系统化方法"。
为了更具体地说明这一转换过程，可以设想一个最常见的登录功能作为实例。假设规格说明规定：当用户名正确且密码正确时，登录成功；当用户名正确但密码错误时，提示密码错误；当用户名不正确时，提示用户名不存在；并且系统规定，密码连续错误超过五次后账户被锁定。在这个例子中，原因有三个，分别是用户名是否正确、密码是否正确、错误次数是否超过五次，结果有四个，分别是登录成功、提示密码错误、提示用户名不存在、账户被锁定。画图时，用户名正确与密码正确这两个原因通过一个"与"关系连接到"登录成功"这个结果；用户名正确与密码不正确这两个条件组合，通过"与"关系连接到"提示密码错误"这个结果，其中"密码不正确"是"密码正确"的"非"；用户名不正确的"非"关系直接连接到"提示用户名不存在"；错误次数超过五次这个原因，单独通过恒等关系连接到"账户被锁定"。画完这张图之后，把所有原因的真假取值穷举出来，会得到八种组合，其中某些组合在现实中不可能发生，例如"用户名不正确"与"密码正确"同时成立但系统却无法校验密码，这类组合就需要借助输入端的约束符号加以排除。最终留下的有效组合逐列填入判定表，每一列就是一条测试用例。这个实例完整地展示了从"提取原因结果"到"画图标注约束"再到"转表生成用例"的全过程，也说明了为什么因果图法在处理多条件组合时比单纯的等价类划分法更可靠。
因果图法并不是万能的，它有自己的适用场景和明确的边界条件，考生必须能够准确判断"什么时候该用因果图法"，这也是选择题中常见的设问方向。
因果图法最适合处理输入条件之间逻辑关系复杂、且输出结果高度依赖这些组合的功能模块。典型的适用对象包括：业务规则密集的校验模块，例如表单校验、权限校验、交易规则判断；控制逻辑清晰的流程控制程序，例如状态机驱动、条件分支密集的代码；以及那些输入输出因果关系明确的嵌入式控制逻辑。当软件规格说明能够清晰、无歧义地表达为"如果满足某组条件，就产生某组结果"的形式时，因果图法就能发挥最大价值。
因果图法的局限同样明显。第一，当输入条件数量较多时，原因组合的数量呈指数级增长，因果图会迅速膨胀到难以手工维护的程度，判定表也会变得异常庞大。第二，因果图法要求原因和结果之间必须是离散的布尔逻辑关系，对于连续取值的输入、时序相关的逻辑、以及涉及大量状态历史的过程，它难以表达。第三，因果图法本身不解决输入条件取什么值的问题，它只解决"哪些条件组合应该被覆盖"，因此在实际测试中，因果图法通常需要与等价类划分法配合使用，先用等价类划分缩小输入域、确定每个原因的取值边界，再用因果图法穷举组合。