腾讯的专项测试之道
李昶博 腾讯 专项技术测试组长 腾讯专项技术测试组长，专注9年性能测试，人称“性能哥”，腾讯公司2015年度优秀讲师。 经历PC QQ、手机QQ、Q+桌面、QQ空间、QQ音乐等客户端项目，多个项目获得了百倍的性能提升。在性能领域，共取得6件国家专利。2012年，QQ性能优化项目团队获腾讯公司级重大技术突破奖。
前言
作者做了9年的性能测试，一直为腾讯 SNG 服务，经历了QQ、QZone、音乐等等项目。腾讯的职业发展通道，各位很熟悉了，这个岗位就是专项技术测试。今年会开拓一个新的领域，叫做音视频专项测试。
腾讯的价值观就是“以用户价值为依归”，所以用户满意，是测试员工做业绩举证的关键。你看下图这个曲线，横轴是日期，纵轴是投诉量,投诉量是测试员工举证自己业绩的关键。
上面是我做项目以来给公司带来的价值，曲线是指数级的，横轴是时间轴，纵轴是投诉量，半年的时间，10多倍的优化效率。下方这个图，一发布投诉量上升，现在贴着横轴，每天0-3个投诉量。
1、我们的专项测试方法论
1.1 专项质量体系
下图最左边的是全流程介入，所有流程都在里面有自己的方法论。我们有各种各样的指标，这是性能测试的关键点，不是光测有多长，有多少秒，还得测很多的红色指标，给所有流程配齐工具。
我的部门老大 jeremy，有一个分层测试理论，我们对全流程都有办法介入，大家看红框，各个环节都有。再然后，各种指标和流程。所以性能测试绝不是测一下有多少秒，这个只是时延，红色的指标是更加专业的东西。
最后，我们有各种工具和手段，如右下角这些，这些工具的名字可能你觉得奇怪，后面会展开介绍。
1.2 腾讯专项技术测试员工能力模型
腾讯的员工能力模型从实习生到外包都覆盖了，我在的岗位是专项技术测试，红色部分值得大家看，可能与其它公司有所不同。资深的同事开始阅读操作性能原码，甚至实习的同事天然读过安卓原码 。
要搞定这么多指标和流程，对员工能力的要求是比较高的。我们从做手工测试，到自动化，再到使用性能分析工具，甚至看 OS 的源码来帮开发解决问题，这些技能是逐级提升的，这些领域可以产生不少的专利。
我在招聘的时候看到一些特点，某些实习生在大学期间就开始深入研究操作系统原理。在职的外包同事也开始做专项自动化测试，这就是团队竞争力的提升。
1.3 速度体验评测模型
方法论里面有重要的一环，就是需求阶段我们如何介入。自然的就是性能测试标准
去项目里给一些开发发现性能 Bug，首先得有提单的规则，到底多少秒算性能 Bug，这是发布标准。400毫秒，4秒，进度条在走如果连续四秒走不动用户觉得焦躁，内部有用户体验研究团队甚至有这样的研究结论，相同的时长把进度条拉长一点，用户会觉得走的快。最后这条始终要看到进度在走，流畅度不再使用 FPS。
1.4 技术评审模型
上面的方法论里面还有一条，我们在开发进入 coding 之前会开展技术评审。
全景图里讲到有一些技术评审流程，初级设计阶段概要设计时就会告诉你代码应该怎么写，遇到这些东西全部逐条怎样与产品经理PK，该不该加进度条，需求是否应该这样设计，跟开发PK价格设计的方案怎样，能否做到极简，每条对应的有需要测试的点。
2、我们的自研平台工具
前文的方法论里面，讲的是如何武装你的头脑。现在，我给你们几把枪，这就是我们自研的测试平台和工具。
2.1 研发支撑平台
首先我们能看到每个版本的 bug 解决情况，包括性能 bug。然后是每个 DailyBuild，都能看到各个工具的运行情况。
每一个 Bug 的解决率，红色的是 Bug 不达标细化到每一个部门，每一个部门解决了没有，能否发布在平台里。底下有一些性能 Bug 直接列在上面，因为这是做性能测试必须推动的事，非常重要。
最后是合流控制，所有的工具必须通过了，才会给开发员工开启 SVN 的代码权限。
我们对所有的工具列在这，这些工具确定的时候才能合流，每一个分支每天都可以收到工具的测试报告，而且当工具只要说不到时候，开发没有权限做合流，权限是流程自动化分配的。
2.2 安装包质量监控：体积、方法数
里面列举每一个需求测试是否通过，安装包直接细化到它应该有多大，我们拉一道红线过了红线是不合格的。安装包的体积给每一个部门有配额管理，直接告诉对应的部门经理，你们如果想植入新的特性到QQ里面，必须得使得安装包在多少K以下，包括方法数也是非常严格的要求。
现在为了让安装包不增大，方法数必须得零增长，你要上新功能把以前的水分挤干净了功能才能上。安装包检查非常细致地检查条件，不可以打包符号表进去，把符号表打包进去原码就泄露了，大家看里面的各种检查项。
2.3 静态代码扫描
静态代码扫描，非常低成本地接入，提供了两个内容我们可以发现 Bug。对应的测试报告就是图片中右上方这样，各种扫描器分别发现了 Bug。
再比如在 SVN 扫描出很多 Bug，并且自研了200多条扫描规则，基于下面大家自己看到的这些扫描器，各种各样的语言可以自研1700多条扫描规则每天都在运转，只要提交了基本当天都可以收到对应的 Bug 单。
Q: 规则和性能测试有关系吗？
A: 有，自研十多条和性能有关的规则，头文件里如果实现了变量会导致经典的 Bug 在一夜之间从三兆增长到十三兆，十兆增长到开发把字符串的定义写在 STDAFX.H 里，用静态代码扫描的语义分析找到 Bug，Bug 的趋势和所有 Bug 的类型各种分析列在这里。
2.4 性能自动化测试工具：Perflib & QTA
手机挂在自己做的墙上 QTA Wall，每天自动运转，基于自动化测试底下采集所有性能相关的测试指标。内部把 QTA 叫自动化测试平台，界面上采集性能数据。
2.5 稳定性测试工具：New Monkey
New Monkey 稳定性测试，要求每一个界面 Monkey 的测试留在界面，所以保证它不要跳出，一旦跳出要能够回来。所以我们有几个管理指标，界面的覆盖率以及界面内部的控件覆盖率，一定要通过若干个小时内把各种界面的各种控件测齐。
各种操作类型的概率，滑动、点击等概率，包括返回 Home 键和菜单键都是可以控制概率，很低的接入成本提供每天的安装包过来就可以给你出测试报告。
所以要接很多产品，半年内刚上线发现4500个 Bug，到现在每半年接的项目越来越多，不仅有收敛的趋势，还可以找出3000多个 Bug。
2.6 卡顿监控：Magnifier
Magnifier 卡顿监控，这是看不见界面的监控工具就在后台里面给内网的实验室环境做测试。
当你的界面发生卡顿时，默默记下相关的分析数据，最后生成了一个对应的分析报告，直接可以把卡顿问题解决掉。任何一次随机发生的卡顿都可以把它优化解决掉，当某一个项目接入 Magnifier 以后，它的投诉量下降，这是一百多倍的优化成果。我们自己写了 SPK，填入要测的 App 就可以监控 APP 的卡顿。
2.7 专项质量体系
我们把能力分三层次，采集性能数据可以度量证明它是否有问题。分析工具和全网的数据上报，各种指标都有对应工具，有一些单元格里存在些信息叉，说明目前没有这个能力，是值得我们做并且改进的东西。
2.8 自动分析工具**框架效应
2.8.1 框架效应：PK导致效率底下
测试和开发怎样吵架？把大家带入到环境测那么多指标是为什么?
我们测试向开发提了一个 Bug，17秒，我看到接 Bug 的开发把我的 Bug 拒绝了，理由是17秒的体验可以接受。做开发的天天面对编译器肯定慢，所以他会接受。但用户不接受，基本的测试标准超过4s，你的进度条得出来，要不然接受不了。
之前我们提性能 BUG 跟开发吵架PK，开发认为不影响用户可以接受。然后我们去实验室里进行证明，证明你做的产品性能真的是不合格，接着就会决策上升交给领导解决，领导看了以后觉得这的确是慢应该还是要改。
接着开发会想你测出的结果十几秒这是你的测试机性能差，我的机器性能挺好的，认为测试数据不稳定。开发怼我们说“你如果不能在我这儿做我怎么改Bug”，我们的测试会说“你来我的环境下”。
在我们的环境底下可以复现还会遇到这样的问题这个好办，复现不了怎么查，最后双方证明查了一堆问题以后发现这是系统 API 的 Bug，开发说我改不了，这不是我的问题。
最后我们还是松口了，通过了测试，付出的计算量和开销还是这么大，最后发布到外网的时候用户体验还是照样投诉。我们QQ几个亿的用户，多写几兆字节的东西用户都可以感受到并投诉了。问题推到了测试这，测试不是实验室体验的很好的吗。
像这样的PK解决不了的问题困扰我很多年，我为此去研究了社会心理学这本书，大家找到了结论—框架效应。
这是人性啊，框架效应有很多的心理学测试很有意思，可以找到奇妙的心理学测试案例。
做个比较简单的测试例子，现在的大脑跟着我说的去想，不要去想母老虎，不要想华南虎，不要想东北虎，不要想老虎，这个时候你在想老虎，这就是框架效应。而框架效应真是拉低效率问题的根源。
2.8.2 实现定位随机性能Bug无需重现规律
干货来了，团队的共同努力，使得前面的那种低效状态发生了改变。现在，我们能做到不需要复现规律，也可以定位随机性能 bug。
因为我们提供了全面的分析工具，只要你的随机性能问题暴露在我的工具下面，就能把问题定位解决。
解决方案是这样，我们把所有的用户体验卡多久，时长多少切割成硬指标，CPU、内存、流量等配上全部的分析工具。自研的IO，流量利用传统的 TCPDump 可以抓包。
闭环的环境下测试原本承担度量和验证，但在我的新体系下革新，将分析环节从测试这边拿过来，由性能测试团队提供了分析工具都是自研的，这时一切的一切都变化了。
所以呢，从产生问题到发现问题，再到解决、验证的闭环里面，测试团队提升了分析能力。十年前别人可能会说，你能力这么强，啥时候转开发啊；现在，开发会说，性能哥帮我们看下这个 bug 的解决方案吧，甚至有开发同事主动转来我们团队。
2.8.3 性能自动化分析能力**框架效应
性能自动化分析实施之后触发了一个良性循环，我们提供了带分析能力的性能自动化测试，上一个版本对应的指标是多少，这个版本是多少，合格还是不合格，所有的指标我们列在这里，而且是带分析数据的。
这些指标如果不达标立即去分析工具里面找对应的日志，你可以分析出来，分析到代码。现在有了分析能力给你提单，QQ某一个业务逻辑用了20兆的IO，你会怎么想呢？
这个IO太多不合理。如果有一个开发者跳出来，告诉架构师你这样的设计肯定不行，这得改，我很欣慰，以前是开发跟我吵说这个 Bug 不需要改了，又不影响用户体验。
现在有其它的T3级的资深开发站在我身边，说这个代码写的不行得优化，一下子测试与开发之间的关系变的亲密，我们只需要做这点，你的代码写的好不好，通过框架效应在人性上解决这个问题。
比如，年前团队发现一个性能 bug，提单的时候就说了，QQ的AR红包导致启动性能下降。
开发的潜意识就是怎么优化AR红包，比如年后下架防止长期影响，而不会去想5秒慢不慢，测试能不能复现等等。语境的变换，就打破了心理学框架效应。测试和开发越过吵架的环节，直奔解决问题。
2.9 获取原子级硬指标—基准测试套件工具
跟你沟通时直接聊代码质量怎样，不聊用户体验，这是软改硬，软指标是用户体验，硬指标就是IO、CPU内存，直接开始写对应的代码。优化之后进行测试验证，代码从原来的20兆减少到1兆，我们的性能提升20倍，而且90%的用户都会用到，肯定全网的用户都会受益。
2.9.1 CPU测试
CPU 测试，大家肯定想到 CPU 占用率，但你能想过 windows 下 CPU 曲线率吗？
我们的创新点在于哪里呢？你看 CPU 占用率有什么问题，你忽高忽底有没有问题。给你一个曲线是否合格不好判断，除非是持续反对，持续99%怎么办，持续50%算不算问题。
其它的 App 为有传染，操作系统刚启动有很多的其它程序在加载，那你的性能怎样保障。安卓 4.X 系列有 Bug 的，你看黑色框里的最后一行，-98万，这个 Bug 怎么回事？
明明有开销但操作系统不可能让 CUP 占有率输出一个负值所以输出0，那你能测出 Bug 吗。
为了解决这个问题使用最新的时间片测试，用掉了多少的时间片，可以直接表征你的代码计算量。换句话说运行某一段模块和代码之前，我取一下时间片，运行了以后取一个，两者做减法，这是这段代码用到的时间片，这个时间片我们拿去和以前的版本做对比超标不合格肯定有多的，没超标是通过的。
对应的 CPU 我们配上分析工具，windows 下的 WPT 就可以分析 CPU 超标的问题。
2.9.2 IO测试
IO测试，提一个 Bug 启动12秒，以前可是6秒，慢了一倍，开发连续三周都没有找到原因。我们只好引入IO分析，突然发现启动IO增大三倍多。增长的部分是因为某一个组件导致的，把那个组件去掉性能就还原。
我们分析成本两个小时，所以我们是一个60倍的效率提升。我们自研的分析工具是这样，这是它输出的日志，对应的函数站打出来，可以直接跟踪是哪一行代码。
有了它以后开始推广，所有的各种场景一股脑的清扫干净全部的性能问题，30多倍的性能提升，主线程IO清扫到0，这一下子在其中一个项目中就换得100倍左右的投诉量下降。
2.9.3 内存测试
内存测试，这是最简单的就是打开关闭，对应的指标就是从开始是基准，泄露就是这样算的。
首次打开之前在第一次关闭以后有的内存是复用的，缓存是否合理要监测出来。内存分析工具，MAT，我们自研了分析工具 Finder。
对应测试性能自动化脚本这样写，复循环，打开关闭，打开关闭，对应的采集性能测试数据，最后给你强大的性能测试报告，而且自带分析能。memdump 可以找出内存为什么增长。
2.9.4 GC测试
GC测试。因为它有一类问题是一定解决不了，用传统的方式打日志发现某一行代码有性能问题，但过一会儿测又不是这行代码又是别的行数为漂移？
我看过操作系统安卓的原码，可以把进程的所有线程都休眠，包括你的主线程。这意味着GC发生的瞬间壮大了函数，一个函数的耗时长。从传统的函数调用上解决问题，绝对解决不了GC导致的性能问题。
我们自研了一个工具 AIIocTrace，每一个对象分配了多少字节多少次，这个对象被谁哪一段代码分配的，可以直接的找到问题所在解决，把这个复用以后GC可以减少。
2.9.5 掉帧率（流畅度）测试
流畅度测试，FPS 不要用，我们这里是一秒 60 FPS。如果每一帧时延稍微长一点，用户会觉得有问题，这时 fps 还是50。卡顿的总时长除以滑动的总时长，这样就是百分之零。
大家记得掉幀率相比 FPS 这是更加敏感的指标，这是腾讯内部的创新。平均化，性能测试要测很多次，测十次有其中一次是50，那最后得出的结论是59，你告诉项目组合格，就永远发现不了刚才的十帧卡顿的问题。
我们只测一次，第一次测合格了，第二次测有性能问题，你赶紧提 Bug，提了 Bug 的问题是什么，对应的都有分析工具。我们把卡顿那一瞬间的主线程报上去了，你直接查对应的问题是什么，直接把卡顿的问题解决掉。
在这套生态环境下，我们在某一个项目里优化它的性能，甚至超越了 Facebook。
2.9.6 流量测试
流量测试。如果你使用操作系统安卓提供的 TrafficStats 时，谷歌的官网说over all interfaces，这说明它是有问题的，最基本的指标离不开用户投诉量，这是其中的一个项目。性能投诉最原始排第一，很高，优化后排名成倍下降，数量也是成倍下降，这是基本的法则。你的项目里看用户的投诉。
3.2 Crash全网上报
再一个，也是最基础的，Crash 率你要监控起来。
Crash 做全网上报，我们内部有这样的平台，你们外部会知道这是腾讯的Bug ，我们内部用了更高级的版本，用户体验好一点。每天发一个日报，跟领导商量好了，这个指标的精品标准有多少，我们定的非常严格，一定要做成精品。
3.3 卡顿全网上报
卡顿全网上报优化了6倍，因为每次卡顿都上报了对应的函数对站，可以形成闭环解决。
我们可以在后台看到这样的图，每一个卡顿事件对应的函数站可以点进去仔细查阅是什么性能的原因。
当构建这样的闭环以后，对应的项目投诉量呈百倍的减少，对于你的用户体验全网耗时也报上来，这个图我相信大家第一眼喜欢看最底下的那个，逐个版本明显的增多。
经验不是看下面小于1秒的用户体验，应该看长尾。如果一个用户以前启动时长要7秒左右，现在优化到3秒的区间，这是一个超过2倍的性能提升。这是至关重要的。
如果你是从1.1s优化到1.0s，用户的感知不大，所以要看长尾。长尾下面真的是少了一半的用户，那对我们过亿的产品而言，长尾几百万用户少一半了不起，对应的投诉也是正相关的。
3.4 SNG APM：掉帧率
掉帧率，若干个版本以后有质的提升，甚至排在其它场景的 TOP3。所有的函数站放在这里，直接看到哪一个函数耗时多少，直接定义在某一个函数导致卡顿的概率最大。
3.5 SNG APM：IO、DB、内存
我们做 APM，把IO、数据库和内存泄露和内存触顶率的创新指标记录下来，这些里面不详细展开。重复IO，你将一个文件打开再关闭，然后又重新打开读一遍再关闭，这很显然是性能问题。
我们经常会发现一个问题，某一个客户端本地的文被计算三次，启动时再校验一遍用之前再算一遍，这为了确定要不要更新，这种都是很显然的性能问题。
我们在数据库里复制进去，直接看对应的执行计划，这对含有全表扫描的我们认为这是性能问题，因为全表扫描这是忌讳的问题，我们有很多的手段可以解决，不要在用户的集成上做全表扫描。手机原本性能不一定很好，有贵的也有便宜的，所以这些是我的演讲内容。
4、总结
我们第一条全流程，每一个流程给大家的方法论讲了性能UI和进度条，技术评审怎样跟开发PK，怎样与产品PK。我们测了这么多的指标，最后第二条各种专项指标，第三条就是各种专项分析工具，所以是全流程各种专项指标以及分析定位工具，这三者齐备就是一个成熟的专项测试团队。
公众号推荐: