测试用例设计方法_错误推测法（游戏向）

一、前言

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

二、错误推测法的魅力

错误推测法发现的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，慢慢的变得更加熟悉，更加了解。

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

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

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

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