腾讯的专项测试之道

转自：https://cloud.tencent.com/developer/article/1005945

 

做者简介：

 

李昶博 腾讯 专项技术测试组长 腾讯专项技术测试组长，专一9年性能测试，人称“性能哥”，腾讯公司2015年度优秀讲师。 经历PC QQ、手机QQ、Q+桌面、QQ空间、QQ音乐等客户端项目，多个项目得到了百倍的性能提高。在性能领域，共取得6件国家专利。2012年，QQ性能优化项目团队获腾讯公司级重大技术突破奖。

前言

 

做者作了9年的性能测试，一直为腾讯 SNG 服务，经历了QQ、QZone、音乐等等项目。腾讯的职业发展通道，各位很熟悉了，这个岗位就是专项技术测试。今年会开拓一个新的领域，叫作音视频专项测试。

 

腾讯的价值观就是“以用户价值为依归”，因此用户满意，是测试员工作业绩举证的关键。你看下图这个曲线，横轴是日期，纵轴是投诉量,投诉量是测试员工举证本身业绩的关键。

 

上面是我作项目以来给公司带来的价值，曲线是指数级的，横轴是时间轴，纵轴是投诉量，半年的时间，10多倍的优化效率。下方这个图，一发布投诉量上升，如今贴着横轴，天天0-3个投诉量。

 

一、咱们的专项测试方法论

 

1.1 专项质量体系

 

下图最左边的是全流程介入，全部流程都在里面有本身的方法论。咱们有各类各样的指标，这是性能测试的关键点，不是光测有多长，有多少秒，还得测不少的红色指标，给全部流程配齐工具。

 

个人部门老大 jeremy，有一个分层测试理论，咱们对全流程都有办法介入，你们看红框，各个环节都有。再而后，各类指标和流程。因此性能测试毫不是测一下有多少秒，这个只是时延，红色的指标是更加专业的东西。

 

最后，咱们有各类工具和手段，如右下角这些，这些工具的名字可能你以为奇怪，后面会展开介绍。

 

1.2 腾讯专项技术测试员工能力模型

 

腾讯的员工能力模型从实习生到外包都覆盖了，我在的岗位是专项技术测试，红色部分值得你们看，可能与其它公司有所不一样。资深的同事开始阅读操做性能原码，甚至实习的同事自然读过安卓原码 。

 

要搞定这么多指标和流程，对员工能力的要求是比较高的。咱们从作手工测试，到自动化，再到使用性能分析工具，甚至看 OS 的源码来帮开发解决问题，这些技能是逐级提高的，这些领域能够产生很多的专利。

 

我在招聘的时候看到一些特色，某些实习生在大学期间就开始深刻研究操做系统原理。在职的外包同事也开始作专项自动化测试，这就是团队竞争力的提高。

 

1.3 速度体验评测模型

 

方法论里面有重要的一环，就是需求阶段咱们如何介入。天然的就是性能测试标准

 

去项目里给一些开发发现性能 Bug，首先得有提单的规则，到底多少秒算性能 Bug，这是发布标准。400毫秒，4秒，进度条在走若是连续四秒走不动用户以为焦躁，内部有用户体验研究团队甚至有这样的研究结论，相同的时长把进度条拉长一点，用户会以为走的快。最后这条始终要看到进度在走，流畅度再也不使用 FPS。

 

1.4 技术评审模型

 

上面的方法论里面还有一条，咱们在开发进入 coding 以前会开展技术评审。

 

全景图里讲到有一些技术评审流程，初级设计阶段概要设计时就会告诉你代码应该怎么写，遇到这些东西所有逐条怎样与产品经理PK，该不应加进度条，需求是否应该这样设计，跟开发PK价格设计的方案怎样，可否作到极简，每条对应的有须要测试的点。

 

二、咱们的自研平台工具

 

前文的方法论里面，讲的是如何武装你的头脑。如今，我给大家几把枪，这就是咱们自研的测试平台和工具。

 

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，你将一个文件打开再关闭，而后又从新打开读一遍再关闭，这很显然是性能问题。

 

咱们常常会发现一个问题，某一个客户端本地的文被计算三次，启动时再校验一遍用以前再算一遍，这为了肯定要不要更新，这种都是很显然的性能问题。

 

咱们在数据库里复制进去，直接看对应的执行计划，这对含有全表扫描的咱们认为这是性能问题，由于全表扫描这是忌讳的问题，咱们有不少的手段能够解决，不要在用户的集成上作全表扫描。手机本来性能不必定很好，有贵的也有便宜的，因此这些是个人演讲内容。

 

四、总结

 

咱们第一条全流程，每个流程给你们的方法论讲了性能UI和进度条，技术评审怎样跟开发PK，怎样与产品PK。咱们测了这么多的指标，最后第二条各类专项指标，第三条就是各类专项分析工具，因此是全流程各类专项指标以及分析定位工具，这三者齐备就是一个成熟的专项测试团队。