首先说明，测试包括很多领域，这次谈测试的未来，我只谈移动互联网测试的未来。这些年我和很多公司的同学都做过交流，经过了长时间的交流，基本上对现状有一个清楚的了解，这里大胆的对未来进行一个预测。 
　　另外我还想说，测试行业还是一个不成熟的行业，学术界和工业界都存在着大量看不清客观事实的人，同样的也存在大量的扯淡的人，本篇文章希望大家都能够认清楚现在的局势，以便更好的认清方向去学习，从而将行业整体推向一个正确的道路上。
　　过去：从极易到极难
　　要预测未来，我们首先必须对过去和现状有一个清晰的了解，所以，下面首先介绍一下移动测试过去是什么样的。
　　我自己是从09年底开始接触Android无线应用的功能测试，那么从那个时间开始说起吧。
　　09年到11年底属于移动互联网测试在中国的第一个阶段，那个阶段几乎网络上除了Android、iOS的官方文档，不存在其它任何相关的测试技术博客或者文档，这对当初接触这个行业的我们是一个非常大的挑战。
　　对于一个未知的领域，为了保证产品质量，测试必然是从功能方面切入进行。不过好在那个时期的App大多都是纯Native的逻辑，并不像现在那么的复杂。但由于开发整体技术的不成熟以及硬件上不充分的支持，我们常见的其实是OOM（Out Of Memory），那个时期真的算是习以为常了。
　　09年到11年的时候，整个行业的大部分互联网公司都感觉到了移动互联网的到来，这个时候，很多大企业也觉得应该开始储备移动团队和技术基础了，所以开始大范围招人。
　　初创企业招入的测试肯定是One Man One Team，一个人相当于一个团队，而大公司的话，会将自己公司内以往做服务端测试，或者Web测试经验丰富的人，拉过来做移动测试团队的leader，然后开始招兵买马。
　　但无论是哪一类公司，测试工作肯定集中在功能测试用例的设计、执行测试用例上，而且非常的累。所以当时如果你会或者说掌握Android Monkey测试以及iOS的Monkey测试的话，那么已经是神一样的人物了，很多公司会争先恐后的抢着要的。（这里我不得不提一句，我面试了那么多的人，大部分人是知道基础的命令，也不知道Monkey执行的策略包括实现，这些人不要说掌握或者熟练了。）
　　在移动互联网早期，功能测试被放在了一个很低的位置，直到现在依然没有什么一个很好的改观。
　　然后过了快2年，各个公司发现，移动互联网不如自己设想中的赚钱，反而烧钱很快。于是11年下半年部分公司开始裁员了，而首当其冲的是测试工程师。在这个阶段中，几乎所有公司都不知道自己要招什么样的人，JD（岗位描述）都会很模糊，会写上要移动互联网测试经验，但不知道具体要什么经验。整整2年处于这样一个阶段，我称之为移动测试第一阶段。
　　接着12年开始到13年底基本上又是两年，进入了第二阶段。
　　这个阶段，移动互联网的项目迭代周期也基本定型了，1～2月内一次大迭代，小版本可能每天都有。此时的公司对移动测试的要求也开始具体化——当然，中国是一个跟风严重的，比如当初BAT或者各个大公司写出来具体的测试JD，行业的其它公司纷纷开始抄袭，所以这阶段的移动测试的要求基本是从BAT和大公司出来的。
　　12年开始，行业对测试人员的招聘要求来了一个180度的转变，Robotium，Monkey，Monkeyrunner，Instrumentation，Objective-C，Java，Python等各种详细的要求接踵而来，整个12年的面试会给测试人员一个感觉———面试测试岗位比面试一个CTO岗位都要累。记得某些公司在面试测试人员之前，首先先要笔试，做各种卷子，包括软件工程，测试，算法，代码，智力题等，从我看来简直变态的可以。
　　另一方面，移动互联网的产品本身从Native开始慢慢的转变成部分Native，部分WebView。Native主要用来实现一些类似于设置、本地界面框架的功能，而WebView更多的会做一些活动界面、广告投放的功能。之后Hybrid混合式应用变成了移动互联网应用的主流实现方式。测试工作也从以往的纯功能性测试，增加到现在的自动化测试、持续集成、碎片化测试等等。移动测试的技术在这段时间也得到了非常大的进步和提升。
　　其实在这两年里，还有一个事情让所有人都感觉到非常大的变化，那是开源的测试技术越来越多。现在很多刚进入移动互联网的测试人会发现单是UI自动化测试会有几十个框架，根本不知道选什么。
　　现状：业务与工具无法兼得
　　近的一年又有了什么变化呢？
　　从我了解的情况看，各个公司的关注点慢慢从功能测试转到专项测试，又从以往单纯去做UI自动化框架的开发发展到了测试平台化，发展到了线上监控。
　　前几年，行业大部分公司都在大量招聘业务测试人员，以及所谓的自动化测试工程师。在某些大公司里，整个测试团队分成两部分—————业务团队和工具团队（这里不得不吐槽，其实实际情况是工具组的大部分所谓的测试开发工程师其实是开发，并没有太多测试的积累）。从2011年开始，百度等公司开始陆续这样去分团队工作，几年下来的确有着不错的积累，比如各个公司属于自己的框架和平台都搭建起来了，但这样的分工如双刃剑，让我来和大家说下另外一面吧。
　　第一点相信很多人心里也都知道，也是两个组总是不能非常融洽的合作，总有互相的抱怨。所谓一个巴掌拍不响，双方都存在问题：
　　? 业务方的同学抱怨工具组做的工具不落地，不能触及到业务功能测试的痛点
　　? 工具方的同学不停的输出工具，更多的从架构层代码层去改进工具，却忽略了业务的实际真正的用途
　　? 业务方和工具方的同学互相不服对方，这点很实际。业务同学大多拼体力，工具方大多拼技术，两者薪资会有一定的差别，公司的重视程度也会有一定的差异，这其中不见得一定哪方好哪方不好，得看公司。
　　? 工具组的同学难过的一点是他们大多并没有自己实际的KPI，更多的是看多少能在业务方落地，也是说KPI其实是依附于业务方，那么合作变的尤其重要，但从上面的现状我们看得出来这并非易事。
　　第二点可能很多人未必知道了。在移动互联网，工具组的同学无非做两样东西————二次开发自动化测试框架和测试平台（兼容性，自动化，监控等）。先说框架这个东西，如果仅仅是API层面的框架，那么的确能够长期有效的使用下去。但移动互联网中工具组大多做的是什么类型的框架呢？你猜对了，正是UIAutomation Framework，过程很黄很暴力，我不多说了，我们来说结果吧。结果是大多数业务方用着也不是很爽，所以不停的给工具组提需求，而工具组服务的不止一个业务方，为了KPI只能不停的去接需求，加班修改，后不仅没有满足业务方，工具组团队先跪了，原因是需求根本来不及满足，Bug也根本修不完，不停的恶性循环。
　　所以说，经过这段时间之后，行业里的公司在功能测试上基本都有了一定的积累，然后开始关注应用的性能，因为性能直接关系到用户体验。
　　同时，行业也意识到功能测试和自动化应该是测试人员的基本能力，而不是一个加分项。
　　所以到了14年，其实很少看到再有公司要招单纯的自动化测试工程师了，算有，招入进去的也会承担更多的职责。虽然我很难确认这到底是不是一个进步，但是国内测试行业之前一直很混乱，伸手党横行，大多数人属于自己根本不能自理的状态，所以从这个角度来看，整个行业的技术能力要求提升，算是一个非常不错的趋势了。关于测试行业到底有哪一些捣乱的人，可以移步测试行业感谢有你。
　　行业现状也能说明这种情况，我能够透露的是，蚂蚁金服从title上面来讲的话，已经不存在“测试工程师”了，全部是“测试开发工程师”，这其实隐约的在暗示点了什么。今年我去了360、百度、JD、OneAPM等公司，同时也和手Q、赶集等同学有了深入的交流。交流下来来看，大家也都隐约的有一种转型。