20年行业经验大佬：游戏测试发展史，如今和未来怎么做QA?

【GameLook专稿，未经授权不得转载！】

GameLook报道/游戏测试有着很长时间的历史，对游戏本身和整个行业也是非常重要的环节。测试不仅可以发现游戏致命的问题，还能在正式上线前获得社区反馈，在游戏被更多人体验之前消弭可能出现的重大失误。

那么，游戏测试是如何发展的，新时代的QA又该怎么做才能在不牺牲游戏皮质的情况下如期发布？今年的GDC大会上，两位加起来有过40多年从业经验的资深测试大佬做了题为“游戏测试20年：战壕中的生活，我们学到了什么、以及我们如何改进QA工艺？”的演讲。

图片来源：Pixabay

一位是在微软工作时间超过18年、加入美国互动艺术与科学学会（AIAS）超过20年的Chris Chamberlain，另一位则是从事QA工作19年、与大量游戏工作室合作过的Blazej Zawadzki。他们分享了他们各自的从业经验、总结的方法以及这些年来QA工艺的提升。

以下是GameLook听译的完整内容：

Chris Chamberlain：

做个简单的自我介绍，我是Chamberlain，我在1990年代末进入游戏行业，最开始是在《网络奇兵（System Shock）》开发商Looking Glass Studios，我在Redmond工作，不过不是在《网络奇兵》团队。我做了很多的Nintendo 64游戏，所以得到了很多乐趣，是从《Destruction Derby 64》开始的。

工作室关门之后，我加入了微软，当时Xbox还没有出世，我在那里做QA一直到2014年，从事过《Crimson Skies》项目，还跟日本工作室就《梦幻之星Online（Fantasy Star Online）》合作过几年。

那个时候我们公司收购了RARE，我孩童时期就很喜欢他们的游戏，所以我请求在他们一些游戏上担任测试主管。参与过《卡美奥:元素之力（Kameo: Elements of Power）》、《Kinect Sports Rivals》等等，坦白来说，这可能是我职业生涯最喜爱的8年。

然后我转移到了《战争机器（Gears of War）》项目，在《战争机器2》结尾的时候从事引擎方面的工作，我们首次为游戏部署了专门的服务器。

期间学到了很多，我们设计了整个多人游戏架构，因为它是一款非常残忍的多人游戏，因此我们想到了匹配的主意，就像是一个新手池，如果你在上一把游戏没有获胜或者长期没玩游戏，我们就会在匹配的时候把你放到这个池子中，然后就会逐渐到海洋中与鲨鱼共舞，但这给了所有人一个更好的首次用户体验。

然后是《崛起：罗马之子（Ryse：Son of Rome）》的Xbox One版本发布，随后帮助拿到白金工作室的《龙鳞化身（ScaleBound）》和《除暴战警3（Crackdown 3）》进入预制作，然后转移到了其他领域。

我加入美国互动艺术与科学学会（AIAS）超过20年了，现在服务于RPG和冒险游戏咨询组，每年他们都会给我们一些游戏来游玩和评估，然后我们把范围缩小到每个品类前五名，这是很酷的事情。接下来交给Blazej

Blazej Zawadzki：

大家好，我是Blazej，原来是波兰人，现在住在巴塞罗那。Chris的职业生涯从工作室开始并且一直做第一方游戏工作，我的职业生涯一直都是在做外包方面的事情。因此，过去19年来，我跟不同的供应商合作过。

我最近加入了一家公司，有一年半了，但在此之前，我是一个大型QA机构的创始人，因此，我跟大量不同的客户、与不同工作室的不同合作伙伴合作过，所以有机会看到了其他人是如何做这些工作的。我们学习最好的工作室，看到我们不擅长的地方，然后捕捉其中的一些想法，努力提升我们的测试、QA方式，以及怎么做才能在下一次做的更好。

这大概就是今天要说的话题，包括我们学到了什么、过去的游戏测试是怎么做的、现在我们试图走向哪里？以及，我们是否能找到一个更聪明工作、而非更刻苦工作的方式。

用数据精准预测发布日期

Chris：

这里列了很多东西，如果你在QA行业，可能会觉得，这些现在都已经是行业标准了。但在行业拓荒期，这并不是标准，我们必须搞定怎么做这些事。其中一个，也就是我工作了18年的公司的做法是，随着你走到了最终，你成为测试主管或者QA部门负责人。

我们会有一些被称之为“Go/No Go Meeting”的事情，基本上，营销在当时就是投入数百万美元，主要投放到易贝游戏、GameStop，以及Babbage’s、BestBuy和Circuit City。但他们会投入很多资金打广告，并且很大程度上开始靠瞎猜，这是很不可靠的，很多的游戏都会遇到障碍，然后游戏推迟数周、三个月、半年有时候会跳票一年。

所以，我们开始用一种数据的方式做这些事情做，我们开始在Excel里做一切事情。这是我们早期做出来的一些东西，有些工作室用，还有些不用，如今这些都已经自动化了，我比较感兴趣还有多少团队没有这么做。

通常来说，当我们还有六个月就要发布游戏，有时候是4个月，就会开始追踪发现的游戏bug，然后了解开发者们解决它们有多快、哪些已经解决、哪些还没解决。基于这些，我们可以对自己做的事情有历史数据，然后我们预测，或者可以做到半精确，例如我们预计bug数量曲线是这样的。

这只是举个例子，红线是我们预测的，蓝线是我们实际做的结果。因此，这给我们做的事情带来了数据方法。我们会跟微软工作室的负责人开会。这时候，团队会说游戏研发进展如何，我们会给一些数据，然后由Phil Spencer决定他们做的如何，随后，项目就会得到绿灯。

衡量测试员和测试效率

Blazej：

我们说的是衡量我们在哪里、要去哪里。在你开始做QA之前，始终有一些非常重要的事情需要思考：

你想如何衡量你的效率？你想怎么衡量测试员的效率？还要确保，在测试之前，就要设置这些指标。我跟很多没有预定义指标的项目合作过，人们基本是以最原始的方式做事情，就是觉得遇到问题的时候就能找到解决方案。

但是，特别重要的是，在开始之前，你就要预定义怎么衡量测试员、如何衡量测试流程，以及你的成功标准是什么？

我之所以说这些很显然的东西，是因为这些很明显，但在进入QA之前，确实很容易忽略的事情。

这是一些案例，只有这样做，你才能达到之前说的零Bug发布。如果你仍然进度落后，可以做什么才能带来改善？有很多衡量效率和进度的不同的好方法，但按照我的经验，如果不提前恰当进行定义，你就无法按照原来的预算、规划和品质标准发布游戏。

追踪性能和稳定性

Chris：

另一个就是在1990年代末的《Destruction Derby》项目追踪性能和稳定性，如怎么才能让游戏崩溃？我们玩多人模式然后将所有车撞在一起，这种方式找到了很多导致游戏崩溃的原因，但也错过了很多，而在当时，你是没办法给自己的游戏打补丁的。

后来，当我到了Xbox部门工作之后，我们有一些才华横溢的软件开发工程师和测试者，他们会写大量代码和工具，并自动测试游戏。他们的代码通常不会和游戏一起发布，但非常有用。我们创作的这些工具最终成为了Xbox平台工具，他们对工具做了一些改变和修改。不过，这成为了一件很重要的事情，这样我们就不用等到游戏发布了之后才说，在研发中没有看到这个问题，但最终它却突然出现。

因此，这就像是，例如游戏的帧率，你对游戏的目标帧率是多少？是否达到了这个目标、有没有地方帧率低？每一台主机都有内存限制，你必须为系统保留一些内存，那么，我们离内存极限还有多远？游戏是否可能崩溃？

你就可以追踪失败时间，或者说，在游戏崩溃之前你能玩多久？什么是可以被接受的？我认为很早期的时候，很多的游戏都是，你可以连续玩4小时（之后就会崩溃），然后很快是8小时、24小时、一周，这些年变得越来越好。不过，我们的老方法，可以让开发者聚焦于让游戏变得更好，提升游戏性能。

我们游玩的时候，有些时候在工作时间、有些时候在家，有些时候是在做QA测试，除非你能复制游戏崩溃的情况，否则我们都不把它算在Bug当中。当时所有人都会手动记录时间，比如有人会说，玩了24小时都没有崩溃，这是很好的。

用好社区

Blazej：

我们说了有关数据、衡量以及想做什么的话题，这是一个在QA期间以更聪明的方式处理测试方法的真实案例，并且根据这个结果来确定你要给测试的游戏提供什么支持。在我工作期间，有很多在QA测试期间利用社区的真实例子，我们从传统的内部测试员测试，转移到公众测试，这时候我们将游戏版本呈现给人们，因为这样才能显示真实环境中的游戏表现，他们在很多环境下玩游戏，使用数百种不同的硬件配置，而且有真人在真正的消费。

这个阶段还可以帮我们从社区识别一些超级用户，所以，可以将公众测试作为在特定国家打造社区的一种方式。会有很多人的参与热情很高，他们会提供大量反馈，会成为特定区域的游戏推广者。

这些人会给你提供反馈，为什么巴西的用户玩或者不玩这款游戏？原因是什么？是与游戏设计还是视觉方面有关？还是说与你的变现方式，或说你强制用户消费有关？他们会给你很有观点的反馈，把这当做在特定国家打造社区的一个好机会。当然，你需要有一个专业的社区团队才能做到。

你不能只依赖超级用户，但可以把它视为一种好方法，把它当做一种区分问题的方法，比如有些问题虽然有人报告，但可能并不是真正的问题。并不是说这可以成为一种功能，但可能找到一些对于特定市场、特定运营商、特定设备的特定用户才会发现的问题。

用多渠道数据解决问题

Chris：

这是一个使用多个来源数据解决游戏发布后问题的案例，我不会说具体的游戏名，但这是我25年职业生涯中最不喜欢的游戏之一。

到了游戏发布的时候，我应该说，游戏并没有达到发布的品质，这些问题会出现在玩家评论中，消费者们会反映。你要跟高级领导团队谈，通常来说，你有一个解决这些问题的计划，如果是主要问题，可能需要数月时间。

我们为一款发布很长时间的游戏做了新版本，在找到问题之前，我们做了所有的工作，我们有5个想要达成的主要KPI，其中四个都在发布前解决了，一个没解决的是评分。在之前的每一个游戏里，我们都已经证明，每一个版本出现之后，评分都会下滑几个月，因为我们改变了一些东西，他们需要学习新方式、新功能才能玩游戏，这让玩家会觉得愤怒，认为我们改变了他们的游戏，他们很厌恶。游戏评分会降低，但慢慢会提升，我们会打补丁并解决问题，然后游戏评分就会回来甚至会更高。

但是，当游戏真正发布之后，尽管我们做了所有的事情发现这些问题，但却被迫在六月份财年结束前发布游戏。游戏最终还是按时发布了，刚开始，大部分数据，玩家时长短期内翻倍，变现效率也有所提高，很多事情都如预料的那样。但商店评分却从4.3降到了3.1，管理层觉得很失败，他们觉得这是最糟糕的事情，而且他们不知道从何处开始，感觉天都塌了。

我们需要快速做出反应，我说，我们在社区管理团队有客户支持，我们与他们聊聊，看看收到了多少抱怨、如何将它们归属到不同领域。阅读了所有的评价之后，我指出，这个问题出现了这么多次、这个问题出现了很多次，然后我跟引擎团队开会，告诉他们出现最多的问题，有些问题出现很少，可以剔除。

比如，在最终版本发布时出现了一些重大问题，如中文版本因某些原因无法启用，这对于那个市场会很糟糕，因为之前的版本是可以支持的，这是最优先应该解决的问题，我们不要等到1.1版本再修复，而是下周就要立即解决。

所以，我们做起来制了一些表格，还有些问题，是人们抱怨升级太慢，我们的对应方式，就是看策划的意图是什么，然后把它归类成百分比，策划看到之后说，这与我们希望看到的结果很一致。这可以通过数据证明，你做的与预期一致。

这是很酷的，我们随后会通过社区管理向玩家们传递清晰的信息，告诉他们，我们听到了反馈，这是接下来的计划，这个月，我们会解决这四个Bug，到本月结束前，我们希望有一个更好的版本解决这四个问题。我们知道另外五件事，并且会在下个月解决。这会给我们一种路线图，我们是完全透明的，我认为这可以带来帮助，社区很愿意看到这样。

避免过度加班和职业倦怠

Blazej：

有关过度加班和职业倦怠的一些话题，我们都了解自己所处的行业是什么样，它是有加班文化的，所有人都经历过，所有人都加过班。当然，QA可能是游戏研发环节加班最严重的一个部门。我们受到的影响最为严重，始终有不断变化的计划，QA是食物链的最底端，我们受到计划变更的冲击始终是最大的。

在管理或者规划QA的时候，如果你是QA经理或QA总监或者是能够影响QA规划或团队组织的人，考虑一些如何避免过度加班或职业倦怠的想法，而不是单纯地在测试后期增加更多测试员，新人可能都不了解产品，他们在真正产生价值之前可能需要时间学习和熟悉。

思考如何根据地理区域构建团队，或者甚至可以将不同的QA团队分不到不同区域，因为这样你就不用把QA压力放到一个团队身上。当然，我不是说这个方法能用到所有游戏上，但如果可能，考虑如何通过增加更多区域或位置来提升生产效率，用全球化思维。当我们醒来的时候，其他人在睡觉，反之亦然。

当有人在睡觉时间的时候你能在线利用这些人手吗？或许你想在早上喝咖啡的时候就得到Bug测试或者其他测试结果，这时候就要想如何在不同地方配置团队。再次强调，这不适合所有游戏和项目，不是所有人都负担得起。不过，多个团队的结构更容易管理计划的变更。

如果要做全球化QA团队，要为你的特定条件、具体设置考虑，你的工作室分布在哪？团队分布在哪？谁在做什么事情？是否有团队在亚洲为你做美术资产？或许你有团队在南美做一些东西。

考虑谁可以在每天的哪个时间开始做QA，因为，当你起床的时候，可能有一个团队已经工作了8个小时，你刚睡醒就有一些有价值的结果可以继续做下去。这可能并不总是有价值，但通常都是行之有效的。

尝试困难和新领域

Chris：

对我来说一个很好用的方面，很多时候都会有全新领域或者非常困难的领域，很多人不愿意接受这些东西。我认为你被人注意或者超越自己最好的方法，就是接受这些挑战，成为第一个尝试这些事情的人，你可能会遇到挫折、犯一些错误。

例如在为任天堂设备做游戏的时候，你每一次都需要跟主机厂商确认，你的游戏达到了这些要求。比如之前，如果你将手柄拔掉，你的角色会受到攻击然后被击杀，现在，这样做的话，游戏会暂停，这些都是我们需要测试的TCR。

因此，这是一个全新区域，没有人知道怎么做。这个任务交给了我和另一个测试员，我们就像是这个领域的专家，因为已经测试了一段时间，然后我们告诉后来需要接触这方面的人，然后转移到核心游戏项目上。

与全球团队合作，B已经谈过了，这似乎是如今的行业标准。但在行业早期，很多人不希望和亚洲团队一起工作，因为他们在不同时区，还有些团队不想用我们的工具。因此，我们将团队分布到不同时区，同时与很多游戏合作。

我们最终找到了对这些游戏感兴趣的人，找到了不介意做晚班的开发者。我们还找到了创意的解决方法，如果有团队希望看到Excel，我们就给他们Excel表格。还好现在不用那么做了，但在可能的时候要满足团队需求，并找到创意的方法。

年龄评级是我们可以帮助解决的另一个区域，我们如今仍在帮助很多团队解决游戏评级问题。尤其是对于在不同语言市场发布的游戏，不同区域的提交标准不一样，比如你在德国需要找USK、英国和大部分欧洲市场要找PEGI，北美是ESRB，日本是CERO。

所以，了解所有这些东西、找到对的人快速有效做好评级，拿到认证、知道每一个评级机构需要什么的人是很好的。比如IARC，有些时候，如果你是数字游戏，甚至可以一次申请7种评级。因此，事情在不断好转，但这是另一个领域。

我始终都很喜欢游戏发布，因为，你是在与平台一起打造游戏，这始终是最具挑战的，我很多次都需要找到做这个主机或者软件的人，比如一些SDK，需要邀请他们才能解决一些困难的问题，并理解为什么他们以特定方式做一些事。

QA是职业、不只是工作

Blazej：

如我之前所说，我是从测试员开始的，这就是我的整个职业生涯。我一直在不断进步，从最入门级的测试员，我学会了如何QA，随着时间的推移，我积累了更多的经验，我也做了一些其他的培训，上了一些课程，投资自己成为更好的测试员，还学了一些计算机课程。

我认为对于所有管理QA团队的人来说，非常重要的是，要知道QA是一个职业，而不是仅仅是一份工作，这不只是为一些测试员进入游戏行业的入口，当然很多人是这么做的，他们通过QA进入游戏业是因为这是最容易的入门级岗位，但他们想成为策划、美术或者其他岗。

思考如何投资你的人才和团队，考虑所有可能为团队提供的职业机会，它可以是职业认证课程，但也可以是确保他们不会因为数月数年重复的测试感到厌倦。确保给他们学习新平台、新工具、新技术、开始用不同框架的机会。

因为很多人想要学习，如果他们被卡在一个位置太久，他们就很快会厌倦然后很快产生倦怠。

定期玩游戏和分析游戏

Chris：

我们每周都会给出时间让团队玩竞争对手的游戏，并且给他们微软发布或者研发的所有游戏的副本，我们甚至有一个叫做Recon的团队，他们什么都不做，只是玩我们的游戏，给出平衡性反馈、他们喜欢什么、不喜欢什么，这给产品带来了很多变化，最终受到了消费者认可。

现在这样做很难，你会有专门聚焦游戏平衡的策划，不过，如果你成为了测试主管或者测试经理，你可以倡议这么做，我们每个月都会对一些游戏投票，从五个当中选一个，在业余时间玩，然后在午餐时间讨论，我们喜欢什么、不喜欢什么？通常会有一个测试员来展示这个讨论。

所以，找到玩游戏的方式，当你在游戏行业的时候，你需要理解游戏，不要给自己找“我很忙”这样的借口。

敢于说话

Blazej：

很多人都说，QA是披萨上的凤梨，我们是守门员吗？并不是，但与此同时，我们在确保在合适时机提出警告方面起到关键的作用。我们负责确保游戏不仅满足了所有标准，比如技术上是否能运营、体验是否流畅，还要确保，游戏是否有趣？这款游戏是所有人追求的吗？

因为产品最终是要面向玩家们的，人们需要在玩的时候得到乐趣。我们测试了很多的游戏，但在生活中也玩过很多的游戏，我们有着比很多人认为更多的视角。

所以，如果你看到了任何问题，就要大胆按下红色按钮、向团队示警，如果一些问题出错，要大声说出来，确保你不害怕说话，与其他经理或者主管，或者任何能有影响的人，让他们知道问题的存在，尽早解决这些问题。这就是我们最终想说的，测试员们，要敢于说话。