基于经验和直觉推测程序中所有可能存在的各种错误, 从而有针对性的设计测试用例的方法。
基本思想
错误猜测主要是一项依赖直觉的非正规的工程方法。其基本思想是列举程序可能出现的错误或者容易产生错误的测试点，然后根据测试点来编写测试用例。另一个思想是，在阅读规格说明时联想开发可能做的假设来确定测试用例，比如规格说明中的可能容易被忽略的内容。
使用方法
个人理解错误猜测法并非是一项有章可循的工程设计方法，而是很大程度上依赖于测试人员的经验、能力以及态度。从个人测试经验角度来看，在考虑使用错误猜测法补充测试用例时，可以从如下维度考虑：
（1）极限值设计。
考虑数值最大、最小、为空、为0等情况。
（2）特殊取值设计。
a. 年、月、日情况，必须考虑平年、闰年，2月，每月包含28天、29天、31天等情况。同时考虑跨年、跨月等情况。
b.模糊查询情况，考虑"."、"%"、"？"等特殊字符取值情况。原因是这些字符在SQL中有它指定的含义。
c.其他取值，包括NULL、1024、FALSE（0）、TRUE（1）、特殊字符（！@#...）等。
（3）特殊组网考虑。
测试场景的考虑必须考虑版本使用局点的组网情况，特别是一些特殊的组网，比如网元主备、容灾等。曾经出现过某token使用未考虑同步到备机，导致业务出现故障后切换备机，业务运行失败的问题。
（4）端到端用例考虑。
通常测试用例用例都是以特性为维度进行设计，或者测试人员在用例执行时都是分功能进行测试用例设计和执行，并未进行端到端测试用例设计。而端到端的测试用例更容易发现问题。如新割接局点，以充值转账功能为例。端到端的用例场景包括：用户开户（用户模型）->用户转账（不同用户层级间，所有的转账接口转账） -> 用户充值（预付费、后付费，所有的充值接口） -> 交易记录查询（所有的查询接口）。当然，如果有必要。这里还需要考虑用户的类型、交易渠道等。
（5）性能角度考虑。
测试场景补充设计时必须要考虑性能情况，特别是未针对核心特性进行性能场景验证的情况。最经常出现的性能问题是报表查询（功能测试时未考虑交易记录数），包括充值交易记录查询、转账记录查询等涉及大业务量数据的测试。类似的功能包括报表测试或者核心交易逻辑的测试。业务数据量（交易记录数）一定需要与现网数据量保持一致。假设充值报表查询，现网充值为100CAPS，交易数据保存的3个月。那么表数据量需要设置100*60*60*24*30*3。
（6）安全角度考虑。
是否考虑不同用户权限功能使用情况、日志中是否有明文显示用户隐私信息、用户登录是否安全校验机制（如密码连续3次输入错误锁账户、验证码）、是否允许越权、前后台校验是否一致等等。
（7）可维护性考虑。
新开发特性出现问题时，已知日志信息是否可以快速定位问题故障。如果没有，需要增加日志信息。
（8）用户体验。
提示信息描述是否合理、搜索出现单条记录是否默认选中、交互次数是否太多、界面操作是否简洁、新增菜单风格是否与已知菜单保持一致。
（9）功能实现与规格描述是否一致。
功能实现是否与规格猫叔一致。是否存在规格中描述但实际特性缺失或者规格中未描述但存在多于交付特性。无特殊情况，交付功能需与规格内容保持一致。另外一点，产品的某些特性需要在不同模块中同时满足。比如新增某充值功能，需要界面模块和业务模块两种接入方式同时支持。
（10）输出域考虑。
用例设计需针对输出域情况进行分类考虑。一个是针对输出情况设计输入条件，另外一个是针对输出内容的使用途径进行补充用例设计。比如某特性是针对充值功能的话单记录新增一个字段，也就是话单发生了变化。那么必须要考虑后台处理逻辑对话单的处理是否能够成功将新增字段的话单入库到充值历史记录表。
（11）隐含功能测试考虑。
比如客户要求历史交易功能查询，客户通常仅会要求输入条件和查询方式，并会针对隐含功能如交易记录展示的分页、跳转、单页默认显示行数等内容。但测试设计时必须针对这些隐含功能进行测试。
（12）针对不同开发考虑用例设计。
这一条情况比较特殊。版本的缺陷会因人而异，同样的特性会由于开发能力、开发态度、开发自验证程度的不同而产生不同的bug。特别注意新员工、自验证随意的开发人员，你会发现有很多"惊喜"。但这些"惊喜"没有在版本发布前发现，就会成为"惊吓"了。
举例说明
案例1：:对线性表（比如数组）排序的程序进行测试，可推测列出以下几项需要特别测试的情况：
（1）输入的线性表为空表；
（2）表中只含有一个元素；
（3）输入表中所有元素已排好序；
（4）输入表已按逆序排好；
（5）输入表中部分或全部元素相同。
案例2：测试手机终端的通话功能，可以设计各种通话失败的情况来补充测试用例：
（1）无SIM 卡插入时进行呼出（非紧急呼叫）
（2）插入已欠费SIM卡进行呼出
（3）射频器件损坏或无信号区域插入有效SIM卡呼出
（4）网络正常，插入有效SIM卡，呼出无效号码（如1、888、333333、不输入任何号码等）
（5）网络正常，插入有效SIM卡，使用“快速拨号”功能呼出设置无效号码的数字
总结
错误猜测法的使用在不同的测试人员手里威力大小会有很大的区别，有经验、有态度的测试人员利用错误猜测法可以发现很多常规工程方法难以发现的问题。对于经验不足或者能力不足的测试人员是很难利用好这一方法。同时，要注意的是，使用错误猜测发有点类似"探索测试"，是需要一定的测试时间来实施的。因此，测试管理者平衡好错误猜测测试法和测试周期的关系，尽量在最合理的时间来确保问题的发现。同时，在版本管理过程中，建立好版本常见或典型测试问题集，定期推广，快速提升测试人员发现问题的经验和能力。
参考资料
《黑盒测试用例设计方法》