首先说明,测试包括很多领域,这次谈测试的未来,我只谈移动互联网测试的未来。这些年我和很多公司的同学都做过交流,经过了长时间的交流,基本上对现状有一个清楚的了解,这里大胆的对未来进行一个预测。 
  另外我还想说,测试行业还是一个不成熟的行业,学术界和工业界都存在着大量看不清客观事实的人,同样的也存在大量的扯淡的人,本篇文章希望大家都能够认清楚现在的局势,以便更好的认清方向去学习,从而将行业整体推向一个正确的道路上。
  过去:从极易到极难
  要预测未来,我们首先必须对过去和现状有一个清晰的了解,所以,下面首先介绍一下移动测试过去是什么样的。
  我自己是从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、赶集等同学有了深入的交流。交流下来来看,大家也都隐约的有一种转型。