由腾讯质量管理通道和腾讯大学联合举办的首届腾讯质量峰会于10月29日隆重举行，吸引了200多内外部小伙伴们。历时1.5天，深入介绍公司质量管理和测试领域的经验和成果。有幸邀请到公司高级执行副总裁dowson分享质量管理在腾讯的重要性；作为质量管理通道分会的会长jeremy讲述了腾讯质量发展十年之路；最后压轴的是专业热门话题分享：如何让android app更加流畅。
质量是腾讯的生命线
作为技术GG的dowson，在工作的早期也曾经做过测试的工作，深知测试工作对整个产品的重要性。他认为，测试工作有三个方面十分重要：第一个是能力，第二个是开放，第三个是角色转变。
在能力建设方面，测试工作到了目前这个阶段，已经远远不是简单的修改bug的阶段，而是已经进入到一个产品综合质量的一个新阶段。测试工程师现在不仅要保障app功能的正常使用，也要保证app是否流畅，在进入app市场后是否安全，发布的过程是否有漏洞，移动端不同的系统之间能否保障功能的同样实现等等。这就要求我们做质量的同学具有更强的能力。
第二个是开放，腾讯在质量测试的过程中，随着业务的扩大，测试的工作越来越多。现在质量通道通过自身的建设，已经建设出了许多质量测试的产品和平台，来帮助我们的测试同学提高效率。现在越来越多的公司业务也在逐渐扩大，腾讯愿意和大家分享我们的测试经验，同时，也愿意同其他测试的同学开放一些我们的测试工具。
最后提到角色转变，生动地举了一个开保姆车司机的例子。一个开保姆车的师傅，他平时的工作，因为车载的都是小朋友，所以开车的时候特别小心。但他也是一个热爱赛车的人，一坐到跑车上，他的开车风格完全不一样。这个角色的变换跟你本身处于的场景有关，你要承担的责任会随着场景而变化。做质量和测试的同学也同样，不能仅仅是站在产品开发的角度来测试，更重要的是要站在用户的角度来看问题。一定要做好角色的转变，这样才能真正的做好用户体验。
十年走来，无限精彩
担任质量管理通道会长的jeremy介绍到在10年前，整个腾讯质量类同事仅有不到50人，3个团队在做质量测试的工作；而今天，整个腾讯已经有近1400人在做质量工作了，其中90%以上的人，是在2010年后加入腾讯的。5年时间，腾讯的质量团队扩大了近10倍，那么在人员急剧扩大的情况下，如何保证团队的战斗力呢？听听jeremy怎么说。
首先是在制度建设和系统建设上，在腾讯质量这个大盘中，我们把质量测试工作分了系统测试、游戏测试、专项测试、过程改进、配置管理5个职位，全方位的探索测试领域岗位细分。而在系统建设上，我们已经拥有一系列的公司级分享平台，TAPD、CodeReview、KM、RDM等在公司已经是广为人知的平台；同时，针对不同的业务，还有很多部门级的测试分享平台如移动众测平台、优测平台等，并且这些平台大多已经开放给了整个行业，现在有很多公司和我们一起在用这些平台。
其次，是对自己的严格要求。在内部晋级的时候，质量通道对晋级率把关严格，一定要让晋升的人是真正有干货的。有很多和他相熟的同事说，为什么一定要卡的这么严，再做测试工作晋升是不是没有希望了。但是，时间慢慢证明，这样的方式是十分有效的，目前，腾讯T3的工程师，在业界是受到认可的。在对自己严格要求方面，他还提到要设立严格的制度来保证对自身的要求。如果外网出现了问题，开发和测试一起承担外部事故责任。然而，结果是非常好的。目前开发团队对质量团队逐渐信任，合作也越来越顺畅。
最后，要让测试团队工作更有效率。我们不能在一个产品上做一万次测试，每一个版本都需要测试一遍，这就要求测试团队进行工具的自动化开发，让android、iOS这部分最基础的功能进行自动化，这个可以带来最直接的指导意义和指导价值。
互联网的产品制作者都希望让用户用我们产品的时候特别爽，爽是互联网企业一直追求的一个词。那么如让用户感到爽，流畅度是一个非常重要的指标。怎么让android的app的用户拥有丝滑般的享受，michael有自己独到的经验。
UI的流畅度是一直困扰android或IOS关键的用户体验，michael在四个方面对这个问题做出了解答。他在原理、如何获取流畅度指标、如何定位流畅度的缺陷并优化、是否有没做的工作，并且能够在运营中持续的优化。
做任何性能测试，它的基础就是用数据来说话。在测UI的帧数和响应时间，基于以前的经验，他选择了FPS，但是在结果出来以后，其实你根本都不知道它在表达什么意思，哪个是好，哪个是差。高是因为什么，低是因为什么。原因是FPS是画面变化的次数得到的数据，如果测视频的话是很有用的。但测app的话，它不会时时刻刻变化，UI没有变化的话是很低的。所以FPS在这时候很难衡量去app是否卡顿，或者app的UI是否卡顿。
那么用什么方法比较合适呢？如果要衡量一个app是否卡顿的话，用丢帧不太合适的话，就用总的减去丢掉的帧数。比如本来有60次，如果中间丢了几帧的话，就用60减去丢掉的帧数。后来我们发现获得这个指标是非常容易的事情。我们自己自研的一个小工具GT上做了一个小插件，GT是随身测试的小工具。GT注入插件，注入之后会在GT的面板上显示流畅度的指标并记录下来，同时会在里面展示一个简单的曲线。
我们做了很多优化，发现整个trace都玩过了，我们自己的方法都差不多了，系统方法耗时是最多的。后来我们发现是布局太复杂所导致的。谷歌也提供了一个工具，Hierarchy Viewer，这个优化很简单，就是把你的层级减少。首先减少不必要的中间层，多了一个中间层，会增加调用的次数，刷新时间就会减小，就会感觉到不流畅。
说了这么多，我们会发现一个问题，我们每次碰到这种事情的时候都是在做救火的工作，其实已经开发得差不多了，告诉我们说这个不行。我们不想这么累，于是想建立一个流畅度的监控和运营制度。最简单的方法是用lint扫描一下，把相关的结果进行归类，把这些缺陷解决。
