“因果分析法”在软件测试和质量管理中虽然名字相同,但属于两个完全不同的领域,目的、方法、图形、输出和应用阶段都截然不同。下面从多个维度进行详细比较。
一、测试用例因果分析法(因果图法)
1. 定义与目的
因果图法(Cause-Effect Graphing)是一种黑盒测试用例设计方法,由 J.D. McCall 等人提出。它的核心目的是:分析输入条件(原因)与输出结果(结果)之间的逻辑关系,通过图形化方式处理输入条件的各种组合,从而设计出覆盖全面且数量精简的测试用例。
2. 核心思想
将需求规格说明中的输入条件视为“原因”,输出动作视为“结果”。
用逻辑门(与、或、非)和约束条件描述原因与结果之间的关系。
将因果图转换为判定表,再根据判定表的每一列(规则)生成测试用例。
3. 主要步骤
识别原因和结果:从需求中找出所有输入条件和对应的输出动作。
分析逻辑关系:确定原因之间、原因与结果之间的与、或、非关系。
分析约束关系:如互斥(E)、包含(I)、唯一(O)、要求(R)、强制(M)。
绘制因果图:用节点表示原因和结果,用连线表示逻辑关系和约束。
转换为判定表:列出所有可能的条件组合及其对应的动作。
设计测试用例:判定表的每一列通常对应一条测试用例。
4. 图形符号
原因节点:用圆圈或椭圆表示。
结果节点:用圆圈或椭圆表示。
逻辑门:
与(∧):所有输入为真时输出为真。
或(∨):任一输入为真时输出为真。
非(~):输入为真时输出为假。
约束符号:
E(互斥):两个原因不能同时为真。
I(包含):至少有一个原因必须为真。
O(唯一):有且仅有一个为真。
R(要求):一个为真时另一个必须为真。
M(强制):一个为真时另一个必须为假。
5. 输出
判定表:条件桩、条件项、动作桩、动作项。
测试用例集:每条规则(判定表的一列)生成一条测试用例。
6. 适用场景
输入条件多、组合复杂,且输出依赖多个输入条件的逻辑关系。
需求规格说明中有明确的输入输出逻辑描述。
需要减少测试用例数量,同时保证覆盖率。
7. 优缺点
优点:能系统覆盖输入组合,避免遗漏;通过逻辑化简减少冗余用例。
缺点:需求复杂时因果图庞大,转换判定表工作量大;不适合输入条件之间无逻辑关系的场景。
8. 简单示例
需求:若输入A和B同时为真,则输出X;若A为真且B为假,则输出Y;否则输出Z。
因果图:A、B为原因,X、Y、Z为结果,逻辑关系为与、非。
判定表:列出A、B的真假组合,对应输出X、Y、Z,生成测试用例。
二、质量管理中的因果分析法(鱼骨图/石川图)
1. 定义与目的
因果分析法在质量管理中通常指鱼骨图(Fishbone Diagram),又称石川图(Ishikawa Diagram)或因果图。它由日本质量管理专家石川馨提出,用于分析问题产生的根本原因。目的是通过团队讨论,从多个维度梳理可能导致问题的原因,找出关键因素并制定改进措施。
2. 核心思想
以问题(结果)为“鱼头”,以原因类别为“主骨”,具体原因为“鱼刺”。
常用分类维度:人(Man)、机(Machine)、料(Material)、法(Method)、环(Environment)、测(Measurement),简称5M1E。
通过头脑风暴,逐层追问“为什么”,直到找到根本原因。
3. 主要步骤
明确问题:确定要分析的质量问题或故障现象。
确定原因类别:选择5M1E等分类框架。
头脑风暴:团队成员提出各种可能原因。
绘制鱼骨图:将原因按类别挂在主骨上,形成鱼刺。
逐层分析:对每个原因继续追问,找出子原因。
确定根本原因:通过投票、数据验证等方法筛选关键原因。
制定改进措施:针对根本原因提出解决方案并跟踪效果。
4. 图形符号
鱼头:问题或结果。
主骨:原因类别(人、机、料、法、环、测)。
鱼刺:具体原因。
子鱼刺:更深层的原因。
5. 输出
原因清单:按类别整理的可能原因。
根本原因:经过筛选和验证的关键原因。
改进措施:针对根本原因的行动计划。
6. 适用场景
质量问题、生产故障、服务投诉等根因分析。
团队协作、头脑风暴、持续改进(如PDCA、六西格玛)。
不要求定量逻辑关系,重在定性梳理。
7. 优缺点
优点:直观、易用,能激发团队思考,覆盖多维度原因。
缺点:定性分析,依赖团队经验;不直接生成测试用例;可能遗漏未知原因。
8. 简单示例
问题:某产品不合格率上升。
鱼骨图分类:人(操作不熟练)、机(设备老化)、料(原料批次差异)、法(工艺参数不当)、环(温湿度波动)、测(检测标准不严)。
逐层分析后,发现根本原因是“原料批次差异”和“工艺参数不当”。
三、详细比较表
| 对比维度 | 测试用例因果分析法(因果图法) | 质量管理中的因果分析法(鱼骨图) |
|---|---|---|
| 领域 | 软件测试 | 质量管理、生产管理 |
| 别名 | 因果图法、Cause-Effect Graphing | 鱼骨图、石川图、因果图 |
| 目的 | 设计测试用例,覆盖输入条件组合 | 分析问题根本原因,制定改进措施 |
| 核心对象 | 输入条件(原因)与输出动作(结果) | 质量问题(结果)与可能原因 |
| 逻辑关系 | 与、或、非、约束(E/I/O/R/M) | 无严格逻辑门,重在分类和层次 |
| 图形结构 | 逻辑图,节点+连线 | 鱼骨形,鱼头+主骨+鱼刺 |
| 是否定量 | 是,基于布尔逻辑,可转换为判定表 | 否,定性分析,依赖团队经验 |
| 主要步骤 | 识别原因结果→分析逻辑→画因果图→转判定表→设计用例 | 明确问题→分类→头脑风暴→画鱼骨图→逐层分析→定根因→改进 |
| 输出 | 判定表、测试用例集 | 原因清单、根本原因、改进措施 |
| 使用阶段 | 测试设计阶段 | 问题发生后的分析阶段、持续改进 |
| 参与人员 | 测试工程师、开发人员 | 质量管理人员、生产人员、跨部门团队 |
| 工具 | 因果图、判定表 | 鱼骨图、头脑风暴、5Why |
| 典型应用 | 输入组合复杂的软件功能测试 | 制造业不合格品分析、服务投诉分析 |
| 优点 | 系统覆盖组合,减少冗余用例 | 直观易用,激发团队思考,多维度覆盖 |
| 缺点 | 复杂需求图庞大,转换工作量大 | 定性分析,不直接生成测试用例,可能遗漏 |
四、易混淆点与注意事项
名称相同,领域不同
在软考中,如果题目说“因果图”,通常指测试用例设计方法;如果提到“鱼骨图”“石川图”,则指质量管理工具。图形不同
测试因果图是逻辑图,有与、或、非门;鱼骨图是树状分类图,没有逻辑门。输出不同
测试因果图输出判定表和测试用例;鱼骨图输出原因清单和改进措施。使用阶段不同
测试因果图用于测试设计;鱼骨图用于问题分析和持续改进。可以结合使用
在实际项目中,可以先用鱼骨图分析问题根因,再用因果图法设计针对性的测试用例验证修复效果。
五、总结
| 对比项 | 测试用例因果分析法 | 质量管理因果分析法 |
|---|---|---|
| 本质 | 逻辑组合测试设计方法 | 定性根因分析工具 |
| 关键词 | 原因、结果、逻辑门、判定表、测试用例 | 问题、原因类别、鱼骨、5M1E、改进措施 |
| 是否生成用例 | 是 | 否 |
| 是否定量 | 是 | 否 |
| 适用场景 | 输入组合复杂的功能测试 | 质量问题、故障根因分析 |
一句话总结:测试中的因果图是“为了设计测试用例而分析输入组合的逻辑工具”;质量管理中的因果图(鱼骨图)是“为了找到问题根因而梳理原因的定性管理工具”。两者同名,但目的、方法、输出完全不同,不能混用。