了解最基本的知识，帮助融入行业。
        从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面会刷很多人）

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

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

资源不错就给个推荐吧~

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

  游戏测试也是非常没有地位，相比于其他软件开发的测试人员，他们除了提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，但是他们并没有去解决也没什么问题。

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

一提到IT行业，大家首先想到的程序员，开发，编程，码农之类的词，似乎对软件测试知之甚少，甚至对软件测试工作的理解有很大的误区，作为在IT行业摸爬滚打多年的小编，和大家一起分析一下现在社会对软件测试的错误理解。
1、和开发相比，软件测试技术含量不高？
一些计算机专业的毕业生因为大学没有认真学，所以毕业找工作时大家会首选软件测试。但毕竟开发和测试是两个不同的岗位，做得了开发的不一定能做测试，做测试的也肯定做不了开发。所以两者完全没有可比性的。
前几年国内普遍存在着“重开发、轻测试”的现象，甚至在很多互联网公司里，根本就没有软件测试岗，产品上线前纯靠开发和非专业人员的内部测试，这也造成了很多产品在上线后出现各种问题，从而半路夭折的事件。
根据这些情况，开发给大家留下了技术强，地位好、薪资高的印象。因此在这种环境下，软件测试很不受重视，相关人员的地位和待遇自然也比不过开发，甚至软件测试变得可有可无。
可最近几年随着软件行业的日渐成熟，用户对产品的体验感、安全性更加关注，各大企业对产品的重视度也越来越高，软件测试变得越来越重要，相应的软件测试人员的地位和待遇也在逐渐提高。在微软、谷歌等规模比较大的公司里，软件测试人员的数量和待遇与程序员没有多大差别，优秀测试人员的待遇甚至比程序员还要高。
另外，从个招聘网站发布的缺口数据中不难发现：相比开发日趋饱和、竞争激烈的现状，软件测试仍会长期处于蓝海状态。
2、软件测试技术含量不高？
在北京顶测学完软件测试，上岗工资就能能7，8千以上，工作1年也是很容易过万，你能说它没有技术含量吗？如果没有技术含量，企业怎么可能会高薪聘用？所以这是个很现实的问题，软件测试肯定是具备一定技术含量的。
3、软件测试是在产品完成之后才需要做
一个项目的完成，基本要经历需求分析、概要设计、详细设计、软件编码、软件测试、软件发布这几个阶段。
大多数人都认为测试只是软件开发过程中的最后一步，不需要Care前面的种种工作， 其实并非如此，软件测试是一个系列过程，包括软件测试需求分析，测试计划设计，测试用例设计，执行测试等等。因此，软件测试贯穿于整个软件项目的生命周期里，对其每一个阶段都要进行不同目的和内容的测试活动，以保证各个阶段的正常使用。
4、项目上线后，如果出现问题，责任是由测试承担吗？
软件中的错误可能来自软件项目中的各个过程，软件测试只能确认软件存在的错误，不能保证软件没有新错误的出现，因为从根本上讲，软件测试不可能发现全部的错误。
从软件开发的角度来看，软件的高质量不是软件测试人员测出来的，是靠软件生命周期的各个过程中设计出来的。出现软件错误，不能简单地归结为某一个人的责任，而是应该分析软件项目的各个过程，从过程改进方面寻找产生错误的原因和改进的措施。