如何做功能测试？功能测试的基本方法及应用详解

一、如何做功能测试？

游戏功能测试，就是对产品各功能进行验证，设计测试用例，逐项测试检查是否达到预期。通常，我们把功能测试分成如下几个步骤：

1. 制定测试计划；

2. 设计测试用例：包含测试什么东西，在什么场景什么环境下测试；

3. 执行测试及产生测试报告；

其中，最核心的是第二步，简单来说就是我怎样去测试这些东西，测试完之后我怎样保证能发现尽量多的问题，从而解决BUG。接下来就详细讲讲具体案例。

如图这是一个排行榜的玩法，我可以挑战名次比我靠前的人，挑战的是对方的防守阵容。如果我挑战成功，我的名次就和对方互换。规则概览如下，这里将规则简单化了，实际上一个排行榜规则不可能如此简单。

大家可以思考一下，这样一个玩法规则，你觉得需要测些什么。

我们跟进这个玩法测试时，会发现这个玩法很自然的分成3个模块：报名、挑战、活动结束&结算，我们将这3个模块分别进行测试。

第1个模块，报名模块

20级玩家级以上才能参加，限定1000人报名，程序在写判断的时候会写： 

第2个模块，挑战活动

第3个模块，结算模块

我们可以认为，三个区域内的排名是等价的，也就是说，1—10名中，如果随机抽取一个名次得到的奖励是正确的，剩下的9个名次拿到的奖励也是正确的，因此1000个名次看成三个区间，每个区间随机抽取一个名次进行测试，所以我们可以用等价划分加边界值来测试。

是不是这样测试就足够了呢？

刚刚我们假设的，是按照步骤一步步走的玩家，但有些玩家会遇到很多其他的情况，因此我们在做测试的时候，要比玩家想得更多，提前预防“骚操作”，去测试游戏功能是否正常。

举个例子，玩家在挑战过程中掉线了、玩家游戏的账号被顶号了，又或者在挑战过程中，对手的名次又变了，出现这些情况游戏应该采用怎样的处理方式，也是我们做测试时需要考虑的问题，这就是功能测试需要做的事情。

功能测试有很多的方法论，除了刚刚提到的边界值、分支覆盖、等价类外，还有很多方法，但万变不离其宗，都是为了找出容易出问题的点，去执行这些用例。

二、白盒测试

黑盒测试与白盒测试

什么叫黑盒测试，我们可以认为一款软件就像一个黑盒子，我们不知道里面发生了什么，但是我们只管设计输入，再去查看输出是不是符合预期，这个就是黑盒测试。

相应的是白盒测试，白盒测试不同的是，盒子内部的逻辑我们都是知道的。 

白盒测试的方法

单元测试和集成测试

单元测试和集成测试都是针对于代码的测试，假设一个函数是一个单元的话，我们针对细节的单元逐一测试，最后将所有单元拼在一起，做集成测试。 

举个例子：抽卡。抽卡分几步？焚香和祷告，这是玩家的过程。程序代码的过程是什么呢，先扣卡券，再随机，最后发卡。其中随机的过程会生成一个卡池，最后再算概率。那这样各个细分模块就清晰了，整个抽卡的测试就先将每个点单独测一遍，再去测整个抽卡的功能。

白盒测试的工具

白盒测试有哪些常用工具呢？静态代码检查和代码覆盖率测试。

什么是静态代码检查？就是在不运行代码的情况静态检查，类似于大家做完作业检查自己的代码，但是这样效率低，且不容易检查出问题。所以大家发明了不同的工具去检测自己的代码是否是正确。 

第二种是代码覆盖率的测试，代码覆盖率测试与静态代码检查相反，是在代码运行中去检查问题。

假设有个老套的求婚代码，要求求婚者必须是男性角色，被求婚者为女性角色。那我们要如何测试呢？只要运行代码的时候把所有的代码都run一遍，做到完全覆盖，就没问题。

有些也会要求判定覆盖，甚至是条件覆盖，那么复杂度会稍微高一点。再往上难度更难的就是多重条件覆盖，也就是每一种条件组合都要覆盖到。

当然也有很多地方是工具覆盖不到的，并且并不是达到了某种覆盖的100%就表示代码逻辑没有问题了。这个时候就需要我们大家更花心思，用更多的方法去覆盖及测试，这就涉及到更深一些的内容。

三、感悟

最后分享一些形而上的东西，做了这么多年测试，给大家分享一点感悟。

完全测试是可能的么？比如一个计算器，能做到完全测试么？那是不可能的，因为计算器的输入和输出是不能穷举的。所以需要设计测试用例来尽可能地发现问题。

另外，并不是所有的软件缺陷都要去修复。理想来说肯定是修复好所有的bug是最好的，但这个在现实中很难实现。我们要考虑成本和收益，成本就是时间、人力以及风险，收益就是质量、安全、体验以及口碑。做了成本和收益和权衡之后才能决定是不是要修复某一个缺陷。

常常有人问游戏测试和软件测试的区别。除了功能测试之外，手游测试其实很复杂，包含了可玩性、平衡性、压力、性能、安全性等测试，这里没法一一展开讲。

简单举个例子，比如一个副本，只有全服全厉害的人才能玩，那这个副本就是无效的，虽然没有bug，但是不符合可玩性。比如MOBA类游戏，出了一个新英雄非常厉害，无可匹敌，也是不合理的，这个就是平衡性问题。

第二点，手游测试有更难的自动化测试，首先是技术上的难度，其次是游戏的随机性使得自动化流程的设计也更加难。

测试的发展趋势

最后和大家分享下测试的发展趋势。一开始是以验证为导向，即只要验证过了就可以。再到破坏行为导向，比如贩卖机，光验证能买到饮料不够，有些买家可能会踢它，还要经历风吹雨晒也不坏，所以要去做这样的暴力测试。

可是后来人们发现，极端情况并不是大家最关心的部分，大家更关心产品的整体质量评估，比如耐用年限，在什么环境下容易出问题等等，所以逐渐地质量保障需要做更全面的质量评估。

再到现在，随着人们普遍认识到问题发现得越早，修复的成本就越小，一个重要的趋势就是通过流程、规范等手段把缺陷扼杀在摇篮里，也就是以缺陷预防为导向。

观察游戏游戏开发模型，我们会发现工作流是从设计师、到开发、再到测试。但是因为测试是下游阶段，越晚发现问题，越难去修改。其实测试应该在更早介入，比如在设计阶段，从数值、从整体架构就能发现问题并提出问题，来降低修复成本，预防更大的问题发生。

更多秋招干货，上网易游戏学院app查看！
APP:https://game.academy.163.com/ssi/app/?referrer=niuke