方法定义

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

主要还是一个慢慢积累的过程。一般来说，常见的错误推测法都是有一些惯例的，也就是比较容易出错的地方。我们可以从这方面可以入手，比如在输入年龄的时候，有个年龄输入框，输入一个超长的混合字符串，这个是很容易出错的。

该方法强调的是对被测试软件的需求理解以及设计实现的细节把握，当然还有个人的能力。那么显而易见地，这个方法的缺点就是太过依赖个人能力，难以系统化。因此，这个方法一般是作为测试用例设计的补充，而不是单独用来设计测试用例。

优点

错误推断法是一种基于经验的测试设计方法。使用错误推断法来设计测试用例，测试用例的有效性（测试用例发现缺陷的能力）会比较高，但也容易引发过度测试——测试者可能会为了发现缺陷而测试得过于严苛，却忽视对一些基本功能和场景的测试验证，造成测试遗漏。

一般来说，我们建议把错误推断法和基于模型的测试设计法放在一起使用，在保证测试用例对场景、功能、设计有一定覆盖度的基础上，进一步增加测试用例的有效性。

错误推断法中的“经验”，主要源于对产品缺陷的分析。

与等价类划分法和边界值分析法的区别
错误推测法其实它不同于等价类划分法或者边界值分析法，它是对有效等价类和边界值分析法的一个补充。因为错误推测法从这个里面我们也可以看出，从这句话也可以看出它注重的是一个推测。所谓的推测就是你要有自己的经验，就是在写了很多的测试用例之后，积累了很多的经验。

遇到一个产品之后，就根据自己的经验，在有效等价类和边界值分析法之外，仍能想到一些测试它的方法，这就是错误推测法。这个方法主要还是靠经验，个人经验比较丰富的话，这个方法可以写很多测试用例。

操作步骤

错误推断法的操作步骤如下：

对非测试用例发现的缺陷进行分析时，用了很多启发式的问题，我们可以一边给自己提问题，一边记录下想到的“灵感”；也可以由一个团队来进行上述过程，大家一起来激发灵感，拓展思路，提高测试用例设计的有效性。

举例

那很有可能这个引号作为一个数字判断也是容易出错的，所以这都是容易忽略的，忽略的状态下，所以一个单引号也是容易会出现问题的。所以通过错误推测法的话，写测试用例的时候，对于输入条件就可以写比如说年龄输入的话就是 20 到 99 的整数。

我们就可以对它进行分析，在输入框输入超长字符串，也有可能报错。错误推测的取值可以写一个很长的一个字符串，把这个字符串作为一个测试用例，输入到输入框里面，看它是否出错。还有全角，我们把这些全角的字符串也输入进去，作为一个测试用例。

还有 0，还有单引号都一样，都作为测试用例。当然错误推测法不止这几种罗列的可能性，只不过这几种比较常见，还有更多的一些常见的可能性，还需要自己去探索一下。

案例总结

强调：没有出现过此bug，不代表这个场景不会出问题

元素类型遍历

当一个元素有不同种类型时，需要遍历该元素所有需要支持的元素，比如手机号运营商有移动、电信、联通，测试手机号相关的功能，需要遍历到这3个运营商

根据以往经验，港股是大家比较容易忽略的点，刚开始是港股，后来是ETF，现在已经有多起类似bug

联动场景&展开收起后跳转&跳转页面后返回的记忆场景

一般一个功能，多个页面之间交互上是有关联的，不同页面、不同操作之间的联动

不同技术栈协议测试

客户端与H5：此处协议是刷新机制，H5添加/编辑/删除操作后需要看客户端是否刷新；

服务端与前端/客户端：前端添加/编辑/删除后，前端需要发起请求告诉服务端，此时响应结果应该是添加/编辑/删除后的结果，为了验证数据库的保存操作正常，需要验证退出再进入页面，数据是修改后的，而不会恢复成修改之前的。

涉及到客户端与H5交互的，需要测试协议之间是否是通的，比如添加流水之后，返回原生是否刷新等，我们需要从开发方案上理解，为什么会产生此种bug，一般情况是开发忘记请求接口。

元素/页面依赖验证

当前页面的展示，依托于一些添加的记录，比如交易流水、记账买入流水、记账指出流水等，当把所有记录都删除时，当前页面预期是无法展示数据的，此时页面是否正常显示，如果没有兼容，可能会出现空白、数据都显示–、null、NaN%等，比较好的用户体验是，先跳回到该页面，再返回到上一级页面。而停留在该页面是不好的用户体验，因为当前页面已经没用了，不应展示。

不同页面对于同一元素操作的联动性

能够不断切换不同元素的场景，那我想导航栏和下面的内容是否可以及时联动，比如频繁快速切换，页面内容与标题能否对应，（需要了解开发方案）

当两个页面都有同一个切换功能，比如顶部导航栏切换元素1，可以先在A页面多次切换，再查看B页面的内容是否是当前元素1的内容

交互的边界场景

注意：不是只有数值才有边界值，交互场景也有边界场景，比如可以左右滑动的Colum，滑动到最左边和左右边，是否有合适的间隔，比如一般都会在左侧会设置间隔，但是滑动到最右侧忘记加间隔，会导致整体不协调

比如页面支持上下滑动是，滑动到某栏悬浮、滑动到最底部，显示是否正常，有时候底部按钮会被底部的操作栏遮挡一部分，具体解决方案是，增加距离底部的间距

日期的边界值

除了数值边界值、页面交互边界场景，涉及到日期的还需要日期的边界值，具体如下：

年份：历史年份、当年、未来年份

月份：去年月份、今年历史月份、当月、未来月份

日：去年日期、今年历史日期、昨日、当日、未来日期

日期的特殊性：工作日、非工作日、节假日、短节假日、长节假日、交易日、非交易日、纪念日、普通日等，涉及具体业务，业务场景不一致，可以自己选择列举

历史业务耦合

此项对业务经验掌握要求很高，业务越熟悉越能发现问题，那么对于经验不足的同学怎么办呢？可以在编写用例时进行实操，查看现有应用当前页面有哪些元素和功能，然后联想需求更改可能产生的问题，或者产品、开发可能遗漏的点。

新业务支持

当一个业务历史支持了类型A,B，此次需求新增C类型，虽然模型是复用的，但肯定是部分通用的，或者我们需要通过测试来发现应用到新类型上的不兼容性，需要开发专门针对此种类型做兼容

比如：支付宝支持买普通基金，如果后续支持港基、QDII基金，需要针对该基金做完全测试

为什么要考虑这么多？

因为线上不支持一定是有原因的，一般页面是通用的，想要支持多账户类型难度不大，主要是依赖的流水不同，导致算法的兼容性存在难度，所以一般刚开始会先支持A种账户，有更多时间再支持B种账户（两融的用户少，优先级低），所以具体流程就是：确定历史不支持原因—>确定特殊性（特殊流水）—>现有其他功能是否有应用—>开发实现方案—>确定测试颗粒度

汇总的聚合和去重

涉及到汇总，我们要想到多个子元素如果存在相同的元素，聚合后按照业务进行聚合去重，我们重点看下聚合的场景

需要理清楚开发的方案是通过什么去聚合的，避免不同元素的记录会产生覆盖的情况

极限测试

这个和边界值有点类似，但又有不同。

比如限制只能添加30个账户，那么我们需要测试30和31的情况，但是这并不是真正意义上的极限测试，因为这个为了避免数量多有问题，特意设置了最大值，但在实际测试情况中，会有没有设置阈值或者最大值的情况，产品并不知道阈值到底在哪里，同时也想尽量支持到最大的情况，不想给用户太多限制，比如记录交易记录、记账等情况。

如果只是让添加流水就好了，重点是后续的根据流水进行全量计算和增量计算，如果你添加足够久的流水，就会出现超时、报错、计算出错等情况，这里包含了压测的测试手段。要求不是很高的情况下，可以根据当前经验以及查到的现有用户数据进行评估，一般用户最多只会添加多久的数据，支持一个大致的最大值就行。当然如果性能要求高的，肯定是要进行完备的压测。

顺/逆状态转换

测试中还有一个高频的测试场景：状态转换

一般测试中会有多个状态，相邻的状态之间、非相邻的状态之间都能正常转换

比如正常流程是状态1—>状态2—>状态3—>状态4，如果业务允许，逆序状态测试状态4—>状态3—>状态2—>状态1，以上为相邻状态转换，非相邻状态如果业务支持也需要遍历转换场景，比如状态4—>状态1

案例1：淘宝下单，状态流有，待付款—>待发货—>待收货—>待评价—>退货退款，其中待发货、待收货、待评价3个状态都可以直接到退货退款状态。当然这个案例中所有状态是不可逆的。

参考文档：https://www.cnblogs.com/northeast/p/15817894.html

参考书籍：《测试架构师修炼之道：从测试工程师到测试架构师（第2版）》

【经验】软件测试用例设计之错误推测法相关推荐

测试用例设计方法-错误推测法
错误推测法定义:基于经验和直觉推测程序中所有可能存在的各种错误,从而有针对性的设计测试用例的方法. 基本思想:列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例. 1. ...
软件测试用例设计方法（一）
目录软件测试用例设计之等价类划分法一.等价类划分法的定义二.等价类划分法的术语三.等价类划分原则四.实例演示(三角形问题和档案管理系统问题) 软件测试用例之边界值分析法一.边界值分析法定义 ...
其他测试用例设计方法-错误推测法与正交实验法
常用的测试用例设计方法,前面基本都介绍完了,其中等价类划分法.边界值法与场景法是最常用的. 本篇文章介绍剩余两种测试方法--错误推测法与正交实验法. 错误推测法基于经验和直觉推测程序中所有可能存在的 ...
软件测试用例设计“八法归一”——因果阵
[本文出自天外归云的博客园] 八法测试用例设计有八法: 1. 等价类划分法 2. 边界值分析法 3. 错误推测法 4. 因果图法 5. 路径覆盖法 6. 功能图法 7. 正交试验设计法 8. 场景设 ...
【测试基础】软件测试用例设计方法
软件测试用例设计方法软件测试的核心就是测试用例的编写!!! 那么我们应该学习如何来编写软件测试用例呢? 通常我们会通过学习几种设计放了编写软件软件用例它们分别是等价类划分,边界值分析法,场景法,错误 ...
软件测试用例设计实用经验之谈
概述软件测试用例设计最重要的前提是掌握业务知识,加上一定的测试用例设计方法,软件测试的工作实际就非常简单了,多测试几个实际项目技能就自然提高了. 我把软件测试用例设计分成4个部分: ·测试类型 ·设 ...
手机软件测试用例设计
实例讲解手机软件测试用例设计实例讲解手机软件测试用例设计,测试伴随在整个手机软件开发的各个阶段中,测试质量的高低直接关系到手机软件的可用性,友好性,可靠性.可以说,测试环节是手机软件开发的重要环节, ...
软件测试怎么测边界值,软件测试用例设计之边界值分析法(示例代码)
软件测试用例设计之边界值分析法一.定义对输入或输出的边界值进行测试的一种黑盒测试方法.通常边界值分析法是作为对等价类划分法的补充,其测试用例来自等价类的边界二.与等价类划分的区别边界值分析法首 ...
学习软件测试（三）测试用例、测试用例的设计方法(等价类划分法、边界值分析法、判定表法、因果图法、正交排列法、场景法、错误推测法)
目录测试用例测试用例八大要素测试用例的设计方法等价类划分法等价类操作步骤边界值分析法边界范围边界值法的操作步骤案例1 案例2 判定表法为什么使用判定表法判定表法的四个组成部分判 ...

【经验】软件测试用例设计之错误推测法