黑盒测试用例设计-错误推测法

一 定义

   错误推测法是指：在测试程序时，人们可以根据经验或直觉推测程序中可能存在的各种错误，从而有针对性地编写检查这些错误的测试用例的方法。

二 基本思想

   错误猜测主要是一项依赖直觉的非正规的工程方法，其基本思想是列举程序可能出现的错误或者容易产生错误的测试点，然后根据测试点来编写测试用例。

   另一个思想是，在阅读规格说明时联想开发可能做的假设来确定测试用例，比如规格说明中的可能被忽略的内容。

三 使用方法

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



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



   B.特殊取值设计：

年、月、日情况，必须考虑平年、闰年，2月，每月包含28天、29天、31天等情况。同时考虑跨年、跨月等情况。
模糊查询情况，考虑"."、"%"、"？"等特殊字符取值情况。原因是这些字符在SQL中有它指定的含义。
其他取值，包括NULL、1024、FALSE（0）、TRUE（1）、特殊字符（！@#…）等。

    C.端到端用例考虑：通常测试用例都是以特性为维度进行设计，或者测试人员在用例执行时都是分功能进行测试用例设计和执行，并未进行端到端测试用例设计。而端到端的测试用例更容易发现问题。以充值转账功能为例。端到端的用例场景包括：用户开户（用户模型）->用户转账（不同用户层级间，所有的转账接口转账） -> 用户充值（预付费、后付费，所有的充值接口） -> 交易记录查询（所有的查询接口）。当然，如果有必要。这里还需要考虑用户的类型、交易渠道等。
    E.性能角度考虑：测试场景补充设计时必须要考虑性能情况，特别是未针对核心特性进行性能场景验证的情况。最经常出现的性能问题是报表查询（功能测试时未考虑交易记录数），包括充值交易记录查询、转账记录查询等涉及大业务量数据的测试。类似的功能包括报表测试或者核心交易逻辑的测试。业务数据量（交易记录数）一定需要与现网数据量保持一致。
    F.安全角度考虑：是否考虑不同用户权限功能使用情况、日志中是否有明文显示用户隐私信息、用户登录是否安全校验机制（如密码连续3次输入错误锁账户、验证码）、是否允许越权、前后台校验是否一致等等。
    G.可维护性考虑：新开发特性出现问题时，已知日志信息是否可以快速定位问题故障。如果没有，需要增加日志信息。
    H.用户体验：提示信息描述是否合理、搜索出现单条记录是否默认选中、交互次数是否太多、界面操作是否简洁、新增菜单风格是否与已知菜单保持一致。
    I.功能实现与规格描述是否一致：功能实现是否与规格描述一致。是否存在规格中描述但实际特性缺失或者规格中未描述但存在多于交付特性。无特殊情况，交付功能需与规格内容保持一致。另外一点，产品的某些特性需要在不同模块中同时满足。比如新增某充值功能，需要界面模块和业务模块两种接入方式同时支持。
    J.输出域考虑：用例设计需针对输出域情况进行分类考虑。一个是针对输出情况设计输入条件，另外一个是针对输出内容的使用途径进行补充用例设计。比如某特性是针对充值功能的话单记录新增一个字段，也就是话单发生了变化。那么必须要考虑后台对逻辑对话单的处理是否能够成功将新增字段的话单入库到充值历史记录表。
    K.隐含功能测试考虑：比如客户要求历史交易功能查询，客户通常仅会要求输入条件和查询方式，并会针对隐含功能如交易记录展示的分页、跳转、单页默认显示行数等内容。但测试设计时必须针对这些隐含功能进行测试。
    L.针对不同开发考虑用例设计：这一条情况比较特殊。版本的缺陷会因人而异，同样的特性会由于开发能力、开发态度、开发自验证程度的不同而产生不同的bug。特别注意新员工、自验证随意的开发人员，你会发现有很多"惊喜"。但这些"惊喜"没有在版本发布前发现，就会成为"惊吓"了。

四 技巧

    最重要的是要思考和分析测试对象的各个方面，多参考以前发现的bug的相关数据和总结的经验，个人多考虑异常的情况、反面的情况、特殊的输入，以一个攻击者的态度对待程序，就能设计出比较完善的测试用例来。

五 优缺点

   优点：

充分发挥人的直觉和经验
集思广益
方便使用
快速切入
缺点：

难以知道测试的覆盖率
可能丢失大量未知的区域
带有主观性且难以复制
只能作为测试设计的补充，不能单独用来设计测试用例

六 使用场景及总结

     使用场景： 先用其他方法设计测试用例，再使用错误猜测法补充用例。

    总结：错误猜测法的使用在不同的测试人员手里威力大小会有很大的区别，有经验、有态度的测试人员利用错误猜测法可以发现很多常规工程方法难以发现的问题。而经验不足或者能力不足的测试人员是很难利用好这一方法。同时，要注意的是，使用错误猜测法有点类似"探索测试"，是需要一定的测试时间来实施的。因此，测试管理者平衡好错误猜测法和测试周期的关系，尽量在最合理的时间来确保问题的发现。同时，在版本管理过程中，建立好版本常见或典型测试问题集，定期推广，快速提升测试人员发现问题的经验和能力。

七 举例

    实例：测试某个课程搜索输入框

既然是用错误猜测法，那么我们首先列出可能导致搜索结果出错的情况，如下：
单个空格，多个空格
字符串前面有空格
字符串后面有空格
转义符 “\n”
Null
特殊字符
通配符 *
空串，很长的字符串