场景作为游戏的一个基本构成元素，其功能、效果和性能的重要程度不言而喻。良好的场景表现是游戏留存率的重要因素，因此，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坐在一起，对场景进行一个跑图检查，这样场景原始的设计者、实现者、测试者汇聚一堂，很容易将一些表现效果类的问题发现出来。

以上就是目前我们项目在场景测试这块的一些方法流程和工具。