浅谈性能测试

前言

初中时期，有了自己的第一部手机iPhone6Plus，它的运行内存仅有1G。当我用着这部手机乐此不疲的玩着雷霆战机无尽模式的时候，打到某个进度总会闪退。

小时候的我便会感叹，“又闪退了，没法冲更高的分数了，会不会手机空间不够啊。”

而如今的我，负责着项目组的性能测试，写这篇文章总结自己经验之余，也是为了解答小时候自己的疑问。

性能指标

既然要做性能测试，先了解常用的几个客户端性能指标吧：
FPS
内存
CPU占用率
耗电量
网络流量

https://liushilive.github.io/github_exercise_performance_testing/md/performance/index.html

在游戏运行期间，通过第三方工具、SDK、引擎工具等获取这部分数据。这里放几个看起来不错的工具：

PrefDog：腾讯开源的性能数据采集工具。
UWA：入侵式SDK，收费项目。据说数据深度与广度比PrefDog更强，个人没用过。放个官网链接吧：www.uwa4d.com
Unity中的Profiler与Stats：引擎自带的工具，仅能检测到Unity引擎自身的内存分配，无法监测到引用的第三方库的性能状况。

其中我个人只用过PrefDog和Profiler，UWA往后加油学习吧！（啊枫你又给自己挖坑哦？）

静态客户端性能

这个概念是我从别的文章看过来的，但我认为是个很棒的测试理念。说起性能测试，大部分QA同学想到的或许就是可视化的性能监测曲线。但其实，不运行游戏也是可以做性能测试的。

这里概要的说两点：无用/重复资源检查、资源合规性检查。

无用/重复资源检查

随着项目的研发，功能不断迭代，资源数量也会不断增长。新资源代替旧资源，但是旧资源仍然保留在包里的情况是很常见的。QA如何发现这些无用资源老实说是一种特别耗费精力的事情。

此处提供一个我们项目组中常用的一个方法，那便是查配置表。一般一些图片，或者是音效等都会配置在配置表中，我们直接扫描对应的资源是否存在配置表中，如果可以发现不存在于配置表中的资源，则大概率是无用资源。当然也有部分资源直接使用在游戏场景中的情况，还需结合项目实际情况进行确认。

资源合规性检查

另外，对于美术提交的资源，我们QA也可以进行检查，比如我们统一了游戏内的角色头像图标的分辨率为125×125，某天发现美术提交的资源却是1080×1080的，那就得找美术确认资源是否合规了。

动态客户端性能

那终于到了大伙儿比较熟悉的性能监测相关内容了，性能监测其实并不难，用工具自己跑自己也就熟悉个七七八八了，那我也就不在这里重复一下大家都已经知道的东西，分享几个自己觉得需要注意的点吧。

内存泄漏

何为内存泄漏：动态开辟的空间，在使用完毕后未释放，结果导致一直占据该内存单元。直到程序结束。

形象点地说，就是你作为一个进程，开始时要到了100MB的内存空间，结束的时候却只还了80MB，剩下的20MB你自己也不知道去哪儿了，只能等整个程序结束才会把这20MB释放出来。

造成内存泄露的原因太多了，某一行代码不对，我们QA可能就得查很久。这是一个易改难查的问题。而反馈到游戏客户端的表现，就是游戏长时间游玩会越来越卡，最终可能会内存溢出，导致闪退。如果怀疑游戏存在内存泄漏问题，可以参考下述方法进行定位：

一：使用类似服务端压力测试的方法，先对游戏内功能模块进行拆解，然后长时间游玩游戏内各个模块并且采集内存数据。最终通过可视化的方式，观察内存曲线是否处于上升趋势。如果是，则记录那几个有明显上升趋势的模块。

二：针对步骤一中确认出来的模块，多次循环运行并且采集内存数据。如果跑出来的内存曲线是一直上升的趋势，则基本可以实锤这个功能存在内存泄漏问题。可以拿着自己的测试结果找研发Battle了。

https://zhuanlan.zhihu.com/p/354615686

内存碎片

一刻也没有为内存泄漏导致闪退哀悼，立刻赶到战场的是内存碎片问题。

何为内存碎片：https://zhuanlan.zhihu.com/p/589406667

简单地说，内存碎片化是由于程序不断分配内存，导致许多细碎内存无法被使用的问题。形象比喻的话，有点像是吃汤面的时候，每次用筷子夹起来咬断，吃到最后总有几条太短的面条没法用筷子夹上来。

内存碎片其实是个很难避免的问题，如果长时间游玩记录下来的内存曲线是上升趋势，但又无法找出具体是那个模块存在内存泄漏问题，那可能根本不是内存泄漏问题，而是内存碎片问题。

对于QA来说，首先要确认内存曲线上升趋势的最大接受程度。举个例子，同样的性能规格设备下，或许连续玩三天才会因为内存碎片化问题，导致内存溢出而闪退，大多数情况下都是可被容忍的。但如果说连续玩三小时就闪退了，那肯定不行，必须让程序狠狠滴优化。

资源占用合理性

这个其实并不复杂，但做起来比较耗费时间。针对某些场景，我们通常需要借助引擎工具，查看一些高内存占用的资源是否合理。比如说场景内某张不显眼的贴图占用了100MB内存，那显然是不合理的。

再举个例子，绝地求生匹配进游戏后，玩家会出现在素质广场，可以进行跑动、拳击、试枪等操作，但没有载具提供给玩家。假如说这时候作为QA你发现在这个场景下，也加载了角色的开车动作，那这显然是不太合理的。

新手教程的重要性

新手教程，是每个游戏新玩家第一接触的游戏内容。算是游戏呈现给玩家的第一印象，很大程度上决定了玩家留存与否。

所以针对新手流程的性能测试，测试用例要尽可能详细，划分的模块也要尽可能细。目的就是提供玩家一个流畅的新手流程。

特殊/极限情况

针对某些游戏场景，我们需要测试它的极限情况。常见的比如说一些多人PVP玩法、公共场景等。

举个极限情况优化差例子，永劫无间比赛决赛圈40个人，官方OB都卡得不行，这就是测试用例没有覆盖到极限情况。当然，或许QA当时也没想到好端端一个大逃杀游戏，决赛圈还能有40个人。

通常进行这种极限情况测试，需要多个QA，如果QA不够了可以引入游戏机器人或者多设备运行自动化脚本。尽可能在多个不同设备采集性能数据。

QA角度看待性能测试

作为游戏QA，需要加强自身的性能测试意识，并不是说保证一个功能测试通过就完事儿了。在部分游戏类型中，性能测试的重要程度并不会低于功能测试。前文提到的永劫无间决赛圈就是个很好的例子。

最近的一次工作中，我们接到了一个卡池复刻的需求，我自己算了下，极限情况下游戏内会同时开14个卡池，而每个不同卡池之间又会有不同的背景动画，势必会带来跟多的内存需求。我很庆幸自己能想到要进行性能测试，同时也意识到了自己之前测过的许多功能，都缺少了性能相关测试。自身的质量保障思维还需要完善啊。

此外，我们需要明确性能测试并不是我们QA一次的短期测试需求，而是整个游戏项目组长期合作的具有挑战性的任务。作为QA的我们自然要主导性能测试、策划要精简配置表、美术要规范资源、程序要写好代码……

游戏研发过程中使用任何一种优化技术手段之后，我们也要即使进行性能测冒烟测试。类似于当初报名蓝桥杯刷算法题的时候一样，运行空间与时间复杂度很难兼得，目前多数技术手段仍然是追求性能上的某种平衡，很少说是用了某个技术手段就能将整个游戏的性能飞跃提升。所以我们QA在平时就要做好性能测试，将质量保障的思想植入到整个项目组里其他同事脑子里。

その他

最近面试的时候总是对自己的一些口头表达不太满意，而写文章确确实实的可以提升我的表达能力，这也是为什么我希望自己的文章口头化一点，一来好看好读，二来也是锻炼自己口头语音组织能力。“口述是快速的写作，而写作是缓慢的表达。”这句话突然就觉得很有道理。

文章写到这里算是结束了，很久没有写这种较长的文章了（其实三千字不到）。文章中也只算是作者在参考其他文章基础上，结合自己理解，产出的些许浅薄经验，无论如何，学习之路无止境，还是希望自己保持学习的东西去了解更加深入的东西。若有读者读至此处，并且能有一些启发，那就再好不过了。