导读：测试工程师像是一位火眼金睛的管家，保障游戏质量，需要进行反复测试。本次，网易游戏测试工程师包子将为大家讲解功能测试的一些基本方法以及如何应用到游戏中。

以下为分享实录：

一、如何做功能测试？

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

1. 制定测试计划；

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

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

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

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

 

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

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

第1个模块，报名模块

报名模块有两个条件，一个是等级条件，一个是人数上限。

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

这里涉及到一个边界值的问题，在人数限定中，如果count是玩家报名以前已经报名的人数，就是小于号，如果是玩家报完名再做比较，这里就要加等于号。从代码编写的角度来看，边界容易出问题，因此我们要对边界值及边界值附近都进行测试。

第2个模块，挑战活动

挑战有以下几个流程。发起挑战，被挑战者排名靠前，挑战成立；否则的话无法挑战，以此类推就形成了一个清晰的流程。

在这个地方，测试时要把每个分支都覆盖一遍，以检测是否有BUG。

第3个模块，结算模块

奖励结算按名次结算，前十名王者礼包，11-100钻石礼包。在我们做测试时可以发现，这些排名被分为了三个区域。 

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

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

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

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

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

二、白盒测试

 

黑盒测试与白盒测试

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

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

白盒测试的方法：

单元测试和集成测试

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

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

白盒测试的工具：

静态代码检查和代码覆盖率测试

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

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

我们日常交流时，判断一个人说话的语法对不对时，会把语言细分成一个个词，再套到语法公式里。那么代码检查也是类似的。我们把源代码分成单词流，再进行语法分析。这是非常粗浅的原理，但实际是十分复杂的，所以工具就十分重要，可以节约我们大量的时间，也能找出我们不太能发现的问题。 

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

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

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

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

以上就是白盒测试的方法和一些概念。

三、感悟

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

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

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

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

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

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

测试的发展趋势

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

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

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

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