喜欢玩游戏应该找什么工作？
那能找的工作就太多了，不过作为一名游戏测试人员，我肯定就只介绍游戏测试。
并且，你玩的游戏越多，对游戏了解越深，越爱钻研游戏的特性，这个行业就越适合你。
网上有很多游戏测试的入门教程，但是经我观察，感觉这些不像是入门，更像是大神进阶之路。
这篇文章按照我的理解来写一写游戏测试入门所需要的最简单技能，东西不多，毕竟入门~
什么是游戏测试？游戏测试的职责是什么？
字面意思，对游戏进行测试。
游戏测试的职责，简单来讲，就是找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”，代表的是版本号，需求通常是由测试组长分配给组员，遇到版本更迭的时候，他可能会分配错（有时候会出现标题一样但是版本号不一样的情况，把不需要你现在测的版本需求分配给了你）。所以拿到需求的时候需要检查，有问题及时询问。
后面的“表情包优化”自然就是标题了，告诉你这个需求是做什么的。
第一条——头像换成黑人小哥：那你就只需要看头像是不是黑人小哥就行了，动作什么的如果需求没写，那你就要看合不合理，有问题及时问策划。
第二条——文字改成白字：同样的，你只需要看文字是不是白色的就行了。当然保险起见，遇到奇怪的地方还是需要问问策划，比如文字虽然都是白字了，但是怎么全写的“猪猪猪猪猪”？
至于这个需求的策划是谁，通常有两个方法来看。
第一当然就是问组长了。
第二就是看该需求是谁验收的，通常需求在研发后，都需要策划先验收，验收结束再转测，交给你去测试。
当你发现测试的结果有问题时，及时询问，该提bug提bug，该让策划修改需求文档就修改需求文档。
如果测试结果没问题，那么就点“完成”——当然，依旧是不同的公司不同的规定。有的需要你先跟组长汇报，或者再次询问策划等等。至于用例，不需要去查什么定义，举两个例子你就明白了。
通常来讲——前置条件、步骤、期望结果——这三个是必须要有的，其它的都只看公司要求，例如有的还需要id什么的。
前置条件，就是你要做这个步骤的前置条件。例如你要点击装备，你不在背包界面怎么行，背包里没装备怎么行？
步骤，就是你需要做的操作，也就是你要检查什么。
期望结果，就是你做了这个步骤后，它应该的表现是怎样的。
当然，期望结果不符合，有时候也不一定是bug，可能是策划悄悄改了需求还没来得及告诉你。这种时候，要不要提bug，就需要视情况断判了（别太担心，工作一段时间你自然就会判断了，实在不知道怎么办就发群里问）。不过在找工作之前，还是建议各位自己尝试写一写用例，这种东西就是看起来简单，但是一上手却可能会出一大堆问题。
另外，说一说测试最重要的东西——认真、仔细、注意细节！
同样是看起来最简单的东西，但是恕我直言，新人基本上没人能做到— —！
读完这篇文章，你们能发现我有几个地方把字写反了吗？