错误推测法

1. 定义
   基于经验和直觉推测程序中所有可能存在的各种错误，从而有针对性的设计测试用例的方法。

2. 基本思想
   错误猜测主要是一项依赖直觉的非正规的工程方法，其基本思想是列举程序可能出现的错误或者容易产生错误的测试点，然后根据测试点来编写测试用例。另一个思想是，在阅读规格说明时联想开发可能做的假设来确定测试用例，比如规格说明中的可能被忽略的内容。

3.使用方法
错误猜测法并非是一项有章可循的工程设计方法，而是很大程度上依赖于测试人员的经验、能力以及态度。从个人测试经验角度来看，在考虑使用错误猜测法补充测试用例时，可以从如下维度考虑：

A.极限值设计：考虑数值最大、最小、为空、为0等情况。

B.特殊取值设计：

年、月、日情况，必须考虑平年、闰年，2月，每月包含28天、29天、31天等情况。同时考虑跨年、跨月等情况。
模糊查询情况，考虑"."、"%"、"？"等特殊字符取值情况。原因是这些字符在SQL中有它指定的含义。
其他取值，包括NULL、1024、FALSE（0）、TRUE（1）、特殊字符（！@#…）等。
C.特殊组网考虑：测试场景的考虑必须考虑版本使用局点的组网情况，特别是一些特殊的组网，比如网元主备、容灾等。曾经出现过某token使用未考虑同步到备机，导致业务出现故障后切换备机，业务运行失败的问题。

D.端到端用例考虑：通常测试用例都是以特性为维度进行设计，或者测试人员在用例执行时都是分功能进行测试用例设计和执行，并未进行端到端测试用例设计。而端到端的测试用例更容易发现问题。以充值转账功能为例。端到端的用例场景包括：用户开户（用户模型）->用户转账（不同用户层级间，所有的转账接口转账） -> 用户充值（预付费、后付费，所有的充值接口） -> 交易记录查询（所有的查询接口）。当然，如果有必要。这里还需要考虑用户的类型、交易渠道等。

E.性能角度考虑：测试场景补充设计时必须要考虑性能情况，特别是未针对核心特性进行性能场景验证的情况。最经常出现的性能问题是报表查询（功能测试时未考虑交易记录数），包括充值交易记录查询、转账记录查询等涉及大业务量数据的测试。类似的功能包括报表测试或者核心交易逻辑的测试。业务数据量（交易记录数）一定需要与现网数据量保持一致。

F.安全角度考虑：是否考虑不同用户权限功能使用情况、日志中是否有明文显示用户隐私信息、用户登录是否安全校验机制（如密码连续3次输入错误锁账户、验证码）、是否允许越权、前后台校验是否一致等等。

G.可维护性考虑：新开发特性出现问题时，已知日志信息是否可以快速定位问题故障。如果没有，需要增加日志信息。

H.用户体验：提示信息描述是否合理、搜索出现单条记录是否默认选中、交互次数是否太多、界面操作是否简洁、新增菜单风格是否与已知菜单保持一致。

I.功能实现与规格描述是否一致：功能实现是否与规格描述一致。是否存在规格中描述但实际特性缺失或者规格中未描述但存在多于交付特性。无特殊情况，交付功能需与规格内容保持一致。另外一点，产品的某些特性需要在不同模块中同时满足。比如新增某充值功能，需要界面模块和业务模块两种接入方式同时支持。

J.输出域考虑：用例设计需针对输出域情况进行分类考虑。一个是针对输出情况设计输入条件，另外一个是针对输出内容的使用途径进行补充用例设计。比如某特性是针对充值功能的话单记录新增一个字段，也就是话单发生了变化。那么必须要考虑后台对逻辑对话单的处理是否能够成功将新增字段的话单入库到充值历史记录表。

K.隐含功能测试考虑：比如客户要求历史交易功能查询，客户通常仅会要求输入条件和查询方式，并会针对隐含功能如交易记录展示的分页、跳转、单页默认显示行数等内容。但测试设计时必须针对这些隐含功能进行测试。

L.针对不同开发考虑用例设计：这一条情况比较特殊。版本的缺陷会因人而异，同样的特性会由于开发能力、开发态度、开发自验证程度的不同而产生不同的bug。特别注意新员工、自验证随意的开发人员，你会发现有很多"惊喜"。但这些"惊喜"没有在版本发布前发现，就会成为"惊吓"了。