测试设计方法地图

先识别问题

确认你面对的是输入、边界、组合、状态、历史缺陷，还是尚未完全看清的风险。

再选择方法

选择最能暴露这类问题的方法，不需要为了“方法齐全”把每一种都用一遍。

最后检查覆盖

确认关键规则、数据、组合和异常都能映射到可执行用例。

因果图负责理清逻辑

• 与：多个条件必须同时成立。
• 或：满足任意条件即可触发。
• 非：某个条件不成立时触发。
• 互斥：两个条件不能同时出现。
• 依赖：一个条件成立前必须先满足另一个条件。

判定表负责落到用例

• 把原因放在条件行。
• 把结果放在动作行。
• 每一种有效组合形成一列规则。
• 合并结果相同且风险一致的组合。
• 为每列规则生成可执行用例。

适合使用

• 浏览器、设备和系统版本兼容。
• 支付渠道、会员等级和营销配置。
• 权限角色、资源类型和操作动作。
• 参数之间主要是低阶交互。

不能只靠 Pairwise

• 资金、库存等核心组合要单独保留。
• 三个条件共同触发的规则需要 3-wise 或判定表。
• 业务禁止的组合要先加约束。
• 边界、异常和状态问题仍需其他方法。

经验从哪里来

• 同一模块的历史缺陷。
• 线上故障和用户投诉。
• 相似系统的常见问题。
• 代码变更、架构边界和第三方依赖。
• 开发与测试复盘中的薄弱环节。

怎样避免只靠感觉

• 为每个猜测写出风险来源。
• 说明失败后会影响谁和哪些数据。
• 转换成可以重复执行的用例。
• 记录命中率并更新风险清单。
• 不让经验替代基础规则覆盖。

探索任务

验证支付结果不确定时，订单、库存、优惠券和积分能否最终一致。

重点变化

支付中断、重复回调、页面刷新、切换网络和再次提交。

带走证据

时间线、订单号、请求日志、状态快照、发现的问题和后续用例。

属性测试

适合金额公式、排序、转换、幂等和数据约束。重点不是某个固定输入的答案，而是大量合法输入都应满足同一条规则。

模型驱动测试

适合订单、支付、退款等状态系统。先定义允许的状态和动作，再生成不同操作序列，检查系统是否偏离模型。

会员积分抵扣的组合方案

1. 用分类树整理会员、积分、金额、状态和支付结果。
2. 用等价类和边界值选择积分余额、订单金额与抵扣上限。
3. 用因果图和判定表覆盖资格、门槛与状态组合。
4. 用状态模型检查冻结、扣减、释放和退回。
5. 用错误推测补充重复请求、精度和并发风险。
6. 联调阶段用探索性测试发现未知问题。

停止增加用例前检查

• 每条业务规则都有对应验证。
• 核心边界和高风险组合已经覆盖。
• 失败后的数据变化和恢复已经覆盖。
• 历史高频缺陷有回归用例。
• 低风险重复组合已合理缩减。
• 剩余风险已明确记录。

问题已看清

• 输入维度已拆分
• 条件关系已说明
• 状态变化已画出
• 未知风险已记录

方法有依据

• 每种方法对应问题
• 高风险组合单独保留
• 约束与排除项明确
• 没有为了数量套方法

结果可评审

• 用例可以直接执行
• 测试点与用例对应
• 优先级理由明确
• 剩余风险已说明