错误推测是什么
错误推测法凭经验与缺陷历史推测易错点，再针对性设计用例：空值处理、并发、日期边界、最近改动过的模块。它不系统，但能补上等价类与边界值顾不到的地方——那些「看起来不会错、实际经常错」的区域。常见依据包括历史缺陷库、同类项目经验、代码评审中的疑问与线上事故复盘。
基本信息
| 方法类型 | 基于经验的测试设计，与系统化方法组合使用 |
|---|---|
| 输入来源 | 历史缺陷库、同类项目经验、代码评审疑问、线上复盘 |
| 常见产出 | 猜测清单加对应用例，并记录猜测依据 |
| 高发猜测点 | 刚修过的模块、复杂条件判断、复制粘贴代码、第三方集成 |
| 使用时机 | 系统化方法设计完成后查漏补缺，或高风险变更前专项使用 |
典型使用场景
- 测试设计收尾：用猜测清单查漏，重点补异常与恢复路径
- 缺陷高发模块：把历史缺陷归类成可复用的猜测检查项
- 发版前回归：对本次改动邻近区域按经验重点抽查
- 第三方集成联调：支付、短信、地图等依赖的超时与错误码行为
- 热修复验证：线上应急修复后的影响面抽查
- 新人培训：用具体猜测案例传授缺陷模式
猜测清单示例
猜测清单示例
# 错误推测检查项（示例）
- 刚修复过的代码附近：同类判断是否还有别的入口没改
- 复制粘贴的实现：改了 A 处是否漏改 B 处
- 异常分支：是否吞掉错误、是否漏记日志、是否留下脏数据
- 配置缺省：配置项缺失时行为是否可预期
# 每条猜测要写清依据与预期结果，才能变成可执行用例并进入回归常见猜测点与验证动作
| 猜测点 | 验证动作 | 预期 |
|---|---|---|
| 空值与缺省 | 空表单提交、必填字段缺省 | 返回可读错误且不落脏数据 |
| 并发与重复 | 同记录并行修改、按钮双击 | 最终一致且重复请求被幂等处理 |
| 日期与时区 | 月末、闰年、夏令时切换 | 日期归属与定时任务触发正确 |
| 近期改动 | 变更涉及的接口各做一轮邻近回归 | 旧功能未被改坏 |
| 配置与开关 | 默认值缺失、开关组合 | 关闭开关后行为可预期无残留 |
错误推测覆盖不稳定：同一功能换个人结果可能差很多。降低个人依赖的做法是把猜测清单团队化、版本化，并定期把线上缺陷回灌成新的检查项。
与检查表测试的区别：检查表是固定清单逐项过，错误推测是针对当前变更即时推断，两者常搭配——检查表保底，推测法查变化引起的风险。