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

　　未来：找出问题还不够，要定位问题
　　了解了移动测试的过去和现状，现在可以大胆的预测未来了，不过，这里也仅仅是未来三年内的情况。
　　首先，测试人员肯定是朝着全栈的方向去发展了，这点毫无疑问。而功能（业务）测试，专项测试，自动化测试等都会变成一个测试人员基本的能力，而非加分项。
　　而随着网商的发展，各类互联网＋金融的崛起，移动安全的测试将会变成专项测试之后的一个新的关注点。
　　有些人可能会担心随着第三方测试服务流行，测试工程师的前途在哪，我想说，测试这个岗位和测试这个工作在移动互联网不会消亡，但综合能力的要求提升很多，将来不会再有单纯的业务测试，也不会再有单纯的自动化测试，以后测试将全部是测试开发工程师，这些人可以快速的去适应各种需求，并且能够通过业务和技术的双向分析从而定位真正所在的问题。
　　测试人员自我能力的提升，也不再是单纯的某一方面技术，而是这些技术如何真正的落地，以及怎么结合自己的业务，以及产品的实现框架去排查和定位问题，终解决问题或者优化产品性能。
　　与此同时，开发工程师也会慢慢的被要求承担一部分测试工作（产品自测），不仅能让开发工程师更深入的了解业务，而且本来我们需要自己去吃自己的狗食（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研发过程中的一些经历和技术写在里面。