移动测试人员的未来：测试开发技术的融合

首先说明，测试包括很多领域，这次谈测试的未来，我只谈移动互联网测试的未来。这些年我和很多公司的同学都做过交流，经过了长时间的交流，基本上对现状有一个清楚的了解，这里就大胆的对未来进行一个预测。

另外我还想说，测试行业还是一个不成熟的行业，学术界和工业界都存在着大量看不清客观事实的人，同样的也存在大量的扯淡的人，本篇文章希望大家都能够认清楚现在的局势，以便更好的认清方向去学习，从而将行业整体推向一个正确的道路上。

过去：从极易到极难

要预测未来，我们首先必须对过去和现状有一个清晰的了解，所以，下面首先介绍一下移动测试过去是什么样的。

我自己是从 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、赶集等同学有了深入的交流。交流下来来看，大家也都隐约的有一种转型。

未来：找出问题还不够，要定位问题

了解了移动测试的过去和现状，现在可以大胆的预测未来了，不过，这里也仅仅是未来三年内的情况。

首先，测试人员肯定是朝着全栈的方向去发展了，这点毫无疑问。而功能（业务）测试，专项测试，自动化测试等都会变成一个测试人员基本的能力，而非加分项。

而随着网商的发展，各类互联网＋金融的崛起，移动安全的测试将会变成专项测试之后的一个新的关注点。

有些人可能会担心随着第三方测试服务流行，测试工程师的前途在哪，我想说，测试这个岗位和测试这个工作在移动互联网不会消亡，但综合能力的要求提升很多，将来不会再有单纯的业务测试，也不会再有单纯的自动化测试，以后测试将全部是测试开发工程师，这些人可以快速的去适应各种需求，并且能够通过业务和技术的双向分析从而定位真正所在的问题。

测试人员自我能力的提升，也不再是单纯的某一方面技术，而是这些技术如何真正的落地，以及怎么结合自己的业务，以及产品的实现框架去排查和定位问题，最终解决问题或者优化产品性能。

与此同时，开发工程师也会慢慢的被要求承担一部分测试工作（产品自测），不仅能让开发工程师更深入的了解业务，而且本来我们就需要自己去吃自己的狗食（Dog Food）。

举个例子，随着 React Native 和 Html5 的发展，很多公司为了满足应用的需求，会开发私有的 RCT 和 WebView 容器。同时，很多业务复杂的公司的客户端，背后对接的不仅仅是一个服务，更多的是服务群。那么这个时候问题就出现了：

我们发现了一个客户端很卡，或者有某些安全的风险，那么，我们首先需要去从业务角度分析，可能是哪些业务链路上出现问题，接着我们需要去将被测产品拆开，一个一个排查和定位问题。比如

• Native Activity View 启动消耗
• RCT 转换到 Natvie 控件的消耗
• WebView 自定义容器的消耗
• Html 中的 CSS，JS，PNG 等流量和时间的消耗
• Native 业务代码调用 RPC，http 请求的方法的消耗
• 本地请求到得到返回的时间消耗
• 数据交互的 Json 结构是否复杂，json 解析的消耗
• 本地业务逻辑是否编写恰当
• 客户端在智能机上的界面绘制的消耗
• 整个架构 View 是否存在重复绘制
• 服务群中互相交互以及透传的逻辑是否恰当
• 服务群中的系统超时机制是否恰当
• 服务群中每个系统的消耗

我们会发现，其实我们并不能一下子就能够找到问题在什么地方，而是需要对业务和被测应用技术了解的情况下，去慢慢排除哪些地方没有问题，从而最终定位问题所在。此时的你光有技术，或者你光懂业务，都无法去完成这样一个工作。测试人员很大的一部分价值会体现在这个地方。

也许看到这里，很多测试同学就要跳起来了，觉得要求怎么那么高，感觉就在扯淡，肯定不是这样。我想说的是：

第一，目前测试圈很多人以为自己的圈子就是这个行业的全部，但其实测试的内涵比他们想象的要大的多。

第二，很多人被培训忽悠（什么自称 xxx 培训第一），觉得单纯的学习技术就可以提升价值，你们自己想想看，测试真的只是一个纯技术岗位吗？

第三，国内测试原本长时间存活在低要求环境中，导致很多人已经不知道正常的要求是什么了，当行业开始以正确的标准来要求的时候，就感觉无法接受。

大家只要抛弃成见，自然知道谁对谁错，也会知道应该怎么去面对未来，只要勇于承认，并且快速学习，未来的测试仍然有你的一席之地。

说到这里，很多测试管理者可能会问，管理者的出路在何方。

其实对于管理者而言，现在应该已经有所感受了，就是纯管理角色在移动互联网很难存活下去。原因有两个，其一，测试本身的技术定位要求，以及技术的更新速度会倒逼着管理者需要有一定的技术基础，包括对一些新技术有一定的了解，否则如何将合适的人安排在合适的位置上呢？又如何去服众呢？其二，未来的转变不仅仅是测试技术和业务的融合，更多的是就业人员从 85 后转变成了 90 后以及 95 后。以往很多管理者觉得给员工一些钱，一些股票，这些员工就会默默无闻的为公司卖命，为项目去加班。但是随着时代的发展，现在很多的年轻人看重事情变成：工作是否开心以及是否对自己有提升。他们不是不在乎钱，但他们会变的更有自己的想法和追求。面临这样一群人，管理者本身的管理方式也需要有一定的改变，同时需要从公司的流程，业务发展，个人规划，技术发展等各个角度去给出一些引导。

差不多以上就是我想表达的观点了，也许很多人已经看到了变化，也许很多人没有，但是无论如何，变化总在快速的，不以任何人的意志而转移的进行下去。最后，如何想了解更多移动测试发展的话，可以关注我写的书《大话移动 App 测试 2.0——技术篇》，会在明年上半年出版，这会是全新的一本书。粗略的目录可见： 大话移动 App 测试 2.0 目录。其中我也会将这次我全程参与钱包 9.0 研发过程中的一些经历和技术写在里面。