关于游戏测试的细节

我本身对游戏测试了解甚少，下面是根据一些资料以及自己的理解整理得来的。

　　游戏测试也是软件测试的一部分，所以游戏测试分为游戏软件的测试和游戏本身的测试，但是游戏本身还涉及到可玩性、娱乐性、竞技性等特征，所以有些地方需要特殊对待。

 

　　游戏世界的测试有以下特征：

　　1、游戏情节的测试，主要指游戏世界中的任务系统的组成，有人也称为游戏世界的事件驱动，我喜欢称为游戏情感世界的测试。

　　2、游戏世界的平衡测试，主要表现在经济平衡，能力平衡（包含技能，属性等等），保证游戏世界竞争公平。

　　3、游戏文化的测试，比如整个游戏世界的风格，是中国文化主导，还是日韩风格等等，大到游戏整体，小到NPC（游戏世界人物）对话，比如一个书生，他的对话就必需斯文，不可以用江湖语言J。

 

　　（一）网络游戏测试

　　我举一个Mmog的例子（注：mmog是大型网络游戏的缩写），大型网络游戏主要是即时战略性质的，所以通讯上采用TCP协议来发送数据包。TCP协议发送数据包的优点是尽量能够减少数据包的丢失，他是对数据包的一个精包装，一般的发送数据包采用实时处理的形式，即采用堵塞式的处理模式，而不是等到一定空间的数据包满了以后才一起发送（非堵塞式的处理模式）。

 

　　需要测试的点有哪些呢？

　　1、服务端的测试。测试同步消息的传递，即在很多玩家的情况下，信息能否顺利的通知给各个玩家。服务器需要处理的事情有：下发玩家信息，仲裁胜负信息，仲裁装备信息，服务器之间中转信息，状态存盘，玩家信息存盘等。下发玩家信息时服务器承受的压力最大，这个时候相当于需要做一个压力测试（参考LR的各项指标进行），看信息能否准确顺利的送给相应的玩家。这个时候需要对通讯协议有比较深刻的理解。

 

　　2、客户端的测试。主要工作为验证功能逻辑，例如我举个例子，任务系统，现在每个游戏都有任务系统。如果测试任务系统，我们应该怎么测试？首先完成任务的条件是什么？完成任务需要什么道具？玩家能得到什么道具？道具是否可以交易，拾捡？道具是否可以买卖？玩家跟NPC（非玩家控制角色）交付任务断线处理？NPC在不同的状态下所说话的内容？是公共任务还是门派任务？在得到道具过程中储物箱满了会怎么处理？在负重超出了本身能力的情况下怎么处理？等等，把细节的问题考虑清楚了，这样设计案例执行就是了，没有自动化的必要（但是可以在组件测试中进行自动化，系统测试没有必要自动化）。

 

　　客户端还有一个测试点就是地图，因为地图是游戏的门面，所以地图的检查点：绚丽度，整个地图的亮度，不同分辨率下的地图显示，地图的拼接，地图上NPC或者怪物的分布等等都很重要。

 

 

　　（二）C/S结构测试

　　C/S结构的系统要求是：服务器处理能力强，反馈及时，并且这种服务器压力是出现在业务繁忙的时候，所以在测试这种软件的时候，需要完全弄清楚业务逻辑，业务点在那里？信息同步在那些方面需要关注？服务端数据处理流程是什么？如果把以上问题搞清楚了，测试的重点也就出来了。

 

　　哪些地方形成了压力？

　　当客户端要求登陆服务器的时候，通过账号数据库验证，然后取出该账号对应的角色，然后告诉客户端你是我们的用户，然后由网关把该玩家连接到响应的GameSvr上。客户端向服务器发送登陆请求时，采用非阻塞式处理，使得各客户端的请求形成非队列形式，这样服务器端的压力不大，处理速度快，而且玩家和账号数据库并不是持久连接，而是保持一个心跳，所以登陆过程不会对服务器造成多大压力。

 

　　压力在于：

　　1、玩家走路，大家都知道，网络最主要的特点是同步信息，也就是说，当一个玩家走动以后，服务器首先要计算一次，当前玩家指的坐标是否正确，其次，服务器要下发消息，告诉周围的玩家，他现在在那里，怎么样的姿态存在。因为服务器会给一定范围内的玩家通知这些信息，造成服务器压力增多，因为服务器（GaemSvr）和玩家保持的是一个TCP的长连接，如果当前服务器或者一屏（或者说一定范围内的玩家相对比较多）的情况下，服务器要处理当前服务器上类似于上面描述的若干个这样的情况，造成服务器压力巨大。

 

　　2、聊天，为什么说聊天会造成服务器压力比较大呢？因为当A对B说话，服务器需要寻找，当前B在那里，然后通知A，B在，你可以说话给他，这个时候A才可能和B说话。如果人相对比较多的话，可能造成服务器压力大。

 

　　3、跨服务器行走，也会造成服务器压力巨大。因为当你从一个服务器跨到另外一个服务器的时候，服务器需要把第一个服务器上玩家的数据拷贝的另外一个服务器，然后初始化一个实体，然后再告诉DB，把这个人的数据存盘一次，然后再尝试跨服务器，如果跨成功，则把该数据初始化给本玩家，如果不成功，则另外处理，这样造成服务器的压力大。

 

　　TCP通讯中，丢包后会有补偿机制，对数据包进行补偿有两种方法：

　　第一种方法是把从丢失的第一个包到当前包作为一个整体的包，进行包的重播，这样的方法会使得从客户端看到通常我们在游戏中所出现的“卡”现象，还有另外一种补偿机制，就是把前面的数据包丢弃，然后播放最后一个数据包信息，这样就会在其他的客户端看到一些莫名其妙的现象。

 

转自：http://www.51testing.com/html/70/n-210270.html