《重装上阵》游戏测试的那些事儿：QA工作流程介绍-网易游学-为热爱赋能

《重装上阵》游戏测试的那些事儿：QA工作流程介绍

宇恒

2022-12-1913639次浏览

9评论

38收藏

17点赞

本文字数在7700左右

篇幅较长，图文为主

内容干货金牌独家

阅读时间7-9mins

学院菌推荐指数：⭐⭐⭐⭐⭐

在开始之前，先简单介绍一下我们的游戏——《重装上阵》。《重装上阵》是一款沙盒竞技类游戏，玩家可以通过基础的部件（包括武器部件、移动部件、功能性部件等），可以组合出各种各样的载具（坦克、战机、火箭甚至高达等等）进行战斗，另外游戏里面也提供了多种玩法供大家体验。接下来网易游学特邀《重装上阵》QA宇恒，畅谈《重装上阵》游戏测试那些事儿。

由于可以自由拼装，各路大神大显身手，经常拼出还原度极高的作品，例如星战里面的飞船，动漫里面的角色等等。玩家们上传的视频也是花足心思，甚至还有人通过剪辑实现了变形金刚的变形，合体等操作，让制作组大开眼界。我们目前在各大平台都有玩家和主播在上传视频，大家有兴趣可以去看看。

游戏上线后能获得玩家的喜爱和肯定，我们自然也是十分欣慰的。但是一路走来，我们也是踩了不少的坑，碰过不少的壁的。曾经有一段时间，我们的QA同学每天都忙得不可开交，即使加班，要验收的内容仍然就像无底洞一样，即使周末抓紧时间进行休息，仍然倍感疲惫。我们的同学明明如此出色，业务已经很熟练了，测试效率也很高了，但为啥还是那么“被动”，每天都处在应付测试需求的窘境呢？

经过长久的学习、观察和思考，我才终于明白，问题其实并不在我们QA同学的测试能力和测试经验上。

测试能力的培养和锻炼当然是重要的，这里面有许多的内容，比如资源测试、系统测试、活动测试、玩法测试、赛事测试、客户端性能测试、服务端压力测试、兼容性测试、安全性测试等等。给大家介绍这些内容，大家也是喜闻乐见的，而且效果立竿见影，可以马上用得上。但是，只是提高某方面的测试能力，并不能从根本上解决问题。因为效率提升总是有限度的，测试人员即使再熟练，也只能是在测某种需求的时候，能做到比别人快、比别人细致、比别人质量更好。但是比别人快，不等于不需要时间。如果给定的时间，总是少于所需的时间，那么再老练的测试人员，也是无法保证测试质量不会下降的。

那我们怎样才能化“被动”为“主动”呢？这就需要从流程下手了。

这里先介绍一般的研发流程。

如上图所示，从设计到最终发布有五个阶段。其中，制作部分又分为UI&GUI制作、场景制作、模型制作、动画制作、特效制作、程序制作等几个部分。

1. 策划文档

这个阶段策划同学会将自己脑中的想法，转化为文档。文档里面会包含各种各样的内容，包括：界面的大致需要包含和呈现的内容，界面的交互逻辑，所需要的美术资源（如场景、模型、动作、特效等等），不同操作的提示信息，活动或者玩法的规则，数值变化的逻辑，发放的奖励等等。

2.多方会议

由于策划并不知道别人在实际实现他的想法时，会遇到哪些问题，有哪些想法其实是无法实现的，因此，需要举行一次多方参加的会议（简称多方会议），将涉及到制作的各岗位的同学都叫上，向大家说明自己的想法，顺便让实际参与制作的同学去看下制作上是否有问题。这时，一些有经验的人也会对策划的设计或者实际制作方案发表意见，最后，还会将大致的排期定下来。

经过这一环节后，不能实现的部分会被剔除，修正后的方案已经是大体可行的了。

3.制作

方案确定后，就进入了制作的环节了。这时候，各个岗位的同学会各显神通。

美术同学会根据策划文档中所需要的美术资源进行制作，场景编辑负责场景的制作，建模师负责模型的制作，动画师负责动画的制作，特效师负责特效的制作。这个部分会存在依赖的情况，比如场景和动画的制作都依赖于模型的制作完成，特效的制作也依赖于模型或者动作的完成。策划文档中的界面表现和效果，会由GUI和VX同学进行设计和制作，界面的具体交互，则由UI同学进行设计。

而音效同学，则需要根据上面的模型、动作、特效、界面，结合策划需求，再结合自己的理解进行设计和制作，在流程上依赖于上面的素材的完成，属于整个流程比较靠后，且容易被忽视的部分。

程序同学，则需要按照策划文档中的设计，将以上产出的资源正确地组织起来。当然，他不需要等待上述所有的资源都到位了才开工，一般会先用替代的资源进行开发，最后再将替换的资源换成正式的资源就好了。

在程序同学进行制作的时候，策划同学经常也要配合进行一些填表的工作，因为数值公式，投放的道具奖励都是由策划同学控制的。

4.测试

最后就来到了测试的环节了。我们QA同学会依据策划文档的内容设计测试用例，待制作完成后就会依照所设计的测试用例进行验收，如果验收不通过，则打回重做，直到所有测试用例都通过，达到外放的标准为止

5.发布

通过测试后，这个需求就可以通过发布流程外放给玩家了。玩家更新完后便能体验到这个需求的内容。至此，这个一般的研发流程就介绍完了。

看了上面的制作流程，咋一看是不是会觉得这流水线配合得还挺好的？可以看到，我们QA作为最后的把关人，责任非常重大。产品质量好不好，外放后会不会被玩家喷“买bug送游戏”，全看我们了！想到这里，一种自豪感，使命感不禁油然而生！

好了，该醒醒了！产品的质量其实与我们的测试关系没有大家想象中的那么大（原谅我来泼大家一勺冷水）。

举个简单的例子，如果一个苹果长虫了，我们作为质检员发现了，让人把虫子清理了，把创口也处理过了，那这个苹果，会从一个烂苹果，变成一个好的苹果了么？处理后就可以拿出去卖了吗？显然不可以啊！

“产品的质量，在交付到测试团队的时候，就已经确定了” —— 《软件测试的经验与教训》

产品的质量，其实在制作的过程中，就已经确定下来了。我们测试，其实只是在做锦上添花的工作。如果指望经过测试流程后，产品就会完全没有质量问题，那就是在白日做梦。如果想得到没有被虫蛀的苹果，最好的方法，不是在它被蛀后再进行处理，而是在苹果生长的过程中，就做好预防措施。这也是为什么我们要关注制作流程的原因。我们现在回头再看这个制作流程，就会发现，里面存在很多的依赖。

制作环节依赖文档设计，测试环节依赖制作。甚至制作过程中，不同岗位的工作也有依赖的存在。这个流水线的每一个地方，一旦出现了问题，轻则导致流程下游的工作时间被压缩，产品质量下降，重则直接要推倒重来，制作计划被迫延误。然而资源是有限的，多延误几次的后果，可能就是项目结项，团队解散了。这并不是在耸人听闻！

大家可能会觉得，这不是PM要做的工作么？我一个小QA，为啥还要操PM的心？

与策划同学一样，PM毕竟不是一个技术性的岗位，有些问题，有些风险，PM其实是很难发现和识别的。再说，我们的最终目标是交付高质量的产品，如果多操一点心，就能提升产品的质量，就能让我们化“被动”为“主动”，就能减轻自己的测试压力，何乐而不为呢？

我们测试工作之所以会被动，有几个方面的原因：

对所需的测试时间评估失误
根本没有测试计划，来多少测多少
上游变更太多打乱了原有的测试计划

对于第一点，属于对业务是否熟悉的问题，这个需要经验累积，这里就不探讨了；对于第二点，属于如何制定测试计划的问题；对于第三点，是属于如何避免节奏失控的问题，这里主要跟大家介绍后面两点。

1.如何制定测试计划

制定测试计划本身并不是一件很难的事情，前提是对测试时间的评估是准确的。刚才我们介绍过一般的开发流程了，那么我们应该何时开始制定测试计划呢？

答案是在多方会议后。因为在进行多方会议的时候，各岗位的制作时间基本上都能确定下来了。我们可以先按照这个时间进行排期。

制定计划的步骤如下：

第一步，首先要确认需求里面，各种资源的到位时间，程序制作完成的时间，以及要外放和正式上线的时间。这里需要注意的是，即使是同一个素材，交付时间可能会有多个（例如GUI，可能会分两次交付，先交付一个临时版本，供程序开发用，最后再交付正式的版本）。程序在进行制作的时候，也有可能是将系统划分成几个部分，分开几次来进行交付。
第二步，根据自己现有的排期，确认空余时间。
第三步，将要测试的需求放进现有的排期当中，看是否有冲突的地方，是否能在给定的外放时间之前完成测试。

接下来举个具体一点的例子。

假设已知各岗位的到位时间及测试需要的耗时如下：

程序部分，分2阶段交付，第二周周二交付第一阶段的内容，第三周周五交付第二阶段的内容。其中，第一阶段部分，测试耗时3天，第二阶段部分，测试耗时4天。
UI部分，第一周周三交付，测试耗时1天。
GUI部分，第一周周五交付，测试耗时1天。
VX部分，耗时约2周，第二周周四交付，测试耗时1天。
场景部分，耗时3周，第三周周五交付，测试耗时1天。

现在测试同学现有排期如下：

那测试计划可以如下：

第一周周四验收UI部分内容。
第二周周一验收GUI部分内容，周三开始验收程序第一阶段的内容。
第三周剩下的一天验收VX的部分。
第四周验收程序二阶段和场景的部分。

这样做了计划之后，我们发现测试时间是刚好足够的，并且前两周还有些空余。但是如果交付节点有所调整，或者因其他原因调整了开发计划，那我们的测试计划就会被打乱。

例如程序二阶段交付的内容，延迟到了第四周周三才能交付，那我们就只剩下周四周五两天进行测试了，原先需要耗时4天才能测完的内容，要在2天测完，显然测试质量就要下降了。

所以即使现在排期是没问题的，我们还是要提醒产品方，目前的安排是有风险的，需要做好调整外放计划的准备。例如原定第四周周六外放出去，如果发生延误，那么这个外放计划最好延后一周，如此我们才有充足的时间进行测试。

因为在一个月前我们就已经进行了排期，了解到了潜在的风险，并且做好了应对风险的方案，所以即便延期真的发生了，我们也不虚，不至于手忙脚乱。当然，这里细化到天了，实际工作中，也可以只细化到周，以下是我们某次春节活动和新主题玩法的排期示例：

知道了外放的时间，各方面交付的时间，我们就可以安排测试时间，并且可以看测试时间是否足够了。

这里顺便说一下，外放的时间，就是指玩家收到更新提示，需要下载新内容的时间。但是一些活动玩法，不一定是更新完就马上开启的，可能要等到具体的某一天才会开启，所以开启时间和实际外放的时间，不一定是同一天。

有了排期后，是不是就有了一种“一切尽在把握之中”的感觉呢？

如果我们不做计划，画风可能就变成这样的：

第一周，开心地划水！
第二周，开心地划水！
第三周，把之前安排的事情做完了，所有东西到位，下周可以开始测试了！
第四周，加班，加班，加班……什么？要延迟交付，要2天测完？加班，加班，加班……终于测完了，好累啊……_(:з)∠)

（外放后）产品：你们QA到底有没有认真测试的呀，玩家反馈上来的问题也太多了吧！#@￥%%#*&&@@￥￥……（QA声望值-9999999）

没有做好计划的话，不但自己无法控制测试的节奏，导致自己要累死累活地加班，而且测试质量也会下降，就容易导致外放后玩家还会遇到很多的bug，玩家对产品评价下降，测试人员在团队中的声望也会大幅下降，典型的吃力不讨好！

当然，真的出现到了第四周才发现测试时间不够的情况的话，我们还是可以向产品进行反馈，然后找PM帮忙调整计划的。但是临近外放才说要调整计划，PM就真的很想寄刀片给你了。而且此时产品对QA的靠谱程度的评价依然会下降。

2.如何防止节奏被打破

上面简单介绍了如何进行排期，是不是觉得很简单呢？

而在实际的制作过程当中，最让人讨厌，也最容易导致产品质量下降的，往往是中期甚至后期才发生的变更。我们QA，与一般的测试最大的区别，就是会全流程介入。介入全流程想要解决的，其实就是这个问题。能在前一个阶段避免和解决的问题，就不要留到下一个阶段。因为越到后面的阶段，修复一个问题的成本就越高。（引用自《代码大全》）

我们重新回到研发流程前面的3个阶段上来，看看我们能做什么。

(1) 策划阶段

在策划设计的阶段，在开始多方之前，我们会先对策划的文档进行分析。这个文档分析的环节非常重要，但是很多人都不够重视。研发过程中的一些临时需求，制作过程中发现不太对，漏了这，漏了那，都是因为在文档设计阶段考虑不充分造成的。在文档设计的时候，考虑得越周到，后续发生变更的可能性就会越小。

策划同学限于自身的经验，以及对系统实现，具体制作过程的不了解，往往是无法发现这类的问题的。通常会到实际制作的时候，才会暴露出来。

而我们QA，进行文档分析，就是要提前发现出这类的问题。至于怎么做文档分析，以后大家有机会进入公司的话，会有专门的课程进行介绍的。这里就不对具体的分析方法进行介绍了，但有几点经验供大家参考：

a.切换到程序的角度去考虑

实现这个需求所需的“材料”是不是已经齐备了？包括但不限于交互逻辑，按钮的位置，所需要的公式、数据等等。
是否涉及到现有的系统？
可能会复用哪些界面或者功能？
是否会在原有的功能上面进行扩展？
需要同步的数据是否过多切频率过高？是否会对客户端或者服务端造成压力？

对复用或者旧有功能的扩展，还有涉及多个系统的部分，需要多加注意，这些地方特别容易出现测试遗漏的情况！当然，大部分情况下，我们是没有代码权限的，所以具体的实现细节我们可能无从得知，一般来说也无需得知。在分析时只需要根据自己所了解的情况进行猜测即可，实在没把握的话，也可以咨询程序同学进行印证。

b.切换到策划的角度去考虑

策划提出的这个需求，用意何在，目标是什么？目标群体是哪些？
关卡、奖励等的设置是否合理？
用于演算的公式是否正确？
对于不同情况的考虑是否完备？有没有特殊的情况，还没有考虑到？
现在的设计是否在以后有扩展的可能？
如果以后要进行扩展，改动成本如何？
根据经验，要实现这个需求，是直接在现有的数值表上改还是需要新增一个数值表，用到哪些数据是否有说明清楚？（当然数值表的填写一般还要看程序具体实现的情况。）为了便于日后进行分析，哪些数据需要进行记录和监控？

c.切换到玩家的角度去考虑

这个设计真的能吸引到目标玩家吗？
在这个规则之下，玩家如何可以做到收益最大化？规则中是否存在漏洞导致玩可以刷奖励？
这个交互设计是否符合玩家的习惯和认知？
对于这个设计，玩家是否会有新的诉求？
这个改动对玩家来说是否造成了损失？
如果造成了损失是否有相应的补偿方案？补偿方案是否合理？

d.从我们测试人员的角度来思考

测试这个需求我们需要准备怎样的环境？
有哪些地方的测试可能需要程序或者策划同学的支持？
这个需求与我之前体验过的其他游戏中的内容，或者测过的内容是否有相似之处，是否有之前漏考虑的地方这次也漏了？
经历过这些分析之后，我们就能发现很多文档中未能确定的问题，此时我们再去参加多方，就能把这些问题都提出来并解决掉。

【惨痛教训】

在《重装上阵》中，就出现过很多设计阶段就考虑不周全导致质量下降的情况：

教训1：我们有次在主题玩法设计初期没有考虑到要为新主题单独设计一个活动，结果制作到一半的时候，才发现要做一系列的活动，制作量瞬间增加了一大部分，测试压力也直线上升。

教训2：在我们的游戏当中，不同的玩法，会有不同的车库，车库里面玩家可以组装自己的战车，但是我们对战车的承载上限做了限制。某次策划调整了模块的承载，去掉了一些之前有的模块，没有考虑到这个改动对玩家现有拼装方案的影响（策划将原先一些模块的承载改高了，导致玩家现有的车承载超过了上限，使用时就会发现这个车无法使用了，也不知道为什么），引发了玩家们的不满。

看上去都是策划经验不足的原因，但如果我们在设计的时候就提醒策划同学要做好这方面的考虑，就能避免出现上述的情况了。

(2) 多方阶段

如果文档分析已经做得相当到位的话，在这一阶段其实主要就是将之前积攒的问题逐一解决掉。

当然，也有可能在讨论过程中发现之前文档分析时的盲点，这种盲点是需要记录下来的。

另外，还有一个很重要的工作。一般多方完毕后，各岗位的制作时间都确定下来了。我们需要考虑，根据以往的经验，大家的排期是否合理，是否有预留应对变动需求或者资源延后交付的情况？

【惨痛教训】

去年11月我们进行对外测试，测试内容的多方其实很早就召开了，然而当时没有叫上音效同学，也没有人发现音效还没排期，所以最后只按美术资源的最终到位时间，来确定对外测试的时间。结果到了最后制作的时候，才发现音效已经来不及制作了。最后只好将未完成制作的音效屏蔽掉，先开启测试，然后再在测试过程中将制作好的音效补上。但对于前期的玩家来说，缺少了音效，体验肯定是不好的。

(3) 制作阶段

在这个阶段，虽然还是不需要我们进行测试，但是我们需要关注制作和提交的规范和流程。如果制作没有规范来指导，大家随意发挥，那出现返工的情况就会多很多。在《重装上阵》的测试过程中，我们就经常遇到资源因为没有按照规范来制作，等到验收的时候才发现有问题，导致反复返工造成效率低下的情况。

要避免这种情况，我们需要熟悉各种资源的制作过程还有制作规范是怎样的。包括：

UI、GUI、VX的制作流程和规范是怎样的？
游戏场景的制作流程和规范是怎样的？
游戏模型以及动作的制作流程和规范是怎样的？
特效的制作流程和规范是怎样的？
大家可能会奇怪，我们又不是美术、UI这些岗位，为啥还要了解制作的流程和规范呢？

在这个阶段，我们其实需要协助产品，对制作的过程进行监控，这样如果发现制作过程中漏做什么，或者某个地方没有符合规范，就可以马上进行调整，而不用等到正式交付测试才来发现和调整。

如果我们不知道制作的流程，没有做好监控的方案，最后其实是会耽误我们的测试进度的，因为测到一半，你发现这个东西不符合要求，没法继续测试下去了，然后已经花了的时间，也浪费了。

当然，对于制作的流程，我们只需要有大致的了解即可，不需要真的掌握实际的制作。另外，这部分的工作，将会是一个持续迭代的过程，因为流程和规范都有可能变更。对于一些经常踩点甚至延期才能交付的部分，在制作过程中也是要密切关注的。

【惨痛教训】

教训1：我们有次对短视频的界面进行迭代优化，UI同学的提交的时间比程序同学的提交早了一周，如果跟着当周的内容直接外放出去的话，会导致我们短视频的部分功能无法正常使用，幸好在外放前一天我们进行回归测试的时候发现了，那时候已经比较晚了，我们虽然立即找UI同学对提交了的内容进行回滚，但是当天的回归进度就被耽误了。如果有流程对UI同学的提交进行规范，要求一定要等程序同学提交的时候，才能将新制作的内容提交上来，就能避免这种情况。

教训2：在《重装上阵》中，有大量的模块和皮肤。然后皮肤的碰撞大小和挂接点位置都不一样，导致有些模块在应用皮肤以后，会比较难以命中，甚至能有穿墙的功能，这显然不是我们想要的。如果能在制作阶段就指定规范，要求大家将各种皮肤的碰撞和挂接点、骨骼等做到与原模型一致，或者有一套机制能确保他们一致，就能避免这种问题。

在保障产品质量这件事情上，尽管提升我们自己的测试能力很重要，但是真正决定产品质量的，其实是制作过程，由于QA可以全流程介入，我们可以在策划和制作阶段就开展工作，帮助产品提高制作时的质量，尽量减少后续的需求变动和返工的情况，如此既能降低下游戏测试的压力，也能提高产品的质量。其次，在开展测试工作之前，需要做好测试计划，定时跟进制作安排的变动情况，及早做出应对，如此才能避免自己陷入“被动”。

大家看完这篇文章，可能会觉得，哇，QA好难啊，又要懂程序，又要懂策划，又要懂玩家，又要懂测试，还要对制作流程了如指掌。感觉什么都得会啊！确实是这样的。不过，这不正是这个岗位的魅力所在吗？毕竟有挑战才有乐趣。而且能学这么多东西，这个过程，其实是很快乐的！