自动化在游戏测试领域中的水土不服

冒着被喷的风险,笔者尝试着回答一个问题,即为什么在传统软件测试中大行其道的自动化测试会在游戏测试领域中出现水土不服呢?笔者并不反对自动化测试,甚至非常支持,也进行过一点点尝试。笔者只是认为大规模的自动化测试并不适用于游戏测试领域。

在正式开始之前,笔者继续给诸君讲述一个真实的小故事。笔者的一个大学同学移民澳洲了,在一次他回国后的同学聚会中,他跟笔者说在澳洲看到了一台特牛x的设备,这个设备可以自动的把废旧的电缆剥开,从而获取其中的铜线,效率非常高,问问笔者是否国内有需求,如果有可以引进到国内。当时我默默一笑,说这设备确实好,高效环保,但是不适合当前国情,估计没人会买,国内的做法是直接雇几个农闲时的村民,拿小刀直接割开电缆的外皮。方法土效率低,但是成本非常低。对比高端的自动化设备,大家觉得老板们会选哪种呢?要知道一台设备的成本可不仅仅是设备本身,还有后期的保养、维修、用电等等。

有时候我们看问题还得跳出问题本身,寻求问题的根源,一件事物在当前阶段的存在必然有其内在的因素或不得已。

好,扯远了,我们回到开篇的问题,到底有哪些因素促使自动化测试在游戏行业(不仅是国内,包含欧美大厂)出现水土不服呢?笔者结合自身在传统软件与游戏行业的亲身经验,来跟大家一起分析一下。

一、成本问题

首先我们来谈一谈钱这个很俗的事,一个团队要不要做自动化测试,首先要考虑的可能不是技术方案而是我们可以投放到质量上的钱有多少。成本主要来源于2各方面,一是自动化测试工程师的人力成本,二是实现自动化测试开发和维护的时间成本。这两方面的成本都会最终折算成钱体现在项目总成本上。

一名自动化测试工程师的人力成本基本上等价于2-4名普通的黑盒测试工程师,而在游戏项目中,黑盒测试工程师是不可或缺的(至于原因,我们下面再讲),也就是说自动化测试工程师是额外投入的成本。投入的少,基本不起作用,投入的多,项目成本能不能扛得住也是个问题,尤其是对很多创业团队而言。

另一个层面,自动化脚本的开发需要与程序和策划有深度交互,这种深度交互会耗费其他人员非常多的时间,从而影响了其他人的工作进度,进而影响整个项目的进度。这一点是经常容易被忽视的一个成本。

二、游戏的感官特征

游戏是感官性非常高的一类软件,与视觉,听觉,感觉有直接关系,这点与传统软件差别较大。测试过程中需要人去直观的去体验,比如图标位置,音频是否合适,关卡玩起来是不是流畅等等,这些是自动化测试无法替代的,也是上面说的黑盒测试在游戏项目中不可或缺的原因。

三、迭代速度

游戏的迭代速度相比传统软件要更加快速,尤其是手游行业。一周一个甚至几个版本都是正常现象。在这种迭代速度下,自动化测试显然很难跟得上项目进度,很有可能一个功能已经上线了,自动化脚本开发还没有完成。面对这种时间上的不匹配,很多事情变成然并卵了,自动化测试的作用也就相对被拉低了。

四、需求变更速度

在游戏行业,需求变更的频度远远超过传统软件行业。原因有很多,列举几点:一是市场变化太快,二是很多设计需要反反复复的验证才能确定哪种体验更好一些,三是移动互联网时代产品与用户的反馈时间被缩短,四是游戏功能之间的耦合度非常高,开发过程中某些功能的设计会导致其他功能变的不再适用,必须进行重新设计。

那么问题来了,需求变更如此频繁,自动化测试怎么适应?可能昨天写的脚本,今天发现就全废了。目前笔者还没想到很好的解决方案,欢迎大家一起探讨。

结合上面的几点,笔者并不认为全面的大规模的自动化测试适用于游戏测试领域,尤其是手游领域。可能小规模或局部自动化测试还值得尝试一下,比如服务端的自动化测试(服务端变更相对不频繁,与人为感官联系不大,逻辑性代码较多)。

自动化测试是一剂很好的方药,对某些病症有很好的疗效,但不能被看作是包治百病的大力丸,吃错了,也会死人的。



留言

  1. #1

    sfsfdsfsd(2017-10-28 15:43:04)

    d是丰盛的丰盛的的时候丰盛的发

  2. #2

    sfsfdsfsd(2017-10-28 15:42:56)

    fdsfdsf发的是非得失丰盛的是方式发的