ITPub博客

首页 > Linux操作系统 > Linux操作系统 > 游戏软件的测试方法简述

游戏软件的测试方法简述

原创 Linux操作系统 作者:habug 时间:2009-01-08 14:50:13 0 删除 编辑


1. 测试的定义

  如果给个定义,我觉得:测试工作是,解决玩家所遇非正常问题的预测工作,同时也是不断调试平衡的一个长期观察任务。无论在什么时间段,功能实现、内测、公测等。测试都应该是分硬件与软件两部分测试。   

  2. 硬性问题

   硬件的BUG部分是指会引起不能让游戏流程进行的BUG。死机、画面出错等硬性问题。这种问题只要按照一定流程进行游戏,就会发生。但对一些会不断增加 服务器负担的高级BUG,应该不会短期测试出来。而对这种在有计算机就出现的问题,现在的游戏在制作过程中都有可自动记录问题的LOG功能,所出现的 BUG大多会被程序部门解决掉。部分的LOG功能可保留到正式客户端,以收集因为升级客户端,而不断产生的新问题。这里应该不会在讨论范围内吧。   

  3. 软性问题

  而软件的逻辑部分大多会在后期进行,比如公测。是各种功能 的数值调整。主要为游戏的世界定义一个平衡。除了初级的数值设定外,内部测试人员很少有能把一个功能测试千万遍的。于是有可能产生出猫耍的老虎团团转,这 种经典的寓言故事。策划及相关测试人员注重的应该是这部分的测试原理及方法。

  而这部分问题的测试,同硬性问题一样,需要一定流程及要求。而具体流程只有根据具体游戏来决定,大多是将问题分裂存放,并将理由归纳。但有几点是不变的。

  3.1 平衡的目标

   而如何让各种设定不偏离主题,明确世界背景及制定等级概念应该是首要的。尤其在一些角色等系统十分复杂的情况下。那种变态ADD的规则,可由主角的 5~6种基础属性影响到数十种战斗、非战斗技能。还可根据各种物品来休整这些数值。而无论如何。他们都有个明确的等级观念。从弱到普通,再到强,甚至到最 强的龙。这是因为他们知道一个人,最强也不能强过龙。这样就给自己定下上限目标。

  所以,测试时首先不要去看玩家可选择的职业技能 等等是否足够多。都会获得什么强大的技能、体力等等。先了解到这个世界里,各个种族之间的关系、职业的互补、各个角色的互相的关系,在整个世界中是什么位 置,是否够合理、让常人可以现实中的逻辑去衡量,这个角色在游戏是否合理。之后才需要针对每个种族、每类职业、每个角色的平衡。最后到一个一个角色的测 试。有人会说这是前期策划制定讨论的部分,没错,因为测试从这里就已经在策划的头脑中开始了。

  在这里定义的过程,正好与现实世界中相反。现实世界是总结出整体的平衡,而游戏世界则要定义平衡,再将世界整理成平衡的状态。

  3.2 划分等级

   测试时同样要明确问题的严重等级,一个数值影响的事物越多,那他的严重等级越高。现在的MMRPG整个属性结构,基本都类似树形结构,之间也有着一些交 错的枝叶。力量等最基本的角色属性,为根。这类属性会影响到的其他属性,最终到达游戏的胜负,任务的完成等等。而这些属性的等级自然也就十分明确。根为最 高,枝叶最低。而修整树木永远不会从根开始。

  力量,最基础的属性,结合自己的命中率,对方的敏捷等,会影响物理攻击。同样也影响 着可拿的武器。但如果这个人攻击力过高。那是谁的原因?是武器,还是角色的力量。需要修改那一个?那些角色的基础属性是最不能随便修改的。因此,还是武器 吧。实在不行在从由属性引发的其他部分着手,如技能的熟练度等。越基础的部分,影响力越大,也最容易出错。角色的基础属性是一切测试的根源,同样也是最不 能随便更改的一类。更不应该因为某个问题而被指明要求更改。而添加删除任何一个属性,更会让之前的测试工作有2/3付之一炬,也许更多。而对于各种武器, 基本可以与角色测试分开。在角色属性有数十条的游戏中,武器更不会容易出现大的问题。

  严重等级之间从高到底可分为,角色,物品, 技能。要修正这三大类属性,尽量在自己的范围内修正。不要妄想在其他级别动手,更别想在比自己之前高的级别里动手脚。而在这些属性里面同样还各种属性,就 需要根据具体游戏进行划分测试。虽然这里以属性距离,但任务也同样如此,相互关连的任务网同样十分重要。只不过之前变化较属性掠少。

  3.3 玩家是否付出与获得成正比

   现实世界中,没有可能可用捷径获得某一种事物,只有拼搏。游戏世界里是否也是?获得一个强大技能之前,给角色的锻炼是否足够。让他足够珍惜这一种技能或 物品。这是游戏中较为关键的一部分,多体现在任务上。时间、精力的消耗,是否足够让玩家获得物品时有足够的满足感。以及对得起测试人员的劳动。

  3.4 记录、调整,总结

   软性问题应该同硬性问题一样拥有足够多的文档资料来记录,同时也方便对以往数值的效果再思考。这也应该是所有文档资料应该具备的,记录每次关键更新的工 作。调整方面Sid Meier说过,每一次调整都要多一些。这样可以看到数值中的巨大差别,从中找到合适的数值。这几乎是知道Sid Meier的人都知道的一句话。(大意相似,具体内容没办法记起来,惭愧)

  很多时候,测试时会直接将测试的内容按自己的想法修 改。即便记录下来也是只要改好就好。其实很多时候这些修改都有一定规律,一些修正往往是没改变任何事情。多一些时间去探讨大家是否按照原来制定的目标去修 正,会更合理的利用剩下的时间测试。同样,全部结束后的总结也会让下次制作时避免出现需要大量修正的设计。

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/14780873/viewspace-531866/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论

注册时间:2008-07-07

  • 博文量
    211
  • 访问量
    328009