《我的世界》首席软件架构师分享自动化测试的6个技巧

由于测试需要加载游戏,所以我们需要等待一些时间才能开始游戏测试,通常是需要数十秒或者更久。之所以说测试结果不可靠,是因为同时加载了太多与我们测试目的不相关的代码,但有很多bug会导致我们的测试失败,因此,你很难确切地知道某次测试为什么失败,实际上,我们的测试方法是有问题的。

这些测试写起来也会很难,由于我们需要用间接的方式搞定测试。比如,如果我们想要在游戏世界里测试(武器的)格挡功能,就需要把它放到玩家背包、让玩家装备它,盯着特定方向,然后使用格挡。假如我们只是想要测试格挡,就不必要地加载了背包和玩家相关的很多代码,这就导致在测试格挡功能的时候有很多因素会导致失败。

《我的世界》首席软件架构师分享自动化测试的6个技巧

作为程序员,我们很幸运地可以对单个物品进行测试,我们必须要像人工测试那样通关整个游戏,而是可以调用一个函数进行单元测试。单元测试主要是对特定一批代码进行测试,这批代码是与游戏的其他部分隔离开的,这是测试策略很基础的部分。

单元测试速度很快,因为不需要处理大量不相关的代码,所以每次测试可能只需要几毫秒;它们也非常可靠,因为它只会执行我们真正在测试的代码。这种方法也很容易写,不仅是因为设置起来更容易,还因为我们可以直接调用需要测试的代码,所以我们非常熟悉API,因为我们已经写好了。

然而,当写代码的时候就考虑测试,那么做单元测试就会有些困难,因为这通常需要重构引擎级的代码。即使我们写了引擎代码、也愿意进行修改,如果没有开始的测试,就可能会带来bug,所以我们经常会发现重构代码来进行单元测试太过于冒险。所有这些都让单元测试几乎是不可能的,至少是大部分游戏代码都不太可行。

《我的世界》首席软件架构师分享自动化测试的6个技巧

所以,《我的世界》当中测试也是一样,即使我们加入了功能测试框架和单元测试框架,我们想要将它写到任何测试当中使用也是有困难的。这里举一个单元测试有关的架构问题:

假设我想要测试一个组件的方法,要创造组件就需要有Actor,这就需要有一个关卡,而想要做一个关卡,就需要主游戏类,而这太大而且太复杂,只有通过运行游戏才能得到,因此我无法对组件进行单元测试。

2、满足代码库要求

《我的世界》首席软件架构师分享自动化测试的6个技巧

当功能或者集成测试不理想的时候,就不可能进行单元测试,所以,我们现在就需要一些满足代码库要求的框架,并且为游戏代码解锁单元测试。

我们在《盗贼之海》和《我的世界》使用都非常成功的一个技巧,就是在单元测试和功能测试之间的“中间”测试,随后我会介绍它在两个项目中看起来是怎样的。

《我的世界》首席软件架构师分享自动化测试的6个技巧

《盗贼之海》使用的方法我们称之为Actor测试,它将引擎的可解锁或可修改部分作为首要类依赖关系。因此,如果你需要一个关卡复活一个Actor,就需要一个真正的关卡才能做到,而不是尝试模仿这个关卡。

所以,不要破坏依赖关系让它独立,相反,你需要满足依赖关系,然后写那些看起来像是单元测试的代码,这些写起来简单、可靠而且容易。

这里Robert局的例子当中,他测试的是白天的影之骷髅,正确地将其从黑暗切换到了光状态,我们可以看到,他只是用了几行同步代码就实现了这一点。他首先创造了一个影之骷髅,并且确保它是在黑暗状态,然后将游戏世界改成中午,然后通过调用光将影之骷髅设定为光状态。

通过这几个简单的调用代码,他有效地对自己的代码进行了单元测试,即使他的代码并不是与引擎分离的,所以这本质上并不是真正的单元测试。这些类型的测试很容易写,运行很快而且可靠,也是单元测试和功能测试很好的平衡,因此它们占据《盗贼之海》70%的测试也就不令人意外了。

《我的世界》首席软件架构师分享自动化测试的6个技巧

对于《我的世界》,我们通过《盗贼之海》的Actor测试借鉴灵感,创造了一种我们成为服务器测试的方法。在服务器测试中,我们通过加载平坦的游戏世界来满足引擎依赖关系,并且让测试可以触及到它。

之所以称之为服务器测试,是因为我们现在很多的测试都是运行在客户端,但有趣的事情却发生在服务器侧,但令人意外的是,它与Actor测试很像。

这个案例中,我们想让蜂巢在被标记之后不再生出蜜蜂,如Robert的案例那样,只需要几行代码就能完成。首先我们生成一个蜂巢Actor,然后直接加上标记方法,然后,我们通过直接调用Actor,让它不想再生出蜜蜂。

这种方法不受太多因素影响,而且直接调用方法,因此它不需要等待时机,也不需要主要的因素和引擎分开,因为我们提供了一个真正的关卡并复活了真实的Actor,才运行了单元测试。如果是用功能测试,就需要做更多的工作,因为我们需要找到蜜蜂、计算世界里的蜜蜂数量,然后再次计算,确保我们的蜜蜂数量不变,这不仅难写,也会需要很长时间运行,还可能有更多地方出错。

所以,就像Actor测试那样,服务器测试非常方便,我们目前在《我的世界》用的超过4000个,占据了这款游戏测试总量的35%。

如果今天一定要强调某件事,我觉得单元测试和功能测试之间的“中间测试”就是最重要的,它可以对旧代码进行测试,而且也应该可以用于任何一款游戏。目前为止,我们发现这个方法在虚幻引擎上可以使用,也能在《我的世界》引擎上运行。

3、偏重采用

《我的世界》首席软件架构师分享自动化测试的6个技巧

对于采用,我指的是持续、广泛的测试授权,所以开发者在为他们大多数的改变写代码。为少数人做少量测试写框架相当容易,但是,想要达到让每个人大部分时间都使用它,是非常有挑战性的。而且,我觉得这是任何测试框架当中,最重要也最优先的问题。

比如,在之前一个测试当中,我写了一个自己觉得很好而且很完美的框架,甚至还简单易懂。悲剧的是,没有人使用这个框架,因为在这里面写测试有太多的分歧,你需要打开一个单独的项目用两种语言写代码,然后还需要写游戏代码将功能暴露给框架,测试结果也不那么可靠。所以,我在《盗贼之海》汲取了教训,写了一个真正让人们使用的框架。

在《我的世界》项目上,我们的框架已经内置在游戏里,因此不存在那样的分歧,但依然因为其他原因存在一些分歧。因此,我们第一步就是承认这不适合我们,即便游戏里已经有一个投入努力就可以用的框架,可是并没有人真正用它来写测试。

所以,我们聚焦于写一个真正实用的框架,甚至要考虑技术债,满足开发者们的要求,让它写一个测试比不写测试更容易用,因为我们认为,帮助人们走出第一步是写测试很重要的一方面。做到这些远不只是易于测试的框架,还需要做出文化上的改变,有对的框架是很必要的。



留言