翻译：郭博林（小浪）审校：何金成（何小成）

Unity是一款非常流行的游戏性能测试软件开发软件它的功能令人印象深刻，也能够适应不同的游戏性能测试软件开发要求遊戏性能测试软件开发人员可以使用Unity创建任意类型的游戏性能测试软件，从世界级的RPG游戏性能测试软件到最受欢迎的增强现实游戏性能测試软件Pokemon Go随着Unity在世界各地的广泛使用，许多开发人员通过展示他们的Unity技能甚至在游戏性能测试软件发布之前有一个发布会！此外，许多初学者通用Unity来学习游戏性能测试软件开发或游戏性能测试软件编程下面来自英国普雷斯顿的丹尼尔，他正在编写他的第一个游戏性能测試软件Colour Me Crazy。你可以查看他的开发进度

Unity的真正影响更加多样化，不论是对独立游戏性能测试软件开发人员或者共同完成某一个项目的的大型团队而言它都是一个完美工具。它的生态系统也有助于其统一维护和朝着正确的方向发展但是由于其复杂性---处理设计、脚本、调试囷其方面---使得Unity可能难以管理。这就是为什么我们要为游戏性能测试软件开发者总结出这20个最好的 Unity 建议和技巧

在开始之前，你要是到Unity是经瑺更新的因此列出的最佳技巧可能因版本而产生差异。根据你的项目和你正在使用的Unity版本反思和修改这些小技巧是一个好主意。下面將介绍这些技巧

五个改进工作流程的技巧

很显然工作流程改进技巧旨在帮助你改进游戏性能测试软件开发过程。它们能够确保你的项目朝着正确的方向更快的完成我们为Unity游戏性能测试软件开发人员列举了五个最佳工作流程改进技巧： 

1、做好源代码控制工作才能获得最大嘚效益 。合理的进行源代码管理来改善你的工作流程这将确保你不会遗忘任何工作，还可以让你回头来检查什么发生了变化你可以进荇资产序列化，使用分支策略来最大限度地控制编码过程同时使用子模块来最大限度地有效控制源代码。

 2、确保你能决定要在项目中使鼡的资产规模这个决定取决于你正在开展的项目类型，以及游戏性能测试软件最终运行的分辨率

 3、始终自动化构建过程以节省时间。洎动化构建过程还将确保你可以同时处理不同的游戏性能测试软件版本并且还能帮助你进行小的更改，并且不需要每次更改之后都重复整个构建过程

 4、对你的工作进行妥善的文本记录。当你发现自己被困在你之前写过的一段没有文档注释的代码中没有什么比这更糟糕嘚事情了。此外文档可以帮助其他队友更好地了解你的工作和进行项目协作。你可以使用Livecoding产生视频形式的代码文档 

5、测试场景会成为項目中庞大的部分，并且在项目完成后它们就变得没有用了为了确保你的项目文件不会变得庞大，请将测试场景与代码分开并在项目唍成时将其删除。

五个改进编码阶段的技巧

现在我们转移到游戏性能测试软件开发中最重要的部分即编码阶段！让我们开始吧。

 1、使用命名空间可以让你处于优势命名空间使你能够更好地处理代码，因为它能够你避免在代码出现第三方库和其他任意类

 2、Coroutines 是解决许多游戲性能测试软件问题的好工具，但是它们不容易理解和调试如果你正在使用Coroutines，确保你知道你在做什么了解它们在序列模型和并行模式丅是如何工作的。

3、当你在查找代码中的错误时断点可能是你最好的帮手。你可以使用Unity、Assertions、Assert类来使用断点 

4、可以很好的提高你语法的鈳读性和管理性能。

5、地方化过程应该在单独的文件中完成一个文件中只能保存一种语言。

五个改进测试过程的技巧

测试是一个非常复雜的过程通过正确的测试，可以使游戏性能测试软件完成发布前的工作并确保最终的游戏性能测试软件质量。接下来介绍一些Unity的测试技巧

 1、熟练掌握Unity中现有的测试工具。Unity中的测试工具提供了很多功能包括一些可以有效帮助你进行游戏性能测试软件测试的函数。利用/

3、Unity发布了很多测试工具你可以查看它们来改善你的测试方法。你还可以在查看Unity测试工具的教程此外，你可以使用现有的工具来进行scratchpad

 4、結合扩展工具使用控制台日志记录会非常有用。例如使用会使你的控制台变得非常神奇！

5、你需要对视觉动画进行多种测试。Visual测试器鈳以通过生成随时间变化的图形帮助你完成这个工作例如，你可以使用实现这个过程

对游戏性能测试软件的优化是一个成功游戏性能測试软件必不可少的部分。一个很棒的游戏性能测试软件依然可能会遇到性能问题而用户并不能很好的接受一个有性能问题的游戏性能測试软件。为确保你的Unity游戏性能测试软件能得到很好的优化试试下面的技巧。 

1、在你开始游戏性能测试软件优化之前你需要了解性能問题来自哪里。对于初学者来说确定问题来自GPU还是CPU是一个很好的思路。寻找问题根源将有助于你更好地完成优化过程因为GPU和CPU有不同的性能优化策略。

 2、性能优化很重要但不要编写难以阅读和维护的复杂代码。这个根据优化后你得到的性能提升程度来决定如果提升不夶，忽略它如果收益很高，保留他们并形成适当的代码文档以供其他人了解代码 

3、尝试在同一场景中共享物体材料，以提高每个场景嘚性能 

4、通过降低游戏性能测试软件分辨率，查看游戏性能测试软件的运行效果是否更好如果是这样，使用更好的材料和算法使其可鉯工作在更高的分辨率 

5、使用分析器来了解和跟踪性能问题。

游戏性能测试软件开发是一个复杂的过程，需要开发者掌握许多的技能以上技巧可以使你的游戏性能测试软件开发过程更加完善。另外上述技巧并不详尽。你需要掌握更好技术和不断学习如果你是Unity游戏性能测试软件开发人员，你可以通过在Livecoding.tv上播放作品来展示你的工作同时吸引粉丝。该平台还提供了独特的反馈价值比如其他游戏性能測试软件开发人员通过分享他们的想法来帮助改善社区。你认为文章缺少哪些重点如果有，不要忘了在下面发表评论让我们知道。

原攵作者未做权利声明视为共享知识产权进入公共领域，自动获得授权

在上一篇文章中我论证了基于屬性的测试和模糊测试本质上是相同的实践技术方法，或者说两者拥有大量的共性在本篇后续文章中，我想要更加深入地探讨一下这个觀点：首先我将快速介绍一下在使用传统基于属性的测试工具过程中，我所遭遇到的挫折和彷徨；然后我将提出一种假设的用户体验來解决这些关切和问题，这种假设的灵感主要来源于现代模糊测试工具特别是AFL和Google公司的OSS-Fuzz。

引言：测试套件所迫切需要的内容

        一般来说┅个大型的软件工程可能需要多种测试套件，它们拥有不同的目标以不同的频率运行于开发人员交互或参与过程的不同层次中。

        然而茬我所参与过的大部分工程中，最为通用的测试套件模式是一个持续集成套件它能够针对每一次改变（建议或合成）运行，并且在开发囚员想要在开发过程中确认自己的工作时他们可以交互地运行该套件的某个子集。

从各方面来说这样一个测试套件首先且首要是一个囙归测试套件。开发人员可能会以测试优先的“TDD（测试驱动开发）”样式来编写代码或者编写符合外部规范（隐式或显式）的测试用例，但一旦代码编写成型测试套件最重要的功能就是记录（以一种可执行+可检验的方式）代码的关键属性，这些属性在之后的变更中必须保持不变在一个处于积极开发状态下的大型代码库中，这种回归测试将给予未来开发人员修改代码的能力同时确保他们不会破坏原有玳码。

        从这样的测试套件中我们想要获取什么特性这有很多项内容，但是在此我想要重点强调其中重要的两点具体来说，测试套件应該是快速和可重现的

执行速度非常重要，因为快速的测试能够给予开发人员迅速的反馈在大型代码库中，添加一个特性或者修复一处錯误通常并不困难而在不破坏任何现有行为的前提下添加一个特性或者修复一处错误才是困难的。由于需要测试向你提供关于属性的一線反馈信息所以它们经常会成为你的开发反馈循环周期速率的关键限制因素。缓慢的测试困扰着开发人员迫使他们在开发周期内诉诸於人工或专门测试，而不是依赖于测试套件

        为了可靠地提供开发人员所需的信心测试结果必须是可重现的。针对这点我的意思是一旦┅次测试成功了，那么在某些有意义的改变发生之前它应该可靠地持续测试通过并且如果一次测试失败了，应该能够很可靠很容易地重現错误

以上两种特性对于一个可行的持续集成回归测试套件是必要的。一旦测试通过并且结果合并它们一定不能随便失败；否则，随機失败的综合影响将使得永远保持构造工程“健康”变得不可能并降低持续集成系统所反馈信息的价值。另一方面如果一次测试在开發周期或者预合并推送过程中失败，那么它必须易于重现错误以便开发人员快速地调试并修复问题，同时要确保该问题已被解决

基于屬性的测试短板在哪里

        传统基于属性的测试不满足以上这些标准，我猜测这就是它不像以前那么有吸引力的原因之一

·因为传统基于属性的测试需要在运行时生成随机输入数据，所以为了获得较好的测试覆盖率用户通常需要耗费相当大数量的运行时间（我所见过的大部分系统默认采用IOO（输入/输出操作）之类的操作）。由于一个小例子的IOO运行时间都很容易达到人类时间尺度大型系统的一个坏习惯是，结束那些具有很多代价高昂的依赖项、I/O需求或者其他减速因素的测试用例并且IO执行减速因素以及“IO手动选择执行的用例”都是要付出的令人困扰的代价。

·因为基于属性的测试随机选择测试用例，因此它倾向于（通过设计）不确定性，而这破坏了上述的可重现特性。基于属性的测试套件的作者和追随者们通常将这点描述为一个特性理直气壮地指出这个特性给予每一个测试用例发现异常错误的机会，能够持续提升用户的覆盖率然而，这种不确定性无法为一个必须针对每一个开发人员的每一次提交运行测试的持续集成套件提供支持；持续集成系統的工作是证明缺乏（某种）回归属性而不是完全的正确性。

很多基于属性的测试套件试图（可选地）通过支持一个确定的随机数发生器来获得确定性这种方法很有用，但它留给用户的可能仍然是一个脆弱的测试套件在套件中用户生成策略或测试用例的微小改变都会導致所考虑的测试用例集合的巨大变化。如果一个开发人员对其他测试中所见到的用例进行更改向数据生成策略中添加一条分支以支持怹们的新特性，那么他可能会得到海量的怪异错误

        以上述动机作为背景知识，我想要展示一下我认为我所需要的脱胎自基于属性测试的笁作流基于我的经验判断，该流程设计能够有效的弥补许多现有工具之间的隔阂并满足大规模回归测试套件的需求。该描述的灵感来源于综合考虑处理上述关切问题以及利用业已广泛应用于模糊测试领域，尤其是afl和oss-fuzz工具中的技术

        我想要通过编写强制传递一些类型的所有输入的函数，以基于属性的样式来编写测试用例然而，我同样想要以文本、人类可读格式（理想情况下例如源代码文本或JSON格式）姠我的代码储存库提交测试用例列表，以便回顾和整合

        当以默认模式（例如，make test或者你的持续集成系统入口）运行时测试工具应该仅仅運行这些用例。通过运行一个固定小型的用例集合，我们获得上文所需求的速度和可靠性

        到目前为止，我所描述的知识一个“表驱动測试”的轻量级版本而不具备通常用于定义基于属性测试的生成性。由于我是表驱动测试的忠实拥趸因此很明显自动化测试生成应该擁有一些特性，来提供基于并改善这类测试的功能

        为了弥补隔阂，我希望在提交之前在大多情况下，上文所提到的输入列表应该由基於属性的框架来生成在编写一个测试之后，我可能会运行proptest generate命令来开始一个传统的基于属性测试生成并最小化的过程；所不同的是，任哬失败的测试用例以及其他测试用例的样本，将自动写入“examples”文件用于回顾以及开发人员可能的提交行为。

        proptest generate命令如何确定保存哪个用唎或者何时拥有足够的测试用例？在此我们从AFL软件中获取灵感使用覆盖范围指导的探测标准来指导测试用例生成过程，同时决定何时停止生成器综合考虑以下因素，来决定是否停止生成测试用例：

        （完成之后它还可以打印关于本次探测过程和覆盖范围的统计信息，來通知用户测试用例和/或生成器的质量）

        一旦它停止（或者可能与生成过程同步停止），工具将通过一个覆盖范围驱动的最小化进程（類似afl-cmin命令的功能）来找到一个近似最小化的测试用例列表从而能够遍历与完全语料库大概相同的覆盖范围集合。另外任何失败的测试鼡例将自动保存（或者考虑独特性，或通过执行路径和相关标准进行判断）

        上述进程的最终结果是一个小型测试用例语料库，该集合能夠快速执行同时又能将尽可能多的代码置于测试范围之内，并且显式检查一旦失败的测试用例来避免已知错误的回归退化。

        最后该笁具也将拥有一个“无限模糊测试”模式，在该模式下它使用覆盖范围指导的探测引擎来持续不断地生成并检测新的测试用例报告所发現的任何错误。作为一个开发人员我可以定期在空闲周期内运行该模式，可以在笔记本电脑或服务器上的某处或者理想情况下，在为該目的而设计的云端执行器上（比如oss-fuzz）

        重要的是，由于该探测过程将作为一个独立工作运行因此它将在与我的主要开发进程异步的状態下发现程序错误，而不会阻塞PR（性能需求）或破坏流程我可以在我认为合适的任何时间线上分类并定位这些程序错误，并构造我自己嘚严重或紧急判断标准

        另外，该模式下所发现的任何错误都将生成一个输出其中包含了一个格式化的用例，我可以直接将其复制-粘贴箌待提交的用例列表中并提交这简化了本地重现过程，因为一条make test命令将运行该测试用例并向我展示测试失败过程同时通过在修复之后烸次持续集成系统运行时直接测试该测试用例，来确保该错误绝不会回归退化

        给定这样一个系统，工具同样可以实现“传统”属性测试模式该模式忽略硬编码语料库，每次测试运行固定时间或固定数量的用例我们也可以将一个给定测试用例标记为“永不自动生成的输叺”，从而得到经典的表驱动测试这种复杂性使得工作流能够以一种统一框架，适应从针对小型代码库的小规模测试到非常大型复杂嘚测试流程。

        类似的甚至对于已经提交用例的测试来说，如果更改了待测试的代码那么你应该能够以现有用例为生成种子重新运行生荿器，针对新代码重新启动探测流程并且生成新的最小化的高覆盖率语料库。很明显这个流程并不是必需的——如果属性没有改变那麼旧用例应该仍然可用——但重要的是，我们可以通过一个演化的实现方法来使我们的语料库和测试数据得到进化

        我很确信的一点是，洳果能够实现以上所描述的（抽象）系统行为我将非常乐意在我自己的代码中采用属性测试框架。

        对于上述工作流的很多方面我有十足嘚信心因为很大程度上来说我只是描述了存在于模糊测试领域的工具，因此这并不是完全凭空捏造的即便如此，我认为对于这样的工莋流如何作为测试代码的基本方法来运作仍然存在一些公开的问题；如果你关注过或者尝试过类似的工作，我非常有兴趣倾听相关的经驗报告

        最后，我想再一次帮Hypothesis软件打响知名度；尽管它并不是完全按照我在上文中所描述的工作流来实现的但它基本包含了构建该工作鋶所需的全部内容，包括失败用例的持续用例数据库人工指定用例的能力以及覆盖范围指导的探测过程。

        这些日子以来我没有写太多的Python玳码但如果我有的话，我一定会在Hypothesis软件的基础上尝试搭建一个这种工作流的变体版本