测试用例设计方法之因果图判定表法

基本概念#

• 因 (Cause)：输入条件、操作、状态（如：输入内容、按钮点击、选项勾选）。
• 果 (Effect)：输出结果、系统状态变化（如：提示信息、页面跳转、数据保存）。
• 核心价值：解决等价类、边界值无法覆盖的多条件组合问题，确保逻辑全覆盖，发现隐藏缺陷。

基本逻辑关系#

1. 恒等（Identity）

   • 因 = 1 → 果 = 1
   • 因 = 0 → 果 = 0

2. 非（Not）

   • 因 = 1 → 果 = 0
   • 因 = 0 → 果 = 1

3. 或（Or）

   • 多个因任意一个为 1 → 果 = 1
   • 全 0 → 果 = 0

4. 与（And）

   • 多个因全部为 1 → 果 = 1
   • 有一个 0 → 果 = 0

约束条件#

约束只限制因之间或果之间，不画逻辑关系。

1. 互斥约束 E（Exclusive）

   • 多个因最多只能有一个为 1
   • 可以全 0，不能同时≥2 个 1

2. 包含约束 I（Inclusive）

   • 多个因至少一个为 1
   • 不能全 0

3. 唯一约束 O（Only）

   • 多个因有且仅有一个为 1
   • 不能全 0，也不能≥2 个 1

4. 要求约束 R（Requires）

   • 若因 A=1，则因 B 必须 = 1
   • A=1，B=0 不合法

5. 屏蔽约束 M（Masking）

   • 只作用在结果之间
   • 若果 E1=1，则果 E2 必须 = 0
   • E1、E2 不能同时为 1

设计步骤#

1. 分析需求，拆分因 / 果

   • 提取所有输入条件（C1, C2, C3…）
   • 提取所有输出 / 结果（E1, E2, E3…）

2. 绘制因果图

   • 用逻辑符号（与 / 或 / 非）连接因 → 果
   • 标注约束（E/I/O/R/M），排除非法组合

3. 转换为判定表（决策表）

   • 行：因（输入）、果（输出）
   • 列：所有有效条件组合
   • 单元格：0/1 表示

4. 简化判定表（可选）

   • 合并相似列、剔除无效列

5. 生成测试用例

   • 每一列 → 一条用例（输入 + 预期输出）

案例#

经典案例：自动售货机

需求： - 饮料单价 1.5 元 - 投入 1.5 元 → 按按钮 → 出饮料 - 投入 2 元 → 按按钮 → 出饮料 + 找零 0.5 元

1. 拆分因 / 果

因 (C)：

• C1：投入 1.5 元
• C2：投入 2 元
• C3：按 “可乐”
• C4：按 “雪碧”

果 (E)：

• E1：出可乐
• E2：出雪碧
• E3：找零 0.5 元
• E4：无任何出货 / 提示（金额不足 / 操作无效）

2. 约束

• E（互斥）：C1 与 C2 不能同时为 1
• E（互斥）：C3 与 C4 不能同时为 1
• 不投币、只按键：无效操作

3. 判定表

总原始组合 16 种，过滤非法后保留有效场景：

1 = 满足，0 = 不满足；已删掉 C1=1 且 C2=1、C3=1 且 C4=1 这类矛盾行，实际业务不可能出现。

4. 简化判定表（可选）

剔除无效场景，仅保留6条核心有效用例：

数学基础与规则计算#

判定表的完备性，核心来自对条件组合的全量枚举：

• 若 n 个条件均为布尔型（2 个取值：是 / 否），则总规则数 = 2ⁿ
• 若条件有多个枚举值（如会员等级分普通 / 银卡 / 金卡），则总规则数 = 每个条件的取值数的乘积（m₁×m₂×…×mₙ）

示例：3 个布尔型条件，总规则数 = 2³=8 条，可覆盖所有条件组合。

设计步骤（附实战案例）#

1. 分析需求，确定条件桩与动作桩

   业务需求：

   • 登录需校验 3 项内容：用户名、密码、图形验证码
   • 仅当用户名正确、密码正确、验证码匹配时，登录成功
   • 用户名错误，直接提示「用户名不存在」，无需校验后续项
   • 用户名正确、密码错误，提示「密码错误」
   • 用户名和密码正确、验证码错误，提示「验证码错误」

拆解业务规则，拆分独立的输入条件和所有可能的输出动作，严禁一个条件桩包含多个判断，避免逻辑遗漏。

• 条件桩：C1. 用户名正确；C2. 密码正确；C3. 验证码匹配（均为布尔型：Y/N）
• 动作桩：A1. 登录成功；A2. 提示用户名不存在；A3. 提示密码错误；A4. 提示验证码错误

2. 计算规则总数，确定表格规模

根据条件桩的数量和每个条件的取值数，计算理论最大规则数，搭建表格框架。

• 3 个布尔条件，总规则数 = 2³= 8 条

3. 填充全量条件项组合

按二进制枚举的方式，逐列填充所有条件的取值组合，确保无遗漏、无重复。

4. 匹配业务规则，填充动作项

对照需求文档，为每一组条件项组合，明确对应的动作结果，完成初始判定表。

5. 简化合并等价规则

合并核心原则：多条规则中，只有一个条件取值不同，其余条件完全一致，且触发的动作完全相同，可合并为一条规则，该不同条件用 - 标记为「无关项 / 不影响结果」。

• 严禁为减少规则数强行合并动作不同、或条件存在业务关联的规则，避免覆盖遗漏。

• 规则 5-8：仅 C1=N，其余条件无论取值如何，动作均为 A2，可合并。
• 规则 3-4：C1=Y、C2=N，C3 取值不影响动作，可合并。

最终简化表：

6. 基于规则生成测试用例

将简化后的每一条规则，转换为一条可执行的测试用例，明确测试输入、执行步骤与预期结果。

场景#

适用场景：

• 多条件联动、多分支逻辑判断的业务（如登录、权限校验、表单校验、营销规则、金融风控）
• 业务规则有明确的「条件 - 结果」对应关系，需求对逻辑分支有清晰定义
• 需要确保测试覆盖无遗漏，避免边界逻辑漏洞的核心功能
• 跨角色需求 / 用例评审，需要可视化呈现所有业务规则，对齐认知

不适用场景：

• 条件桩数量过多（如超过 10 个布尔条件，规则数超 1024 条），出现规则爆炸，维护成本极高
• 业务逻辑以循环、时序流程、状态流转为主，而非条件判断分支
• 输入条件的取值无法明确枚举，边界模糊的场景
• 条件之间无逻辑关联、相互独立的简单场景

优缺点#

优点：

• 逻辑严谨，覆盖完备：枚举所有条件组合，从根本上避免遗漏业务规则和测试分支，是黑盒方法中逻辑完整性最强的方法之一
• 可视化强，便于对齐：表格形式清晰呈现所有「条件 - 动作」规则，便于测试人员梳理需求，也能快速发现需求中的逻辑漏洞
• 可维护性强：需求变更时，只需调整对应条件桩、动作桩和规则，无需重构整体用例框架
• 用例设计高效：一条规则对应一条用例，避免重复设计，且能精准定位缺陷对应的业务规则

缺点：

• 规则数指数级增长：条件数量增加时，规则数呈指数级爆炸，维护成本急剧上升
• 需求梳理要求高：若条件桩、动作桩拆分错误，会导致整个判定表失效，需要测试人员对业务规则有深度理解
• 场景适配有限：无法很好地处理循环、顺序执行、状态流转类的业务场景，需配合状态迁移图等方法使用

使用技巧与避坑#

1. 条件桩拆分原则：每个条件桩仅对应一个布尔判断，避免一个条件桩包含多个判断（如不要把「用户名和密码正确」做成一个条件桩），否则会出现逻辑遗漏
2. 合并规则的边界：合并仅适用于不影响动作结果的无关项，严禁强行合并动作不同的规则，避免覆盖遗漏
3. 多取值条件处理：若一个条件有多个枚举值（如会员等级），按实际取值数计算规则数，不要强行转为布尔值，避免逻辑失真
4. 大规模条件优化：当条件数过多时，可配合正交试验法减少规则数，或按业务模块拆分多个子判定表，分别处理
5. 与其他方法配合：等价类划分确定条件的取值范围，边界值确定临界输入，判定表覆盖组合场景，三者配合使用可实现最高效的测试覆盖

推断依据#

错误推断法不是无依据的随机测试，所有用例设计均需基于可沉淀的经验依据，核心来源如下：

1. 项目历史缺陷库：过往版本、同类型功能反复出现的高频 bug（如表单重复提交、接口超时无兜底、大数据量分页崩溃），是最高优先级的推断依据。
2. 行业通用易错场景：全行业软件的共性缺陷点，包括空值 / Null / 特殊字符输入、数值边界溢出、权限越权操作、并发场景数据不一致、弱网 / 断网异常、浏览器 / 设备兼容性问题、敏感信息泄露等。
3. 业务核心风险点：产品核心流程的高风险分支，如支付退款、库存扣减、用户账号注销、数据备份与恢复、合规校验等场景。
4. 研发团队特性：开发人员的编码习惯（如部分开发易忽略异常处理、边界校验）、重构 / 迭代频繁的模块、历史债务重的老系统、第三方依赖接口等。
5. 合规与安全通用漏洞：如 SQL 注入、XSS 跨站脚本、CSRF 跨站请求伪造、未授权访问等常见安全风险。

实施步骤#

1. 沉淀与维护错误知识库：搭建团队级缺陷台账，分类归档历史 bug、行业通用错误、业务风险点，形成可复用的错误推断清单。
2. 拆解模块与风险预判：针对待测功能模块，结合错误知识库，梳理该模块可能出现的所有错误类型、触发场景与诱因。
3. 针对性设计测试用例：为每一个预判的错误点设计专属用例，明确前置条件、操作步骤、输入数据、预期结果，重点覆盖异常分支与极端场景。
4. 执行测试与闭环迭代：执行用例验证缺陷，同时将本次新发现的 bug 补充至错误知识库，持续优化推断清单，形成经验闭环。

典型示例#

针对用户登录模块，通过错误推断法可快速设计以下高优先级测试用例：

1. 账号 / 密码输入空值、超长字符串、特殊字符、SQL 注入语句，校验是否有合规拦截与异常兜底
2. 连续多次输错密码，校验账号锁定机制是否生效，是否存在锁定绕过漏洞
3. 弱网 / 断网环境下提交登录请求，网络恢复后是否出现重复提交、多 token 生成问题
4. 登录成功后点击浏览器回退按钮，是否可重复登录、是否能未授权访问受限页面
5. 第三方登录授权失败 / 取消授权时，是否出现页面白屏、流程卡死无兜底的问题
6. 记住密码功能在无痕模式、多浏览器切换场景下，是否存在账号信息泄露风险

优缺点#

注意事项#

1. 严禁单独使用：高风险核心模块（支付、交易、用户数据等），必须以等价类划分、边界值分析、场景法等标准化方法为核心，错误推断法仅用于补充测试。
2. 降低个人依赖：必须搭建团队共享的缺陷知识库与错误推断清单，将个人经验转化为组织资产，避免人员流动导致测试能力断层。
3. 持续迭代优化：每次版本迭代、上线复盘后，必须将新发现的缺陷补充至知识库，持续更新高频风险点，提升推断精准度。
4. 区分随机测试：错误推断法是目标明确的针对性测试，而非无目的的随机点击、随意测试，所有用例必须有明确的风险预判依据。

场景#

正交实验法是多因素组合场景的最优解，尤其适合以下情况：

• 多输入参数、多条件联动的功能测试（如复杂表单提交、接口多参数校验、系统配置项联动测试）；

• 全量组合数量过大，无法实现穷举测试的场景（例如4因素3水平，全量组合有81个，正交法仅需9个用例即可覆盖核心场景）；

• 兼容性测试（浏览器、操作系统、分辨率、设备型号等多维度组合场景）；

• 性能测试的参数调优、接口压力测试的多变量组合场景；

• 回归测试的用例精简，在有限时间内完成核心场景覆盖，提升回归效率。

正交实验法并非万能，以下场景不建议使用：

• 单因素单水平的简单功能校验（如单一按钮点击、单个输入框校验），无需复杂组合；

• 因素间存在强互斥、强依赖关系，且无法通过人工调整规避无效组合的场景（如“支付方式=现金”与“支付渠道=线上支付”无法同时出现，会导致大量无效用例）；

• 连续型变量无法离散化的场景（如温度、压力等连续值，无法拆分为明确的水平，需先进行离散化处理）。

设计步骤#

正交实验法的用例设计流程固定，核心分为6步，结合实战案例可快速掌握：

1. 明确测试目标，提取核心因素：分析需求规格说明书，梳理所有影响被测功能输出的输入条件/参数，优先筛选对功能影响大、风险高的核心因素，剔除弱影响、无关因素（避免因素过多导致用例数冗余）。

2. 确定每个因素的水平：为每个核心因素设定有业务代表性的水平，结合等价类、边界值法，覆盖有效、无效、边界场景；尽量让各因素的水平数保持一致，简化正交表的选择（水平数不一致可选用混合水平正交表）。

3. 选择适配的正交表：选表核心原则：① 正交表的列数 $k$ ≥实际因素数；② 正交表的水平数 $m$ =实际因素的水平数；③ 在满足前两个条件的正交表中，选择行数 $n$ 最小的表（用例数最少，效率最高）。

4. 因素水平映射到正交表：将确定的因素一一对应到正交表的列，每个因素的水平按顺序替换正交表中的数字（如因素A的3个水平，替换正交表中“1、2、3”三个数字）。

5. 生成基础测试用例：正交表的每一行，对应一个可执行的测试用例，补充用例的前置条件、操作步骤、预期结果，形成完整的基础用例集。

6. 补充优化用例：正交表生成的是核心覆盖用例，无法覆盖所有极端场景、全异常组合，需人工补充强业务相关、极端边界、全异常的特殊用例，降低漏测风险。

实战案例（电商订单查询功能）#

被测功能：电商后台订单查询功能，用户可通过“订单状态”“时间范围”“排序方式”三个条件组合查询订单，需设计高效的测试用例覆盖核心场景。

常用正交表参考#

实际测试中，无需手动绘制正交表，可直接选用预制的标准化正交表，以下是常用正交表分类及参数：

优缺点分析#

使用关键注意事项#

• 因素筛选优先级：优先选择对功能影响大、风险高的核心因素，剔除无影响、弱影响的次要因素，控制因素数量（建议不超过5个，否则用例数会显著增加）；

• 水平选取原则：每个水平必须有业务代表性，覆盖有效等价类、无效等价类、边界值，避免重复、无意义的取值（如用户名“正确”与“合法”属于重复水平，需合并）；

• 互斥/依赖因素处理：若因素间存在互斥、依赖关系，需人工删除正交表中的无效用例，补充符合业务逻辑的有效组合，避免无效测试；

• 不可替代基础方法：正交法是组合场景的优化方法，不能替代等价类、边界值、错误推测法，需结合多种用例设计方法使用，才能保障测试完整性；

• 工具辅助提效：复杂场景（多因素、混合水平）可借助正交表生成工具（如正交设计助手、SPSS、Minitab）自动生成正交表，避免人工制表出错，提升设计效率。