由于之前那篇其实算是公关稿了。。。被恒温吐槽太水了。我也觉得太水了。所以我还是打算多弄点技术相关，测试关心的干货出来。
主要以下几个方面，待会儿到了公司我来详细写
浅谈react native和扩展信息
和我一个出品人专题下面的天猫专家鬼道说的react native当天真的是火爆的一塌糊涂。从鬼道的说明来看，天猫其实已经有部分的界面使用了react native。目前实践下来的情况整体的性能在webview和native中间，而且比较贴近native的性能。
在过程中我也碰见了一家做企业级产品的公司，他们其实在2年前就在尝试类似于react native的尝试。react native目前其实对于iOS6支持的不是很好，而这家做企业级产品的公司是使用jsCore做了一个类似于react native的解决方案并且很好的支持了iOS6。现场我也使用了他们的产品，从界面的跳转到listView的滚动都很流畅，体验很好。
现在我和手Q的同学表示，目前支付宝和腾讯应该还没有使用或者有react native的实践。而之前类似于react native的实践都是有的，比如iOS中使用lua来做一些hot fix或者a b test。如果对于lua在移动端没有了解的同学可以看我的这篇文章：http://testerhome.com/topics/2041。其实其原理按照我们目前的了解还是应该差不多的，假设在中间有语言翻译层的话，那么其实无论用什么语言来编写都可以，最后使用js去调用本地原生的控件即可。目前的总结如下：
1.react native相对来讲，目前看来是一个很好的解决方案，但是并非一定要和html5比谁好谁坏。
2.react native并非银弹，总体认为，是否能够大范围使用还是要看产品架构，业务复杂程度等上下文。最终应该是native、html、react native三者并行的状态，只不过是侧重的功能不同
3. 当然，由于现在react native的经验并非很多。但是按照lua之前的经验。动态的去调用生成本地的控件还是有一定的风险和不稳定性，而且也是针对特定的一些场景和控件。当然，我更多的觉得对于测试会是一个新的考验。
4. 同样的，react native本身的js其实是打在整个安装包呢的，那么关于安全性的话。其实本身目前针对js就没有一个完全100%安全的方法，所以代码安全性上面可能也没有办法完全的保证。
5. 最后一点就是流量。怎么说呢。推脚本也好，或者以后动态更新也罢，其实都有流量上的消耗。这个其实我觉得如果运用频繁之后，流量上的消耗可能也是一个需要关注的点。
百度交流细节和感想
百度的交流给我最大的一个感觉就是——百度的工程师平均的技术水准都很高。这点是事实。百度也有自己的技术委员会等。百度同学给我的反馈是，对于测试来讲，无论做什么，他们都需要一个很扎实的技术能力。我也问过他们如果是走纯业务路线在他们那边能够走的多远，答案是有肯定有，但是是非常个别的。因为无论是职业发展还是晋升考评，百度都有技术上的考核，所以这点上面百度本身会在面试，晋升，包括职业规划等，技术都是必不可少的一项。
百度也是一家很看重code review的公司。高工中有一些就是专业做code review，并非只是看看代码，而是从code review中直接找到bug或者性能提升点或者业务逻辑错误的地方。不过这样的技术人员很不好找罢了。
总体在百度，让我感觉的是每个来的人都很专业，而且提出的问题很有针对性。总体感觉技术氛围很浓。
360交流细节和感想
360当然也做app，但是他们的最终目标肯定不止是做app。所以360工程师关注的点既很有广度，也很有深度。比如应用上的兼容性，专项测试，持续集成等，这些我还能有点经验，比如adb如果链接多个机器不稳定了怎么解决，其实ddmlib就是一个很好的东西嘛。但是涉及到OS层面的API区别，包括kernel上的一些问题我就力不从心了。不过360的总监还比较关注一个问题就是我们公司有什么机制或者是怎么提高大家的分享的积极性。其实阿里或者支付宝都有自己的技术大学（当然我们自己这样称呼）。然后我们也有自己的内部技术blog，比如ATA，ATiT等，这些其实干货很多，只不过不对外开放。每天的6点都会自动邮件自己的组告诉大家自己的组今天有谁发了什么文章等，定期也会组织内部或者外部的分享，并且每年也都有技术提案，在公司内评奖啥的，今年我提的就是移动无线上面的功能自动化＋性能监测平台等。
总体在360，技术专业程度自然不用质疑，不过感觉和我这样纯做app的人的关注点还是很不同的。我需要加把劲啊。
手Q专项总结感想
手Q专项的负责人和我在这次QCon成为了很好的朋友。我们两个做的事情目前来看也是最接近的。当然相同的我总结下，其实就是以下两点。
1. 一定是有功能自动化的，但是用例都是比较固定的。目前我所在的团队和手Q的团队功能自动化用例斗士在70个左右。这个70个用例都是最最核心，最最不会变化的功能和业务流程。而且我们不会轻易的去增加用例，这样会有额外的成本。功能自动化一方面可以用来做回归，另外一方面就是辅助性能监控能够在持续集成中跑起来。
2. 性能一定要持续做，并且要区分手工和自动化。手Q中一个很好的实践是，每次迭代或者每次check in都会有一些固定功能的性能数据产出。他们会有数据展示的界面和报警，同样我们也有。当一个产品如果内存，cpu，流量等消耗一直在一个固定范围的时候，突然有一天出现一个峰值，那么这次check in肯定会引起重视。所以很多事情我们是要去考虑怎么让开发和公司引起重视，但是同时我们也需要去明白我们应该怎么去做这样一个测试，我们的策略定的好，报告一目了然，那么自然就会有更多的人来使用，也自然会受到重视。
总结
其实和赶集，手Q的同学聊下来，最终得出的结论还是这样一点：
流程和技术也许都不会差太多。但是并不是能够完全借鉴的，需要结合产品和团队特点去慢慢走出一条属于自己的路
任何问题讨论到最后还是落到人的身上。我们要找到靠谱的人，有想法的人。流程和技术其实都可以照搬，但是同样一个事情，做的人不同，做的方法不同会产生很大的效果。我举个简单的例子好了。比如说我们要找一个同学做api测试。那么也许X公司的同学说我们的效率很高，我们应变变化的能力也很强，我们的框架很多BU都可以用。而Y公司就会觉得我们也做了啊，为什么感觉还是效率不高呢。原因很有可能的是，api测试框架的组织架构不同，也许Y公司没有数据驱动？也许Y公司没有做出很好的数据配置的架构？也许Y公司的做的这位同学也没有太多的想法，只不过去完成工作罢了。等等这些其实都是原因。故而人很重要
测试人员不能仅仅通过单纯的测试活动来保证质量了。其实很简单，我这次提出了性能监测，hybrid的巡检，手Q的同学也是说到了性能的持续集成和分析等等。那么我们的测试已经变的多样性了，活动也不仅仅存在于研发过程中，甚至渗透到了每时每刻。那么其实移动无线现在产品的质量怎么做？就应该是各个方面去保证，通过我们想得到的各种手段，持续集成，自动化的用户舆情反馈分析，线下线上的数据搜集分析，专项测试，安全分析，风险评估等等等等，这一系列看似很多和测试没有关系的事情，其实对最终的质量都有着至关重要的效果
其实最近又有人开始讨论测试会不会消失这样的问题了。其实事实再次证明了，测试岗位消失不消失这个不重要，重要的是测试这样一个活动和保证产品的质量的方法和思想已经进入了一个新的阶段。面对目前移动互联网灵活的产品，我们需要更快的应对速度，面对每年层出不穷的技术，我们也需要不停的学习。所以最终的目标是大家使用不同的方式和技术去保证质量，你的title是不是测试人员还重要么？重要的是你是否跟得上时代。
Monkey（陈晔）写于QCon结束后