看了不少论坛，发现没有多少介绍游戏测试的。或许游戏测试这个职位并不受到广大群众的认可吧。但是现在已经2020年了，可以说已经是全民游戏了，每个人手机里总有一款游戏类app。作为资深游戏测试员，在这里抛砖引玉，向大家介绍一下游戏测试的基础和我的一些心得体会，请各位大神轻喷。
了解测试基础之前，我们先来看看什么是游戏测试以及游戏测试的基本技能。
什么是游戏测试
也有人觉得我们一天到晚玩游戏还能拿工资，是件美差
有人把游戏测试工程师当成游戏体验员。也有人认为我们就是GM，是游戏里的托，其实不是，游戏测试作为软件测试的一部分，它和软件测试一样，其目的就是发现软件中的缺陷，简单说就是保证游戏的质量。
那么从哪几个方面保证呢？首先就是功能，兼容，性能。其次游戏的可玩性，是否易上手，都是我们需要考虑的。我们不仅要对游戏进行测试，保证它的功能。更要对游戏提出建议，来保证它的可玩性。
游戏测试的基本技能
一款游戏，首先，它得是一款软件，所以软件测试的一些技能我们也是需要了解的（测试方法、测试用例的设计方法等等）。
1）热爱游戏，玩过游戏。
首先你得喜欢游戏，玩过较多的游戏，才能快速的上手。了解游戏的机制，以及发现游戏中不合理的地方。当然，这个不合理也仅仅是对你个人而讲。
2）有测试相关的技术
这个就不详细解释了。一个搞IT的连这都不会，也就呵呵了吧。
3）逻辑思维
有助于编写用例，进行测试工作。较强的逻辑思维，能够保证用力的覆盖率，最大程度上减少漏测。
如果只是做初级执行的话。其实有以上三点。基本就可以了。随着我们工作的深入，我们掌握的也会越来越多。
4）数据库
数据库的操作也算是基本的了。查看用户数据什么的，学会这个用起来还是蛮方便的，再也不用腆着脸去求开发了。
5）脚本语言
掌握一门语言总是好的。服务器性能什么的都会用到。我们都会有自己写脚本的那天。
6）Linux
我们终归是要要去做性能的。了解相应的Linux的知识，可以帮助我们做好性能，更能让我们看到服务器日志，一些常规的操作。报错。可以更加轻松的定位问题。
7）肯做事
这是最重要的一点。就算是才高八斗，学富五车。不做事，也是没用的。一定要肯做事，然后才是会做事。公司招人，最重要的是要你来做事。说句直白的话，前面技能要求一大堆，可是我招你进来，就是想你做事。不会的，咱可以学，公司可以培养。可是不做，就没办法了。
以上只是我的个人观点。游戏测试与基本技能说完了。我们看看现在国内游戏市场，测试的现状（大部分情况下）。
1）缺少时间
测试团队介入较晚（代理游戏介入更晚），很多都是策划和程序已经实现了游戏的大部分基础功能后才开始组织测试，编写测试用例的时间极为稀少。
解决方案：
我以为，在没有充足的时间去写用例的情况下。我们还是很有必要拆分一下测试点，做一个checklist。如果什么都没有的话，就会导致，我们重复的做无用功。没有逻辑，没有目的。
2）维护困难
网络游戏内容变动频繁，变动量大，随之而来的测试用例变动也会频繁和巨大，因此许多团队放弃制作和更新测试用例。
解决方案：
时间充足的情况下还是更新维护的要好，毕竟用例是测试开展工作的核心。现在很多团队都在走敏捷开发的路线，人手不足的情况下还是做个checklist吧。
3）急于发现Bug
测试用例需要长期制作和维护才可体现其作用，而目前大多数测试团队都急于找到Bug，当执行完一遍测试用例后发现没有多少新Bug，从而开始怠慢测试用例的制作不更新。
解决方案：
这种情况我也遇到过。切忌心急。如果没有发现BUG，就仔细阅读需求，挖掘隐藏需求。累了就去休息休息。发散一下思维。
4）缺乏专业知识
不可否认的，目前游戏测试从业人员专业知识不够丰富，对于测试用例的制作方法了解甚少。
解决方案：
这个是没办法的事。随着游戏测试人员需求量的增加，测试人员的门槛也越来越低。只能说，多做，多练，给予适当的培训。
测试准备期，怎么确定测试需要的工具和技术
1）首先，我们要提升自己的高度，以项目经理或者测试经理的角度来看这个问题。不能单纯的以测试的角度来看这个问题。如果单纯的以测试的角度看待这个问题，那么这个问题没有答案。
2）通过需求及技术的评审，来确定，测试需要的软硬件设备。包括，PC机，操作系统，所需软件，用例编写工具，BUG管理工具。
3）技术则需要测试通过与开发人员进行沟通，了解他们的开发语言。对于新人来讲，不做白盒和自动化的话，就主要了解一下实现逻辑，能够读懂代码是最好了。
4）对于新人来讲，性能不会那么快接触到。我到现在也只是初步接触到性能。服务端的性能需要写脚本去测试，客户端的性能就是查看流量，电量，CPU，内存等等，通过纵横对比的方式，来提出相应的优化方案。
关于测试的数据分析
提升自己的眼光。了解整个游戏的系统，清楚产品需求，知道开发工作情况为前提。从当前版本已知BUG，进行分析归类。通过分析BUG的分布及易发点，去了解到技术的薄弱点（易忽略点），再和相关人员进行沟通，避免出现重复性BUG。对开发也是一种技术上的提升。
关于游戏与机型的适配。
关于适配这个问题。适配机型，一般在立项的时候就会确定下来。当然也有研发完成后，在根据实际情况来确定适配机型的。那么我们再来说说，RAM ROM CPU 分辨率 这些配置对游戏的影响。分辨率，一般都是界面显示的问题，UI，特效，动画。而RAM ROM CPU，则会影响到客户端性能，比如游戏卡，崩溃。所以这就要求我们需要在不同的机型，操作系统上，进行真机测试。
当然，我们这里讲的机型适配也可以叫做兼容性。机型适配只适合手游，那么页游，端游的兼容，就需要更换不同的浏览器，不同配置的机器，不同的操作系统。进行多次，重复的测试。
功能测试（functional test）
我做了半年的测试。接触到的也就是功能测试。兼容测试。客户端的性能也做过一些。兼容，我们上面已经讲过了。接下来我们讲讲功能。
刚进公司的时候，入手测试一个游戏。那个时候，策划是没有案子的。这种情况怎么测？整天问，问产品，问项目经理，问策划。有问题就问。曾经有个同学讲，策划没案子，他都是主观的跑的。你主观的跑，你怎么知道，这个功能是否符合策划的需求呢？又要怎么确定Bug呢？所以，没有案子的情况下，我们就要多问。不要觉得烦，也不要怕别人烦。这是你的工作。
有案子就不一样了。认真的看需求。不懂得就去问。我有的时候一个案子要看一两天，才开始写用例。不要看过几次案子，就急着去写用例。一定要吃透，不仅要看到需求，更要通过需求，挖掘到隐藏需求，要看的远。看到与之交互的模块是否会有所变动。要考虑到，这个需求，是否存在漏洞，如果我是玩家，玩到这里会怎样。我们不仅要把自己当成测试，我们更是玩家。也需要和策划，和产品提出相应的合理化的建议。
当我们一切准备工作做好之后，可以和程序进行适当的沟通。这个功能，它实现的逻辑。这样有助于我们更好的开展测试工作。也能在发现Bug的时候，更准确的定位问题。
最后，就是按照用例，跑功能，进行测试了。当然，用例总会有漏掉的地方，有时候我们测试也不会完全按照用例上进行。但是，一定要保证，尽可能的覆盖。
测试用例（test case）
定义：测试用例是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求。
作用：
测试用例是为了有效的发现游戏中的缺陷而编写的包含测试目的，测试步骤，期望测试结果的特定合集。正确认识和设计测试用例可以提高游戏的品质。便于测试质量的度量，增强测试质量的可管理性。
特性：
1、最有可能发现产品缺陷的
2、不是重复的，多余的
3、一组相似测试用例中效率最高的
4、操作简单，可执行性强
依据：
1）策划文档
2）版本更新文档
3）测试计划
4）测试方案
5）个人习惯
测试用例设计原则
1、测试用例的代表性： 能够代表并覆盖各种合理的和不合理的、合法的和非法的、边界的和越界的以及极限的输入数据、操作和环境设置等。
2、测试结果的可判定性： 即测试执行结果的正确性是可判定的，每一个测试用例都应有相应的期望结果。
3、测试结果的可再现性： 即对同样的测试用例，系统的执行结果应当是相同的。
性能测试
性能测试，又分为服务器性能和客户端性能。服务器性能，我没有接触过。在这里就和大家讲讲客户端性能。
我们在手机上或者PC上，可以通过工具，或者debug看到，内存占用，耗电量，流量等。这个我们就要进行对比。
纵向对比产品之前的各种数据参数，横向对比其他的产品。这样对比，提出合理化的建议。对游戏进行优化。
数值测试
游戏，除了程序出问题，那么也就剩下策划了。我们不得不承认，做游戏，最坑的其实不是程序，是策划。需求变更，咱就不提了，一大堆的数据表。技能，装备，人物，只要是配的数据表的地方都要测试。
技能表，就要对照技能去一一测试。包括技能效果，伤害，人物特效等等。
人物，装备这些，就需要对照数据表，按照公式算。
不要嫌麻烦，这是必须的。
之前我测试过一次，140+的人物，先是算属性，之后算加成，然后逐一测试技能。看到数据表头都是大的。搞了一个周。
之上说的也都算很简单的了。只要做了，有点耐心，很快就会上手。
前面也讲了那么多。我再说一下怎样做好游戏测试吧。
1、首先的是爱好。
说心里话，刚开始，从学校出来，就是想混口饭吃，能拿到3K就行，现在做了5年，我发现我已经喜欢上了这个职业。没错，是喜欢。
2、上进心
我们不可能做一辈子的黑盒，执行。我们必须要学习，要进步。不进步，则灭亡。
3、责任心
相信无论是老板，还是上司或者你，都会喜欢一个有担当的人。敢于负责，有责任心。
4、肯做事
交给你的事，要做，不要推卸，不要拖拉。
5、会做事
肯做事之后才是会做事。那么怎么才是会做事呢？我举个例子说明一下。在公司，很多情况下会出现。做事做到一半，项目经理或者老大，交给你个东西，去测一下。这个时候，就要搞清楚，事情的轻重缓急。优先处理比较急的。不要因为他是项目经理（老大），就优先去做他给的任务。当然，如果是随手可以做的，就做一下。
6、坚持原则
一定要坚持自己的原则。存在重大问题，比如功能未实现，或者存在重大Bug（这个重大情况视具体情况而定），严重影响用户体验的。一定要坚持，不允许发版本。当然，如果是老板或者项目经理要求放绿灯。那我们就放吧。
7、永远不要主观的去做判断。
8、永远不要带着情绪去开展你的工作。
最后。我再讲一下测试的时候需要注意的点。
这个需要注意的点，视具体情况而定。我从我的切身经历出发来谈。
1）功能
功能是否实现，是最基本的了。但是也要注意，交互的模块是否有变动，是否带来了Bug。
我自己的习惯就是，优先测试本次版本更新的东西。包括修复上个版本的Bug以及本次更新。然后发版本之后会把大致的基本流程再过一下。当然，只是刚上线没多久的时候。线上版本稳定之后，我就不会每次都去跑一下流程了。就是看看交互的会产生影响的模块。
2）资源配置
我们经常会出现数值，技能，骨骼的短缺，造成的BUG。在PC上模拟测试没问题。但是在客户端就会出问题。这种情况经常出现在刚上线的项目里。就像我上面讲的，尽可能的去跑。比如上次一个项目，更新后，半个小时内，很多玩家反应会卡死。可是我们在模拟器上怎么都发现不了。用手机试过之后，发现是少了一个骨骼。
3）消耗/获得
各种资源的消耗/获得，无论对于玩家还是我们来讲，这个点都是相当重要的。
我遇到过几个问题。
后端程序的请求没有即时的推送，导致前端不会即时刷新。这就会导致，我无论消耗还是获得，我的东西看起来就感觉没有减少/增加。
数据表更换，但是拿的还是之前的旧的表，就会出现，报错或者消耗/获得的不正确。
以上的三个问题，是我经常遇到的问题。这些问题多和程序沟通，就会了解到他们容易忽略的地方。测试的时候会有所针对。
第一次经历项目上线的时候很紧张，各种担心，漏测，出问题怎么办。在这里和新人讲一下，发版本后，无论出现什么问题，有多严重。第一时间，不要去自责，先去联系相关工作人员。赶快解决问题才是最重要的。以最快的速度解决问题，给予玩家相应的补偿。最大程度上减少损失。
总之。多和策划和程序沟通。不仅仅有利于自己的工作。也可以了解到他们的不足。会使自己更快的成长。
多做，多看，多学，多问。
愿与大家共同成长。
本文转载自：https://blog.csdn.net/qq_24180827/article/details/41700983