《我的世界》首席软件架构师分享自动化测试的经验心得

导语：如今大部分游戏都是网络游戏，或者更确切的说，是服务型游戏（GaaS）。这些游戏的更新频率更高，仅靠人工测试效率越来越低下，越来越耗时，而且成本越来越高。很多工作室都在尝试自动化测试，但往往发现创造快速、可靠并且真正有价值的自动化测试，是一场看

　　如今大部分游戏都是网络游戏，或者更确切的说，是服务型游戏（GaaS）。这些游戏的更新频率更高，仅靠人工测试效率越来越低下，越来越耗时，而且成本越来越高。很多工作室都在尝试自动化测试，但往往发现创造快速、可靠并且真正有价值的自动化测试，是一场看不到结束的艰难战斗。
 
　　在此前的GDC大会上，微软旗下Mojang工作室首席软件架构师Henry Golding分享了《我的世界》自动化测试的经验和技巧，他还曾是《盗贼之海》自动化测试负责人。
 
　　以下是Gamelook听译的完整内容：
 
　　Henry Golding：
 
 
　　我是来自Mojang工作室的Henry Golding，我们将要分享的是，当尝试用《盗贼之海》同样的方法测试《我的世界》时，我们学到了什么。我会尝试总结一些方法和技巧，希望能够对其他项目的自动测试也能带来帮助。
 
　　我从事游戏行业已经12年了，过往的经验基本上平均分布于玩法、程序和自动测试三个领域。我参与过多个项目的研发，和今天相关的是曾经在《盗贼之海》项目带领自动测试框架团队，目前在《我的世界》团队担任同样的职位。
 
　　为何要做自动化测试？
 
　　在我从业期间，我们发布游戏的方式发生了很大的变化：刚开始的时候，我们把游戏写到一张磁盘上就结束了，后续还可以发布补丁、DLC。整个游戏行业趋势转向了GaaS，游戏发布更新越来越频繁，《盗贼之海》与《我的世界》都是很好的案例。
 
 
　　行业趋势向服务转变带来了很大的问题，自动测试变得至关重要，游戏已经大到不可能人工测试了。我们过去曾经只依赖于人工测试，当你只想做一两次测试的时候，代价可能是有些昂贵的，但当你经常发布更新的时候，就需要不断地支付这个费用，测试成本就会大到难以承受。
 
　　对于《盗贼之海》和《我的世界》这样的即兴玩法沙盒游戏来说，很难在有信心发布的同时做到比较高的测试性价比，所以很多工作室都在寻找另一个方式。
 
 
　　在《盗贼之海》这个项目上，我们解决这个问题的方法就是采用持续交付，在2018年的GDC大会上，Jafar Soltani讲述了这个方法，以及我们通过它得到的帮助。基本上来说，持续交付就是能够在任何你想要的时候发布内容，因为你总能将代码保持在稳定状态。当然，这件事说起来容易做起来难，但你可以想象，自动测试是持续交付的基础，因为它可以让你的代码维持在稳定状态。
 
　　自动化测试是《盗贼之海》项目研发很重要的一部分，我们知道，为了实现持续交付，我们需要以快速可靠的方式验证游戏，所以我们打造每个功能都要证明它们是行之有效的，2019年的时候，Robert Masella专门就这个问题做了一次演讲。可能有人记得这次演讲，因为在GDC历史上，首次有人把玩法用函数形式写出来。
 
 
　　自动化测试很重要的一个功能，就是谁来写测试，那就是让游戏开发者来写测试代码，包括玩法代码，我觉得这是最有效率的方法。在软件行业，这基本上也是所有领域的标准做法，而且开发者也可以对给玩家带来高品质体验投入热情，当有了对的工具和训练，我们实际上可以将它做的非常好。
 
 
　　《盗贼之海》与《我的世界》是有些共同点的，但也有些关键的差异。对于《盗贼之海》，我们可以完全从头开始，游戏是从一个小团队开始研发的，所以我们可以从一开始写代码的时候就保证它能用来测试。《我的世界》是一款十多年的老游戏，它的代码并不是为了测试而设计的，然而我们始终都有数百名开发者对其做出改变。
 
 
　　然而它们也有些相似性，由于开放世界属性，两款游戏都很难讲明白，而且两者都频繁发布更新内容，所以都很适合持续内容交付。刚开始的时候，两个团队都不熟悉自动化测试，所以我们可以开始就在两个团队都形成一个文化。
 
　　目标：让开发者写测试
 
 
　　假设我们都对持续内容交付很感兴趣，并且希望我们的开发者们写出快速、可靠的自动化测试成为他们日常工作的一部分，在他们写代码的时候，就能快速找到bug所在。那么，我们该怎么做到呢？
 
　　这是很有挑战性的，我见过这样的尝试失败，也见过成功的，不过，我们在《盗贼之海》和《我的世界》都做成了，接下来我就说一些在两个项目上都有用的主题和方法。
 
　　《我的世界》自动化测试技巧
 
 
　　简短来说，它们分别是：让一个小团队负责过渡、满足代码库的需求、偏重采用，然后规模化、让开发者作为合作伙伴一样参与其中，以及从领导层得到对应的支持。
 
　　1、安排团队负责过渡
 
 
　　采取自动化测试通常试一次新奇未知的冒险，当我们不适应这种方式的时候，需要克服许多的障碍，需要有人来带来这种文化上的改变。需要有专门的团队写专门的工具或框架，教开发者们使用，以及持续提供的支持并打造社区，任何一种情况下，两三人的团队就已经够用了。
 
　　为了给下一个方法打下基础，我们来探索写测试的一些不同方式。我注意到，作为开发者，当我们开始思考自动化测试的时候（包括我也不例外），都倾向于以玩家角度进行测试。这是非常自然的现象，因为传统意义上，我们就是通过自己亲身体验来测试游戏的，因此在设计自动化测试的时候，我们很容易参考人工测试的方法。
 
 
　　对于这些测试，我们给出了很多种名字，功能测试、集成测试、端到端测试，这是很常见的测试起点，《我的世界》最初也是这么测试的。尽管这样的测试有成熟的框架，但通常情况下，这些测试往往很慢，而且不可靠、很难规模化。
 
　　由于测试需要加载游戏，所以我们需要等待一些时间才能开始游戏测试，通常是需要数十秒或者更久。之所以说测试结果不可靠，是因为同时加载了太多与我们测试目的不相关的代码，但有很多bug会导致我们的测试失败，因此，你很难确切地知道某次测试为什么失败，实际上，我们的测试方法是有问题的。
 
　　这些测试写起来也会很难，由于我们需要用间接的方式搞定测试。比如，如果我们想要在游戏世界里测试（武器的）格挡功能，就需要把它放到玩家背包、让玩家装备它，盯着特定方向，然后使用格挡。假如我们只是想要测试格挡，就不必要地加载了背包和玩家相关的很多代码，这就导致在测试格挡功能的时候有很多因素会导致失败。
 
 
　　作为程序员，我们很幸运地可以对单个物品进行测试，我们必须要像人工测试那样通关整个游戏，而是可以调用一个函数进行单元测试。单元测试主要是对特定一批代码进行测试，这批代码是与游戏的其他部分隔离开的，这是测试策略很基础的部分。
 
　　单元测试速度很快，因为不需要处理大量不相关的代码，所以每次测试可能只需要几毫秒；它们也非常可靠，因为它只会执行我们真正在测试的代码。这种方法也很容易写，不仅是因为设置起来更容易，还因为我们可以直接调用需要测试的代码，所以我们非常熟悉API，因为我们已经写好了。
 
　　然而，当写代码的时候就考虑测试，那么做单元测试就会有些困难，因为这通常需要重构引擎级的代码。即使我们写了引擎代码、也愿意进行修改，如果没有开始的测试，就可能会带来bug，所以我们经常会发现重构代码来进行单元测试太过于冒险。所有这些都让单元测试几乎是不可能的，至少是大部分游戏代码都不太可行。
 
　　
　　所以，《我的世界》当中测试也是一样，即使我们加入了功能测试框架和单元测试框架，我们想要将它写到任何测试当中使用也是有困难的。这里举一个单元测试有关的架构问题：
 
　　假设我想要测试一个组件的方法，要创造组件就需要有Actor，这就需要有一个关卡，而想要做一个关卡，就需要主游戏类，而这太大而且太复杂，只有通过运行游戏才能得到，因此我无法对组件进行单元测试。