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。特别注意新员工、自验证随意的开发人员，你会发现有很多"惊喜"。但这些"惊喜"没有在版本发布前发现，就会成为"惊吓"了。

​

 很多软件测试从业者用到的黑盒测试用例设计方法大多是等价类划分法、边界值分析法、判定表法、因果图法和正交试验法等，其实还有一种方法不得不提到，那就是错误猜测法，这对资深测试人员尤为重要。

因为随着在产品测试的实践中对产品的了解和测试经验的丰富，使用错误猜测法设计的测试用例往往非常有效，可以作为测试设计的一种补充手段。

并且积累的经验越丰富，方法使用效率越高。那么到底什么是错误猜测法呢，下面我们将通过定义和实际测试案例来加深对错误猜测法的认识。

首先，我们先来看看错误猜测法的定义：有经验的测试人员往往可以根据自己的工作经验和直觉推测出程序可能存在的错误，从而有针对性的进行测试。它的要素共有三点，分别为：经验、知识、直觉。

基本思想：列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例。

​

 
 01 

例如,输入数据和输出数据为0的情况；输入表格为空格或输入表格只有一行。这些都是容易发生错误的情况。可选择这些情况下的例子作为测试用例。 

02      

例如，前面例子中成绩报告的程序，采用错误推测法还可补充设计一些测试用例：

      1)     程序是否把空格作为回答

      2)     在回答记录中混有标准答案记录

      3)     除了标题记录外，还有一些的记录最后一个字符即不是2也不是3

      4)     有两个学生的学号相同

      5)     试题数是负数  

03      

例如，测试一个对线性表（比如数组）进行排序的程序，可推测列出以下几项需要特别测试的情况：

          输入的线性表为空表；
           表中只含有一个元素；
          输入表中所有元素已排好序；
          输入表已按逆序排好；
          输入表中部分或全部元素相同。  
04 
例如，测试手机终端的通话功能，可以设计各种通话失败的情况来补充测试用例：
           1)    无SIM 卡插入时进行呼出（非紧急呼叫）
           2)    插入已欠费SIM卡进行呼出
           3)    射频器件损坏或无信号区域插入有效SIM卡呼出
           4)    网络正常，插入有效SIM卡，呼出无效号码（如1、888、333333、不输入任何号码等）
          5)    网络正常，插入有效SIM卡，使用“快速拨号”功能呼出设置无效号码的数字

​

一、前言

  前些章节提到了程序测试很常用的黑盒测试方法，尤其是判定表和因果图法尤其重要，是需要重点学习和复习的，没看过的小伙伴可以随时查阅前置文章进行查看~，至此感谢大家这些时间的支持与鼓励 ~ ，话不多说开始今天的内容
（重要的不得了！！！）

二、错误推测法的魅力

  错误推测法发现的Bug

  笔者个人游戏时间通过错误推测法进行的尝试从而发现的Bug，每个游戏均有很多类似的问题，以下仅用游戏“腐烂国度2”进行展示：

  1、战斗时背包装备icon缺失

  2、产生的一个异常道具配件

  3、战斗过程中枪支模型消失

问题过多，不逐一列举，上述的问题均有错误推测法所发现的~，看到了错误推测法的魅力了嘛？[手动滑稽]

  

三、错误推测法简介

  
3.1 什么是错误推测法？

  在日常测试游戏/软件时，测试人员可以根据自身的测试经验对游戏/软件的熟悉程度以及个人的直觉推测程序中可能存在的各种错误，从而有针对性地检查、编写测试用例。

  
  错误推测法所依据的四大要素：

  （1）游戏/软件的熟悉程度

  （2）行业的测试经验累积

  （3）测试中方法的知识运用

  （4）个人直觉

  
3.2 错误推测法基本思想

  （1）列举出程序中可能出现的错误和容易发生错误的特殊情况

  （2）根据列举出的各类情况，取出部分做为测试用例

  
3.3 错误推测法优缺点

优点：

  （1）能够充分的发挥直觉与思维

  （2）毫无局限性，可以随时使用

  （3）随着经验与认知，不断提升错误推测法的使用，逐渐扩大收益，产生无限可能

  （4）在各类开发流程（V模型、敏捷开发等）情况下均可快速进行切入使用，无需有额外顾虑，适用性强

缺点：

  （1）推测有无限大的局限性，但思维有限，难以达到高覆盖率

  （2）存在不确定性，最坏的结果可能通过推测法一个缺陷都无法发现，存在很多未知

  （3）他人学习成本非常高，带有个人的主观性、经历以及经验，难以复用

  
3.4 错误推测法的使用方式

  （1）先行通过其他测试用例设计方法对用例进行设计

  （2）设计完成后使用错误推测法进行推测列举程序中可能出现的错误

  （3）列举后针对自身对项目的理解、对程序的理解，对所有列举结果进行筛选，最终进行用例补充

  
3.5 常见的程序错误
  

  （1）空格不会当做判断回应
  
  举例：某游戏的交易系统要求输入道具购买数量，输入文本框中如果输入的数据为空并点击交易按钮会提示您的输入数据为空，无法成功交易，当你输入一个空格在文本输入框中并再次点击交易按钮，此时仍然提示你输入数据为空

  这就是典型的空格不会判断回应，正常的表现是当玩家输入空格后，返回的结果应该是输入错误请重新输入或其他友好提示，而并非输入为空，在对输入的特别异常判断上主要是两种，一种为不输入，即输入为空，另外一种为输入空数据，即空格、制表键Tab等。

  差别也显而易见了，一个是没输入数据，另一个则是输入了，只不过输入了个空数据而已。在接口测试中也会经常出现类似的情况，换句话说一个是不传参，一个是传空参(传空格等)
  

  （2）按钮快速点击所导致的各类异常

  举例：某游戏的交易系统供角色皮肤购买，快速点击购买按钮

  在我们进行一些道具购买时玩家很可能会进行连续性且快速的点击动作，尤其是点击带有客户端请求、以及服务器处理下发相关的按钮，快速的点击事件会导致服务器与客户端在短时间内处理大量的请求与下发数据，当未生效这类防护逻辑时(例如禁止连续点击一个按钮多次)，很可能会导致数据产生异常或引发其他错误

  相对于一些金钱计算非常严格的软件，例如平常购物的某宝、某东，某多多，在快速点击事件的处理上就会非常仔细，例如双11的购物上，他们无法允许这种错误的产生，因为一旦产生就是致命的，故此服务器与客户端对于这一类的事件处理就会非常的精确，但部分游戏/软件在开发时可能会忽略掉这一点，因而快速点击按钮的事件行为非常容易引起异常问题的出现（不仅仅是数据上的问题，可能导致的有UI错乱、按钮无响应，或者连带的其他集成模块受到牵连）
  

  （3）带有两个或多个的关系事件或互斥事件

笔者这里用6月25日上线的梦幻新诛仙游戏进行举例

  举例：玩家身为队员，队长此时进行了组队副本的匹配，将在3秒后进行组队副本的进入，玩家在2.5秒的时候点击了世界地图并进行了地图跳转，此时还处于loading中，队长点击副本的进入按钮。

  
  试想一下，错误的点在哪里？没错，就是两个明显的互斥关系，即：我在loading时就一定无法进入副本，我进入了副本就无法处于跳转的loading中，如果我身为队员的情况，让队长进行操作，我先行跳转了在loading过程中，队长又强制进入了副本，那么我到底是进入副本还是不进入副本，亦或者发生致命错误？…

  

  看到这里，大家应该对错误推测法有一定的理解了，错误推测法顾名思义就是进行错误的推测，好比例3，进入副本还是不进入副本的问题，当你有场景符合这类的条件，就可以使用错误推测法进行列举，并选取条件进行用例设计
  

四、知识小课堂

  
   问题一：如文章所示，错误推测法的学习成本高，更多是依据个人的游戏/软件熟悉程度，经历或是直觉去判断的，是否有学习的捷径或快速的方式？
  

   答：我们可以通过Bug列表去了解，负责项目中会存在很多Bug，这些Bug通常会提交到缺陷管理平台形成Buglist，可以通过Buglist出发，去学习了解，看看出现过的Bug，有哪一些很新奇、很独特，甚至未听说过的Bug，慢慢的变得更加熟悉，更加了解。
  

  当你知道曾经的项目出现过这一类或某一个问题的时候，在下一次负责有同样特性、特征的模块/系统/玩法时自然而然就可以使用错误推测法进行用例设计，来避免同样的问题二次产生
  

   问题二：错误推测法用例设计时有遗漏，正式服/生产环境出现了问题，应该进行用例补充吗？
  

   答：如果出现了遗漏内容，一定需要补充测试用例，并且需要补充多个地方：自身所负责的模块/系统，对应遗漏的模块/系统，如果这个内容有庞大的集成条件，理应写进冒烟测试检查中或通用检查点中，以防后续再次出现。
  

  
  
  好啦~以上就是本次文章分享的全部内容啦，你学会了吗？希望能给大家带来帮助哦！