游戏测试是在国内游戏制作行业中最容易被低估的一个职位。而从事游戏测试的人员大多没有高学历，对游戏也没有多大的热情（有热情的大多做策划去了），几乎可以说是毫无门槛，会玩游戏就行。

  游戏测试也是非常没有地位，相比于其他软件开发的测试人员，他们除了提bug外，毫无话语权，因为可替代性高，甚至有临时工这样的存在，当游戏制作到了最后阶段，临时招几个游戏测试，公司包吃住，白天其他人员负责游戏制作和修改bug，晚上他们进行测试，整理bug，供程序人员第二天来修改。

  在招聘网站上，其他职位几乎没有什么薪资上限，测试主管的月薪2到3万，似乎已经到头了，而且需求非常少，只有大规模的公司才有这种需求。

  那么游戏测试确实不重要吗？

  如果说，策划是游戏质量的上限，那么，测试就是游戏质量的下限。

  在很多游戏论坛里，尤其一些有些年代的游戏，玩家往往对那些不断出新的鸡肋功能褒贬不一，但是，修改那些恼人的bug和不良的体验确是广大玩家最大的呼声。

  在很多时候，游戏策划也负责测试的工作，但是正如让程序员自查代码一样，策划能够发现一些bug和一些与设想不一致的地方，但对自己错误的设计却无法发现。

  因此，游戏测试这个岗位是有存在的意义和不可替代性的。

  大多数游戏测试人员也是不求上进的，他们往往安于寻找bug交给程序去解决，对于其他的视而不见漠不关心。收入也是项目组垫底，更加不愿意付出给多精力在工作中，这样恶性循环就导致目前这种不重视游戏测试的环境，并且他们自己也不重视自己工作，不少会转到策划岗位。

  以上，是我在工作中的一些体会，有失偏颇，在所难免。批评也不是这篇博客的重点，本文旨在帮助游戏测试人员优化工作方式，并寻找一些工作上的突破口，获得更高的收入，在项目组中有更好的地位。
1 找bug的正确姿势
1.1 测试用例
  首先，阅读策划的文案，了解整个游戏项目的框架，分析各个模块的重要性，编写带有优先级的测试用例。和金钱挂钩的模块一定是游戏测试重点，如充值，还有赠送能够等价金钱奖励等等。另外，游戏的核心玩法、正常的登陆到进游戏流程也是优先级极高的。这样编写测试，能够让自己在之后测试中有重点和方向，每次更新时，这些测试例也是要保证测试到的，保证测试覆盖。

  另外，测试用例还会作为其他测试人员的工作计划，让后辈也能不遗漏关键点。

  一个公司或项目组的新项目基本都是基于先前项目的，游戏类型固定，大致玩法固定，所以良好的测试用例是能够像代码一样传承下来，提高工作效率，这也能成为公司的资产和底蕴。
1.2 定位错误原因
  在测试时，做好充分的记录，可以是笔记或者录屏，在bug发生时回溯问题发生的条件，并且多次尝试，确认bug触发条件，帮助程序更快定位到问题，并在bug修复之后，知道如何去复查bug。

  对程序的前后端分工有大致的概念，一般涉及到数值的bug大多是服务端的，游戏卡死崩溃是客户端的，还有更多具体的场景，测试人员应该在工作中累积相关经验，而不是总是去找客户端程序修改问题。
1.3 统筹bug解决进度
  良好的测试用例的优先级别也就对应着bug的优先级别，学会分析哪些bug是致命的，需要优先解决，哪些bug是不影响测试其他部分流程的，可以延后，哪些bug甚至不影响上线，可以忽视。而不是只要一点点小bug也马上反馈到程序那边，影响到项目整体的开发进度。

  心里对整个项目进程有一定预估，如果堆积了大量的bug没有解决，但是这些bug也没有优先到需要马上解决的时候，就要及时和负责人沟通，让他了解到虽然现在看起来进度正常，但可能之后还需要比较多的时间用于修改那些边边角角的bug。

  另外，每个人对于bug的优先级别判断是有出入的，所以，在要求穿插优先修改的bug时，也要给出相应的理由，比如，这个bug导致无法进入到游戏场景，有大块的内容无法测试到。
1.4 了解团队成员的习惯
  这点需要在一个稳定的团队中，经过长期的磨合，个人对程序也有一定的理解。比如，有些程序员总是遗忘对边界值的处理，有些总是忘记屏蔽用户快速点击按钮，有些忽略了用户两根手指同时操作的情况……

  如果能够掌握到各个程序员的这些习惯，在他们负责的功能部分，去着重测试一下他们的弱点，也能帮助他们加深印象，提高整个团队的能力。
2 进阶
2.1 先做一个玩家
  没有游戏bug只能说是一个软件的本分，也就是游戏的下限，但是如果想为团队作出更多的贡献，提高自身价值，还要从玩家的角度，更多元的角度去看待产品。这些进阶，有点向制作人的方向发展。

  对于UI，你有一些看法，可以提出来，对于玩法，你也有看法，也可以提出来，有人会觉得这算是僭越，对你的想法不屑，并抛出各种专业的词汇让你自惭形秽。这时候拿出你的游戏体验数据来，“我玩了这款产品60个小时，我总是卡在这一等级，没有继续玩的动力。” “每次停在这个UI，我总会觉得焦虑，想快点跳过去” “这个按钮放在这里，我点起来很费劲。”……

  如果说游戏制作有照搬的公式，那就没有不好玩的游戏，游戏是一个艺术产品，而不仅仅是一个软件产品，至少在目前，是无法量化游戏的。
2.2 沟通
  另外，注意沟通的语气和用词，因为不管如何，策划美术程序是游戏的创造者，是他们一笔一画，一行行代码实现出来的，他们也是希望产品成功的，但是每个人有各自的理解。

  在沟通时要先肯定他们的付出，再小心翼翼地抛出自己的看法。比如，我作为程序，如果测试一上来就说这里有‘bug’，我心里一定很难受，仿佛是说我水平真差，还能写出这样的bug，但是我精心设计的巧妙结构，却没有得到肯定。还有一些程序，他们年轻经验不足，往往因为一点小小的纰漏，但看起来是个很大的问题，导致大家对他们的技术产生怀疑，个人信心受挫。

  不良的沟通的方式会导致制作人员和测试人员的对立，并不断加深误解，这样的团队如何能制作好的产品出来。

  平时的日常沟通也很重要，如果生活中也能成为朋友，那么工作效率也能事半功倍。
2.3 自学
  有效的沟通能够让程序更愿意解决你提出的bug，策划更愿意花时间倾听你的看法。但是，如果要获得其他人尊重，那一定也要自身能力过硬，如果能很好完成找到bug，大家会认可你是个不错的测试，但如果你对游戏设计、心理学方面也有不错的基础，那么，大家会对你的学识感到惊讶，而这部分工作也和制作人的工作所去不远了。

  多看一些游戏设计的书也能帮你和策划更好的沟通，甚至超过他的认知，对你佩服不已。程序和美术相关的书也可以看一些理论归纳类、和游戏沾边的。

  玩其他公司的游戏时，也要从一个游戏测试的角度去看那些优秀产品是如何处理问题，有哪些在自己原本看来属于bug，但是他们并没有去解决也没什么问题。

  总之，付出总会有回报，提升自己，才有底气得到的更多。

了解最基本的知识，帮助融入行业。
        从2014年的软考结束后，正式到一家创业公司里实习，岗位就是软件测试，主要是app测试，很感谢这些时间里的帮助过我的人，尤其是我的师父，他说他曾经的花名是馒头，哈哈，感谢恩师把我领进了软件测试的大门，在这期间自己也是从0开始，一步步的学习，希望我对测试的一些理解能够帮助一些迷茫的人，不对之处请指出，共同讨论，共同进步哈^_^
        1、什么是bug?
              最简单的理解就是跟需求说明书不符合的地方，这样就可以扩散了：a、没有实现需求上的功能是bug；b、将需求上的功能实现错误是bug；c、将需求上没有的功能实现了是bug，因为古语不是有句画蛇添足嘛^_^；d、没有实现即时需求上没有指明但应该达到的功能；e、功能不好用，不具有易用性。

         2、软件测试的目的？
              a、发现程序中的错误；b、预防缺陷；c、提高软件质量；d、推动项目进程。

         3、如何快速跟进一个产品？
               a、了解相关人员的职责以及联系方式，如交互设计师是谁，做什么的，联系方式是什么（有问题可以快速找到人员寻求帮助什么，确定是否是bug什么的^_^）；
               b、了解整个项目的生命周期，现公司的整个项目流程；
               c、了解之前这个软件的一些缺陷，每一版本修复了哪些bug，了解每一版本在应用商店上的更新日志；
               d、了解现在线上的软件功能，业务逻辑；
               e、了解现公司的缺陷管理工具以及用例管理工具（用例管理工具可能是不大需要了解的，可能对你的要求还没到用例上，可能没有用例管理工具）。
          4、项目周期但，需测试的功能较多，怎么解决？
               对需测试的功能做个优先等级的划分，重要的功能先测试，重点排查，但是所有的功能点都要保证正常情景是能够实现的。Bug无止尽，不要指望一一列举，全部找到。
           5、如果开发人员认定这不是bug，怎么办？
                测试人员首先确定这个是不是一个bug，认定的凭证是什么，可以根据凭证与开发人员进行沟通，看是否是需求变更，测试人员没有及时接到通知，这种情况下，可以一起与需求制定者进行确认，最终确定这个bug要不要改。
            6、没有在缺陷管理工具上提交bug，直接给开发改，如果开发告诉你这个bug已经改完了，测试人员怎么做？
                   a、要把bug描述好，记录到缺陷管理工具上，以便日后查证；
                    b、在出新的测试包的时候，这个bug需要验证，如果还是没有改对的话，提到缺陷管理工具上，还要看下跟这个bug相关的一些功能是否正确。
             7、在出每一个测试包的时候，测试人员需要做什么？
                    a、在出每一个测试包的时候，先进行冒烟测试，即对主功能的测试，对主场景的测试如果通过，再进行全面的集成测试或者系统测试，因为如果是web测试，主功能通不过，部署一个测试环境很费成本，可能整个服务器会duang掉，损失惨重；
                    b、冒烟测试通过后，之后出的测试包，先将缺陷管理上的bug先验证了，再开始重新测试，对之前的bug的相关功能进行重点测试，bug具有集群现象。
              8、测试过程中需要注意的地方？
                     a、测试环境要干净，测试环境包括了测试数据及测试的设备及操作系统、软件等；
                     b、刚开始测试的时候，测试目的要明确，知道每一步操作步骤的最终目的是验证什么；
                     c、在测试用例覆盖之后，就可以“乱晃”，不用局限于测试用例，做探索式测试，可以当做一场旅行，随心的进行测试就可以了，手工测试的目的就有了，没有一定要按部就班，作为一名用户，走自己的关键路径。
              9、提交bug时需要注意的地方？
                     a、看缺陷管理上的bug记录中有没有你将提交的bug，如果有，就不用提了，避免重复提交bug；
                     b、如果没有使用缺陷管理的管理工具，直接与开发沟通的bug，可以用excel表格，excel条理清晰，可以插入图片，bug修复后excel也可以更改状态。
              10、描述bug时需要注意的地方？
                      a、最好说明bug所属的功能模块（UI上能快速定位的描述）；
                      b、操作步骤最好是有序列号标明，如【1.xxx；2.xxx；或者a.xxx......】；
                      c、说明清楚前置条件，比如在登录情况下，用户名：test@test.test，密码：testtest，测试机信息：NO.12MI，android4.4.4，版本号：v1.1.1；或者指明未登录情况下，win8,firefox36.0.4等。有些bug是适配问题，不是每个手机都会复现，需要标明所使用的测试机型号，验证时就可以找到相对应的手机；
                       d、描述里最好是有期望值：xxx，实际值：xxx。两者不同就能进行对比。最好再附加图片，一般是截图，截图命名最好是日期+问题的关键词；
                       e、对于不好描述的bug，截图也不能解决，可直接演示给开发人员。

我的整体意见是测试岗位不会变少，反而相对于其他岗位会变的更重要一些。
首先纠正一个非常非常错误的观念。测试和测试开发是两个岗位？No，不是的。测试开发是属于测试的。
测试开发只不过是使用类似于开发的技术和能力，来达到测试的目的，本质还是测试。
就如同一个人用人肉扫地，另一个人发明了自动扫地机来扫地，看起来后面这位更高级，但是实际目的还是扫地。

其次就要说到测试的本质，以及行业对测试愚蠢的误解上来了。
我曾经前一段时间去阿里面试，测试相关问题回答良好，技术原理理解力，业务熟悉度，测试框架的设计思路，都回答良好。最后考了我两道算法题，回答的不是很好，最终说我技术不太好，offer给的不高。于是我tm就拒了，心中一万句mmp。
没想到如此大厂也是对测试误解如此深，因为他们招测试的标准就是在招研发。

就如同扫地，你扫地机器人做的再牛逼有用吗？如果你的场景是擦玻璃窗，而压根不是扫地呢？
测试的本质是，理解业务，产品和需求。傻乎乎地用研发标准招一坨长得像测试，但是实际是研发的人，就无法保障测试到位。测试是非常靠软实力的，标榜自身技术能力很好，但是半个重要bug都测不出，线上事故一坨，这样的例子见的太多了。
接下来说一下测试的进阶形态
测试有两个进阶方向，一个是理解实现原理。也就是你要明白，当前项目里面，业务需求是如何变为设计，再变为代码实现的。代码逻辑层次的耦合，数据库设计，甚至网络层如何通信，拓扑架构如何，都需要理解。注意，理解即可，不需要完全掌握。这样，任何研发行为你都可以明白其意义和风险，你就可以精确设计测试用例，不浪费自己的时间，也不会遗漏高风险场景。

另一个方向就是自动化，也就是在简化自身的重复劳动。这个虽然非常重要，但实际上现在成熟框架很多。而且测试框架其实不像研发框架，测试框架优先关注的是易懂性，易用性，交流能力，扩展便捷性。
测试人员在选择框架和使用框架时，要灵活，要贴合业务。比如他可以去思考，是否可以把一个扫地机器人改造为擦窗机器人。

最后来正经回答下问题：
1 如果你指的是业务测试外包给阿里做，那这个可以不讨论了。测试外包在十年前就有了，逐渐已经不流行了。这是因为维护一两个专职测试人员，比外包靠谱的多。自己的测试人员理解业务，外包就是瞎测，一旦换人就面临很大风险。这也说明了，测试的本质是产品。业务和需求。
2 性能测试和自动化测试是否可以外包？也不可以，但是我们确实可以有平台或者框架，来集约一下大家的知识和资源。所以最合理的模式是，阿里这样的大厂提供平台，或者开源测试框架，而其他公司的专职测试去使用。

3 测试岗位的人数确实可能会下降，不是因为提问里面的原因。而是因为：测试自动化程度变高，手工测试消失（但测试开发会变多），这是目前一个已经既成的事实；另一个原因是开发的测试意识变强，自测能力提升，运维的质量意识变强，线上测试和质量控制体系的建成，这是目前的一个趋势。
4 那么为什么我还说测试人数会变多呢？因为随着软件开发行业的体系化，运营化，质量会变的越来越重要。而测试的软实力，分析业务构建测试思路和用例，沟通作用，流程控制作用，都是更难被机器所替代的。如果说以后机器可以帮忙写代码，做项目，那么最后两个被机器代替的岗位，一个是测试，一个是产品经理。
end

上面是我收集的一些视频资源，在这个过程中帮到了我很多。如果你不想再体验一次自学时找不到资料，没人解答问题，坚持几天便放弃的感受的话，可以加入我们群【902061117】，里面有各种软件测试资源和技术讨论。


当然还有面试，面试一般分为技术面和hr面，形式的话很少有群面，少部分企业可能会有一个交叉面，不过总的来说，技术面基本就是考察你的专业技术水平的，hr面的话主要是看这个人的综合素质以及家庭情况符不符合公司要求，一般来讲，技术的话只要通过了技术面hr面基本上是没有问题（也有少数企业hr面会刷很多人）

我们主要来说技术面，技术面的话主要是考察专业技术知识和水平，上面也是我整理好的精选面试题。

加油吧，测试人！如果你需要提升规划，那就行动吧，在路上总比在起点观望的要好。事必有法，然后有成。

资源不错就给个推荐吧~

面试常问
视情况回答
1.一个优秀的测试工程师应该具备什么品质？


2.为什么想做测试相关的工作？
对测试感兴趣，性格适合（细心、耐心等），测试人员是质量的保证者，喜欢挑战。展开分析。
3.测试开发与测试的区别？
测试开发的核心职能依然是测试。只是工程师在具备测试经验、熟练使用测试工具并有一定开发能力的前提下，可以自主开发平台，或对现有开源工具进行二次开发，最终目的是提升产品测试效率。
4.怎么理解测试开发这个岗位在软件开发中的作用？
产品的用户体验是互联网行业非常重视的一个关键点，产品质量和用户体验都非常好的产品就越有竞争力也更能持久的在市场上发展下去；我觉得测试开发就是保证产品质量的重要岗位之一。测试开发岗位也需要和产品、研发、业务团队密切协作，提高产品的质量。
5.职业规划？
培养自己的思维模式，深入理解业务和客户行业知识，持续学习

1.巩固自己的测试基础知识，在基本知识扎实的情况下提高理解需求文档地能力。

2.学习自动化测试工具，并将它运用到测试中。

3.在测试技术达到一定程度后，要学会如何带领一个测试团队。

4.最终希望可以成长为可以让产品的研发线更加高效，能成为全面的测试开发工程师。能发现开发人员没有发现的问题，能想到产品人员没有想到场景，成为一个综合能力很强的测试开发工程师。
6.对于这个岗位有什么优势？
有耐心、做事有条理性、喜欢面对挑战、有信心做好每一件事情、较强的沟通能力
7.你在测试中发现了一个bug，但是开发认为这不是一个bug，你应该怎样解决？
1）首先确定自己提出的bug确实是一个bug，符合评级等

2）把自己的理由告诉开发人员，跟开发人员沟通到底是不是bug

3）站在用户的角度跟开发进行沟通

4）可以开会议，邀请项目经理、开发人员、测试人员进行会议商讨

5）换位思考以开发人员的角度思考怎么能让开发人员认可我