转载声明：文章来源https://blog.csdn.net/ppap_/article/details/127279856

喜欢玩游戏应该找什么工作？

那能找的工作就太多了，不过作为一名游戏测试人员，我肯定就只介绍游戏测试。

并且，你玩的游戏越多，对游戏了解越深，越爱钻研游戏的特性，这个行业就越适合你。

网上有很多游戏测试的入门教程，但是经我观察，感觉这些不像是入门，更像是大神进阶之路。

这篇文章按照我的理解来写一写游戏测试入门所需要的最简单技能，东西不多，毕竟入门~

什么是游戏测试？游戏测试的职责是什么？

字面意思，对游戏进行测试。

游戏测试的职责，简单来讲，就是找bug。要确保游戏正常进行，确保游戏的表现符合需求。

不过具体情况还是要看公司，不同的公司、不同的游戏对测试的要求也不一样。例如有的游戏很看重表现，只要显示有问题就一定要修复，而像网易的“荒野行动”这样的游戏，穿模现象非常严重，但是却很少修复，因为别人不在乎这个。

游戏测试需要会什么技能

以下讲的技能，是必须要会的！没有任何一家公司会例外！

除非这家公司真的很特殊。

0.了解“版本”与“迭代”

写成第0个知识点，是因为觉得这不算个知识点，但是说不定就有人不知道。

版本：玩LOL的都听过“一代版本一代神，代代版本玩盖伦”这句话，版本是实际交付给用户的产出，也就是说，这次更新版本后，用户是能看到的。

迭代：迭代和版本不冲突，可以一起，也可以分开。迭代是固定周期的开发节奏，跟玩家没啥关系。

1.了解一个项目的部门构成

一般是由“策划-美术-程序-测试”四个部门构成。

策划负责玩法、规则、数据等（玩法和规则他们会写在需求里，数据会写在配置表里。一个配置表其实就是一个Excel表格）。

美术顾名思义。

程序就是敲代码的，功能上的问题由他们负责。

测试就是你的岗位，负责寻找bug、保证功能的完整性。

暂时先记住这些，下面第三条会解释提bug的问题。

2.版本管理工具及Unity的使用

入门级不用害怕，这两个很简单，公司都会教。但是这里不便方细讲，因为每家公司节细都不一样。

所以这里大概解释一下它们是什么东西就行了。

版本管理工具：例如SVN、GIT等，他们的作用是什么呢？——程序、策划等将他们的代码、配置表或者其它的改动放到上面，你登录后，就可以将他们对游戏的改动拉取到本地——即每次拉取，你获得的都是最新的游戏。并且当你发现一个可复现bug（即这个bug可以稳定出现）的时候，记得一定要拉取到最新，以保证测试的准确性。

Unity：unity是什么，在百度上就能查到。但是对于游戏测试来讲，他就相当于一个功能比较完善的模拟器（模拟器应该懂吧？就是可以让你在电脑上玩手机游戏的东西—.—！我这篇文章可以说是非常小白了）。但是至于Unity如何运行你们的游戏，以及Unity有什么功能，这其实也是由你们的程序设计的，每家公司都不一样。

3.bug管理工具的使用及bug提单

bug管理工具，就是用来管理bug的，这种工具也有很多，所以就不举例了。

一般的流程是：

-发现bug

-记录bug

-将bug提交给对应的负责人

-负责人解决后再转给你（转测）

-你再次测试该bug（回归bug）

-打回或通过（bug未修复好就再转给他，修复好了就通过）。

当你发现一个bug的时候，你该提给谁呢？

首先你要判断这个bug是属于“策划”、“美术”还是“程序”。

配置问题提给策划，比如需求上写点击就送999，结果你发现数值显示的“666”，说明策划配置错了，提给他，让他改；

功能问题提给程序，比如需求上写点击就送999，结果你发现数值显示的“1000”，说明程序做了四舍五入，提给他，让他改；

（为什么看起来相似的两个问题，却要提给两个不同的人呢？好好思考下~~~3~ 2 ~ 1 ~答案揭晓）

（因为999显示666，大概率是策划看错了，所以在配置的时候打错了数字。而999看错成1000的情况基本是不可能的，大概率是程序做了四舍五入，所以需要提给程序）

美术方面的问题就要提给美术了，比如你发现他给角色少画了一只手（提给美术的时候其实很少，因为表现太明显，通常还没到我们测试，他们自己就发现了）。

当然，除了“策划”、“美术”和“程序”，有些公司或者项目组在提bug的时候，也会有别的选择，例如“音频”、“运营”（运营就是邮箱、活动相关的模块）等。

4.看需求及写用例

需求和用例是比较难的。

需求由策划负责，简单的需求稍微看下就能测，而复杂的需求一般是需要写用例的。

需求一般有两种情况，一种是添加某种全新的功能，一种是将原有的某个功能进行更新。

看需求的时候需要仔细，有的需求写的并不完美，所以如果有不理解的地方可以直接问策划，让策划讲解或者补充。

需求里的图片仅供参考，不要着看游戏和图片上长得不一样就说这是bug。因为需求是先提出来的，所以图片和游戏里长得不一样是正常现象，尤其是新功能的需求，图片和游戏基本上是不可能一样的。优化单就看情况了，有时候图片和游戏是一样的，当然，主要还是看文字。

如下图所示，这是我自己编写的一个需求用来举例：

上面的“12.0”，代表的是版本号，需求通常是由测试组长分配给组员，遇到版本更迭的时候，他可能会分配错（有时候会出现标题一样但是版本号不一样的情况，把不需要你现在测的版本需求分配给了你）。所以拿到需求的时候需要检查，有问题及时询问。

后面的“表情包优化”自然就是标题了，告诉你这个需求是做什么的。

第一条——头像换成黑人小哥：那你就只需要看头像是不是黑人小哥就行了，动作什么的如果需求没写，那你就要看合不合理，有问题及时问策划。

第二条——文字改成白字：同样的，你只需要看文字是不是白色的就行了。

当然保险起见，遇到奇怪的地方还是需要问问策划，比如文字虽然都是白字了，但是怎么全写的“猪猪猪猪猪”？

至于这个需求的策划是谁，通常有两个方法来看。

第一当然就是问组长了。

第二就是看该需求是谁验收的，通常需求在研发后，都需要策划先验收（策划也叫PO，测试则叫QA），验收结束再转测，交给你去测试。

当你发现测试的结果有问题时，及时询问，该提bug提bug，该让策划修改需求文档就修改需求文档。

如果测试结果没问题，那么就点“完成”——当然，依旧是不同的公司不同的规定。有的需要你先跟组长汇报，或者再次询问策划等等。

至于用例，不需要去查什么定义，举两个例子你就明白了。

通常来讲——前置条件、步骤、期望结果——这三个是必须要有的，其它的都只看公司要求，例如有的还需要id什么的。

前置条件，就是你要做这个步骤的前置条件。例如你要点击装备，你不在背包界面怎么行，背包里没装备怎么行？

步骤，就是你需要做的操作，也就是你要检查什么。

期望结果，就是你做了这个步骤后，它应该的表现是怎样的。

当然，期望结果不符合，有时候也不一定是bug，可能是策划悄悄改了需求还没来得及告诉你。这种时候，要不要提bug，就需要视情况断判了（别太担心，工作一段时间你自然就会判断了，实在不知道怎么办就发群里问）。

不过在找工作之前，还是建议各位自己尝试写一写用例，这种东西就是看起来简单，但是一上手却可能会出一大堆问题。

另外，说一说测试最重要的东西——认真、仔细、注意细节！

同样是看起来最简单的东西，但是恕我直言，新人基本上没人能做到— —！

读完这篇文章，你们能发现我有几个地方把字写反了吗？