场景作为游戏的一个基本构成元素,其功能、效果和性能的重要程度不言而喻。良好的场景表现是游戏留存率的重要因素,因此,QA对场景的测试需要格外注意。
场景的测试一般分为基础功能、效果、性能三方面。基础功能包括场景的路点配置是否正确,网格、高度图配置是否正确,复活点配置是否正确,npc配置是否正确,空气墙配置是否正确等;效果包括烘焙、LOD、天空盒、高中低配、场景特效、树、水、雾、草等显示是否正常;性能包括场景面数、顶点数、Drawcall是否合理。从这些维度我们可以看到,其对QA的专业能力要求很高,需要具备一定的图形渲染知识和美术那样的像素眼,同时游戏中场景的数量也十分巨大,一个mmorpg类型的游戏,其场景数量往往达到上百个。所以一套流程化的场景测试方法和配套的测试工具是十分必要的,不仅能保证测试质量,也能提高测试效率。
笔者所在的游戏是基于Unity开发的,下面我将以某个场景的一个测试报告为模板,介绍下目前我们组内针对一个在Unity下开发的场景的测试流程和方法。
首先是报告的一个概要信息,其中主观感受可能大家会比较疑惑,为什么会出现在这里。个人觉得不管最后你测试的数据如何,最后玩家不不会关心这些数据的,他们只会关注感受,比如流畅度如何、画质如何、发烫如何等。所以我们要把自己当做玩家一样去实际体验这个场景,得到一个主观感受。如果我们光关注数据的话,有时候甚至会被数据欺骗。同时为了保证全面性,还会邀请场景的负责策划和美术进行一个场景跑图,从不同角度看待场景,并记录下他们的实际感受。
这里主要是通过一个GM命令,记录下在真机上场景跑图过程中的FPS,然后绘制曲线看是否平滑,有无巨大的波动。
Triangles统计:Triangles_Min = 59334.0 Triangles_Max =461620.5 Triangles_Average = 270621.0
同理会画出batch和vertice的图。其中第一张图是数据的一个波浪图、第二个图是2D的图,颜色越深代表数值越大,其中x和y分别对应地图的坐标。第三张图是在Unity编辑器的Scene视图下生成的,能够较为直观的看到地图中各个点的性能指标。在性能测试之前,我们会设定场景各个性能指标的阈值,最后将实际测试的数据和事先约定的阈值对比。这里为什么要选取4个方向呢?因为每个点的性能数据和LOD相关,LOD和镜头的视角有关,所以这里我们简单的选取了4个方向,然后做一个平均值。
这个工具会检查场景中Renderer的分布密度,如果某个区域内密度过大,会输出一个warning,然后交给策划和美术,和他们确认下是否需要调整下场景的布局。
这个工具中我们会对场景的基础配置进行一个自动化检查,比如LOD配置、Animation组件配置等,这些检查结果会输出到一个log文件中,如果有相关的错误,就会开单子给对应的美术或者策划。
这两个工具都可以对场景内的NPC做一个检查。其功能是遍历当前场景内所有的NPC,并传送到其附近,然后人工确认下NPC的基础表现和功能是否正常。
最后,我们还会编写针对场景的一些测试用例,这些测试用例会更偏重各个场景的特殊之处,比如:
那么根据什么原则选取这些景观呢?1是场景的标志性景观,2是在日常的测试中,多次出现过bug的物件。
大家可能还有一个疑问,针对场景的这么一个较为完整的测试,在什么时候开展呢?按照目前我们的经验是,等美术、策划和程序优化过一轮后,或者策划这边反馈说这个场景已经迭代完成了,那么我们就会进行一次完整的测试。过早的介入,会因为问题太多,造成各个职能组压力太大,同时有些因为处于迭代中,会造成不必要的时间成本。过晚的介入,会给修改和优化带来一定的压力,尤其是美术资源这块,千万不要临近版本上线之前进行大规模优化或者迭代。
还有一个场景测试过程中存在的问题是,比如某个广告牌有一个流光的效果,或者树叶不能透光,甚至是某个NPC的衣服样式不正确,这些在QA测试的时候很难发现,或者不被认为是Bug,因为我们不清楚场景设计的原稿是如何的。所以我们目前会定期开展的一个工作是,美术、策划、QA坐在一起,对场景进行一个跑图检查,这样场景原始的设计者、实现者、测试者汇聚一堂,很容易将一些表现效果类的问题发现出来。
以上就是目前我们项目在场景测试这块的一些方法流程和工具。
来源:“ 不安分的小QA”微信公众号,作者:彩虹小金刚
原文链接:https://mp.weixin.qq.com/s/kLzLNjngNEHIcqAKDMryww
【声明】文章来源于网上采集整理,版权归原作者所有,如有侵权,请邮件反馈yidunmarket@126.com,我们将尽快核实修改。
相关阅读: