# 1. 因果图(Cause-Effect Graph)中如何处理'与(AND)'、'或(OR)'、'非(NOT)'等逻辑约束？请以'订单提交'场景为例绘制因果图并转换为判定表。 A 结果与原因无关 B 任一原因成立结果即成立 C 多个原因同时成立结果才成立 ✓ 正确答案 D 对原因取反
# 2. Decision Table 在条件-动作矩阵的完全展开 vs collapse 的工程取舍？ A 先完全展开确保覆盖，再折叠相同动作列以精简 ✓ 正确答案 B 只做完全展开，绝不折叠 C 只做折叠，不管覆盖 D 两者都无法保证正确性
# 3. Decision Table 的 limited-entry vs extended-entry 的工程差异？ A 真（T）/假（F）/任意（—） ✓ 正确答案 B 具体数值或范围 C 任意字符串 D 时间戳格式
# 4. Cause-Effect Graph 的基本符号（identity、not、and、or、xor、nand）与决策表的工程协同？ A 两者完全无关 B 因果图负责逻辑建模与缺陷发现，决策表负责结构化落地与用例生成 ✓ 正确答案 C 决策表用于画图，因果图用于生成用例 D 两者互相替代
# 5. 判定表的组成与化简，条件桩/动作桩/条件项/动作项的规则，如何通过合并相同动作的列来化简规则数？ A 两列动作相同，且仅一个条件项不同、其余条件项相同 ✓ 正确答案 B 两列条件项完全相同 C 任意两列都可合并 D 两列动作不同
# 6. 判定表(Decision Table)的简化与折叠规则，如何通过约束(Impossible/Any)减少规则数量？ A 无条件减少所有规则 B 剔除业务上不可能发生的条件组合 ✓ 正确答案 C 把条件项全部设为任意 D 删除条件桩
# 7. Cause-Effect Graph 的 Boolean constraint（Mask、Unique cause）的工程边界？ A 时序依赖与状态保持 ✓ 正确答案 B 同一时刻原因之间的静态限制 C 原因与结果之间的逻辑门 D 不成立的组合剔除
# 8. 因果图转判定表，如何从需求梳理输入间的约束关系（互斥/包含/唯一/要求），再转换为判定表生成用例？ A 一个条件成立要求另一个也成立 B 两个条件必须同时成立 C 恰好一个条件成立 D 两个条件不能同时成立 ✓ 正确答案
# 9. 判定表与等价类/边界值的结合，什么场景下判定表比逐项等价类更高效（多条件组合），如何避免规则爆炸？ A 判定表用例更少 B 判定表不需要条件桩 C 等价类无法覆盖单字段 D 判定表能覆盖多条件之间的组合规则 ✓ 正确答案
# 10. 判定表在复杂业务规则（保险核保、优惠计算、审批流）中的落地案例，条件桩如何从业务规则中提取并控制规则数？ A 条件桩数量与规则数无关 B 只保留对决策结果有区分力的条件 ✓ 正确答案 C 条件桩越少越好，不考虑业务 D 把所有字段都作为条件桩
# 11. 因果图与判定表的适用边界，什么场景直接使用判定表即可，什么场景必须借助因果图梳理输入依赖？ A 条件间存在隐藏依赖/约束、逻辑复杂 ✓ 正确答案 B 任何场景都必须用因果图 C 条件独立且逻辑清晰 D 只有单条件场景
# 13. 判定表用于需求评审，如何用判定表发现需求中的矛盾规则、遗漏条件与不可达组合？ A 条件组合没有定义动作 B 同一条件组合被规定为不同动作 ✓ 正确答案 C 条件组合逻辑上不可能 D 条件桩数量过多
# 15. 正交实验法在条件组合中的运用，为什么条件多到判定表规则爆炸时改用正交表，如何确定因子与水平？ A 减少因子数量 B 覆盖所有全组合 C 完全避免组合测试 D 用少量代表性组合覆盖两两交互，控制用例规模 ✓ 正确答案
# 17. 判定表的自动化表达，如何把判定表规则参数化为数据驱动用例（CSV/JSON），并随规则变更同步维护？ A 每次规则变更都重写测试代码 B 判定表作为单一数据源，规则变更时同步数据文件 ✓ 正确答案 C 规则与用例无需同步 D 只用 CSV 不用 JSON
# 19. 判定表化简后的等价性验证，合并规则后如何确保不改变原始逻辑，如何用真值表校验？ A 只对比动作桩数量 B 只对比条件桩数量 C 无需验证 D 用真值表逐一比对化简前后所有条件组合的动作 ✓ 正确答案
