入行游戏测试之测试方法篇

测试方法大概分为以下几种：场景法、等价类、边界值、错误推测、因果图、判定表、正交实验设计法，以下将重点介绍场景法、等价类和边界值法，这三种方法用得最频繁，其他方法在我一年多的工作经验中，基本对我来说就是个概念问题，可能还是我菜，所以用不到具体的实践中，这里暂且不表，感兴趣的同学可以百度看看。而错误推测法比较特殊，顾名思义就行，貌似不能举什么例子，需要有经验来推测。

这些测试方法有什么用呢？主要是为写测试用例而作的理论基础。

一、场景法

百度百科对场景法的解释是：通过运用场景来对系统的功能点或业务流程的描述，从而提高测试效果的一种方法。用例场景来测试需求是指模拟特定场景边界发生的事情，通过事件来触发某个动作的发生，观察事件的最终结果，从而用来发现需求中存在的问题。我们通常以正常的用例场景分析开始，然后再着手其他的场景分析。场景法一般包含基本流和备用流，从一个流程开始，通过描述经过的路径来确定的过程，经过遍历所有的基本流和备用流来完成整个场景。场景主要包括4种主要的类型：正常的用例场景，备选的用例场景，异常的用例场景，假定推测的场景。

是不是看起来有点多，且难以理解？

我刚开始也是不能理解，直到将它形成自己的理解思路，可能不全面，但是对我还是有作用的，在写测试用例中也用得比较多，我喜欢这么理解场景法：

在一个游戏功能中，将大功能拆分为一个个小功能，而这些小功能就可以视为一个个小场景，这些小场景的集合就成了这个完整的功能模块。

举个例子：王者荣耀的每日任务功能

这个每日任务小功能可以将他分成三个场景：

1.今日活跃度

2.具体任务信息

3.本周活跃度

这三个场景就组成了一个完整的每日任务功能。当然，看到这里你可能会说这不是一个测试用例吧？

对，在我的理解中，我把场景法变成了一个测试思路。

二、等价类分析方法

百度百科中：等价类划分，指的是一种典型的、重要的黑盒测试方法。其就是解决如何选择适当的数据子集来代表整个数据集的问题，通过降低测试的数目去实现“合理的”覆盖，以此来发现更多的软件缺陷，统计好数据后由此对软件进行改进升级。

作为一名游戏测试，不可能用枚举的方法去测试一个个区间，虽然看起来很有必要，但是在实际工作中，使用枚举法，即将所有的可能性都测一遍，一个是效率低，另一个是工作时间不允许。

比如测一个邮件发奖的任务，前三名分别会获得什么什么道具奖励，那这个可以用枚举法，因为就只有这三个账号，查看第一名的奖励，第二名的奖励，第三名的奖励一一对应，不会出现说第一名的发成第二名的奖励，再核对奖励道具就说明成功了。

如果再加一个任务呢？比如，在第4-10名会发放xxx奖励。

按照枚举法，就需要登录第4-10名得账号，一个个去查看这7个账号的道具奖励是不是一样。

你可能会觉得才10个账号嘛，简单。

那如果再加：第11-100名发放yyy奖励，这就需要枚举100个账号。

再加：第101-10000名会发放zzz奖励，10000个账号这怎么可能用枚举法一个个去尝试？想想就会头皮发麻，输账号都能让你输得手抽筋！

所以就需要用到等价类划分法。

等价类又会分为有效等价类与无效等价类。

有效等价类：输入的是有意义的集合，用来验证，合理覆盖。无效等价类于此想反。

还是邮件发奖励问题。

前三名因为是特殊的，每个名次获得的东西不一样，所以还是需要一个个去验证，但是第4-10名就可以用有效等价类法来验证了，比如我们可以取其中一个值，区间是第4到10中间随机取一个第五名来验证发放的是不是xxx奖励。第101-10000名同理。

是不是就会变得高效很多？那么多的集合，我就取其中一个有效的值就可以来验证了。

那无效等价类呢？

上面说道第1到10000名都有奖励，但是10000名以后是没有奖励的，1000名以后的所有值的集合就是一个无效的等价类。所以我们就可以取10000名之后的值来验证有没有发放邮件奖励。只会有两种情况，一个是发了，那就说明程序出现了错误，就是个bug。另一个是没发，那就说明是正确的。

为了方便理解，我再举一个例子：

更改名字问题：

我们在输入不合理昵称的时候会收到一个提示：名字最长为6个中文字或12个英文字。

看条件就知道王者荣耀更改名字是有两个限制条件：

1.最长为6个中文字

2.最长为12个英文字

很明显，这里的条件有三个，分别是：字数长度、中文字、英文字，所以这里有效的等价类就可以分为：

①符合的字数长度，比如取1-6个中文字符，1-12个英文字符

②中文字：这个也好理解，上下五千年的中国文字，随机挑几个还是很容易的

③英文字：这个也好理解，英语嘛，那26个英文字母随意组合。

上面都是有效的等价类，无效的又是什么呢？

①超出长度的字数：你让我最长是6个，我就取7个8个

②你限制了只能中英文，那我韩文行不行？俄文又行不行？可以从里面取几个值验证一下。

当然，更改名字的测试并不是只有这么一点，这里只是为了说明等价类的测试方法。

三、边界值法

在我的理解中，此方法就是为了配合有效等价类而加的一个限制条件，具体的定义以及历史渊源可以自己去查，此文暂且不表，直接来举上面的例子说明：

1.王者荣耀每日活跃度

他的设定是今日完成的任务活跃度，到达30、60、90、120、150这个节点时，可以额外领取一个小礼包。

通过学习上面的等价类，我们知道，到达30获得可以领取小礼包，在0-30就可以设置一个有效的等价类，0-29活跃度是不可以领取奖励的，只有到达30才能领取奖励，那么这里数字30就是一个边界点。

所以30活跃度的礼包的边界值就有3个：0、29和30.

为什么会取这三个边界值呢？

0-29之间的活跃度可能是不能领取奖励的，只有30可以领取。

那么60活跃度礼包呢？边界值就是59和60，你会不会疑问30怎么不取？那是因为上一个节点30已经取过了呀，形成了覆盖，所以可以选择放弃。

90活跃度礼包呢？边界值89和90.后面的120、150礼包同理。我这里写同理，并不是不需要测试了，而是为了在写测试用例中少写，我们知道有这回事，自己在测试的过程中注意就行。

温馨提醒：0是一个特殊的边界值，不可忽略。

2.邮件奖励发放

看了第一个例子，我想你应该可以明白取哪几个边界值了。

第4-10名得边界值是什么？

对，就是4,10和11.

我猜你可能想的是4、9和10这三个数字。

请注意，边界值的取值要符合具体的功能，具体情况要具体分析嘛。在活跃礼包中，我们为什么不取30后一面的一位值31呢？因为30是可以领取礼包，那么31一定也是可以领取礼包的，30就是一个边界值。

而邮件的奖励为什么会取10后面的11？你想啊，10是正确发放的奖励，我们取这个值没有任何问题，9也是正常取值，但是是属于10以内的，你可以理解为是多余的一个值，并不属于这个任务的边界值。取11呢，因为你不知道11会发放什么奖励。在实际工作中，第11名有可能发，也有可能不发，这是我们边界值得一个起点，也是另一个终点。即11是10的后一位，也是11-100的第一位。

是不是有点迷糊？

不要紧，所以我一般取边界值都是取4个数字，为了保险起见，比如0、1和10，然后另一个值可能是9，也可能是11.

我相信你可以明白的。

3.更改名字字符

直接写答案吧：

①6个中文字，那就取0、1、6和7（虽然我们都知道1是多余的，但是这是个人习惯，希望大佬可以说明一下我这个思路对还是不对。）

②12个英文字：那就取0、1、12和13。

四、寻找问题的源头：

可能你会疑问为什么等价类和边界值要这么取值，那么这个问题就需要有程序逻辑思维了。

拿发放邮件奖励做例子。

程序首先会取你的名次，你是第几名就是第几名，然后存入数据库。

然后判断：

如果你是第一名：那么给你发放第一名的奖励；

如果你是第二名：那么给你发放第二名的奖励；

如果你是第三名：那么给你发放第三名的奖励；

如果你是第四名：那么给你发放第四名的奖励；

如果你是第五名：那么就给你发放第五名的奖励；

···

···

你以为程序会这么写吗？

当然不会，前三名是特殊的，所以会这么写，从第四名到第十名就不会这么写了，他会写一个区间：

如果4<=你<=10（大于等于4，小于等于10），那么就发放xxx奖励；

看出问题了吗？

等价类就是这程序里面的集合，所以你选择里面的一个值是里面的集合就行，意思就是取一个值来验证这一个集合的类。

那么边界值又是怎么出现的呢？

程序爸爸是个人，人也会犯错，当然这极可能是无心之失，比如忘了、键盘敲错了。

怎么说呢，就是把大于符号敲成了大于符号，然后又落了等于符号，这样会造成什么样的后果？

①把大于4写成了小于4，本来是56789，结果变成了01234，所以有效和无效等价类就是这么来的。

②把大于等于4，结果漏了一个等于符号，所以本来是456789，结果就变成了56789，是不是就漏了一个4？那么这个4，就是我们要取边界值的理由。