《易测试》2013-04

目录

1 平凡的功能测试发现不平凡的Bug

3 性能测试简报

6 团队代码规范实践之路

11 初步探索前端性能测试

18 移动客户端测试10问

22

Linux网络控制神器 ———Traffic Control介绍 平凡的功能测试也能发现不平凡的Bug，这里就有这样一枚背景深厚、故事丰富的Bug，对iOS线程控制机制感兴趣的童鞋们看过来。你是否在使用时下风光无限的移动App客户端！趁着App的风声乍起，测试人员也迎来了新的测试领域挑战。如何保证App的正常运行？如何确保App的安全性？或许可以从以下10个问题中找到答案。团队代码规范的重要性不言而喻，本文介绍了杭研质量保障部探索、实践团队代码规范的过程和经验，希望对同样关注代码规范的团队有所裨益。

我们在性能测试过程中发现有一些问题，可能会经常隐藏于代码、应用架构中，特把这类问题分享出来，希望能引起大家的警惕。本文将向大家介绍一款L i n u x 网络控制的五星级神器-Tr a f f i c Control，该工具在网络带宽、丢包率、延时等控制方面表现优异，是网络异常相关测试的首选工具。

从去年开始，我们利用业界现有的工具对前端页面的性能测试进行了初步的尝试，取得了不错的效果，跟大家分享。

陆春红

2010年加入网易杭研QA部门，有后台、算法、

C/S&B/S架构产品测试经验，目前负责网易云音

乐产品测试。一个喜欢折腾的人，在折腾中把自

己所有的激情投入到生活的每一个空间。

平凡的功能测试发现不平凡的Bug

问题描述：

话说，今天我要向大家介绍一个小Bug，它来自当今最小清新的一款音乐产品的iOS版本：进入已下载的歌单，点击“管理歌曲”，连续且快速的删除几首歌曲，App会出现闪退现象。

问题重现并不困难，如果大侠还在使用怀旧的iPhone4及其以前的产品，那么您不用太着急忙慌，只要悠闲的删除若干首歌曲，问题必现！假若高手装备着当今最洋气最高端的手机，并且怒气满100，您只要使出必杀技------幻影夺命手：快速并反复的删除歌单，直到手机的反应开始慢于您的动作之后，App的闪退现象也会不期而遇了。

崩溃原因：

人在江湖，身不由己！抓住了Bug还不够，还需要对其进行深入分析，找到问题原因：原来，删除歌曲的操作会触发歌单下载进度的重新计算，歌单下载进度的重新计算会触发歌单容器结构的快速遍历，所以连续删除的操作与歌单下载进度的计算两个线程出现了同步问题，对一个容器结构快速遍历的同时另一个线程尝试更改它，从而引发了应用程序崩溃。

解决方案：

增加线程控制机制，采用OperationQueue，如果一个线程在一个operation里遍历，另一个线程要改变容器时，就取消那个遍历的operation。

技术念念碎：

iOS 和 Mac OS 传统的并发编程模型是线程，不过线程模型伸缩性不强，而且编写正确的线程代码也不容易。Mac OS 和 iOS 采取asynchronous design approach 来解决并发的问题。

*引入的异步技术有两个：

G ran d C entral D ispatch：系统管理线程。你不需要编写线程代码，只需定义想要执行的任务，然后添加到适当的D ispatch Queue。G ran d C entral D ispatch会负责创建线程和调度你的任务。系统直接提供线程管理，比应用实现更加高效。

Operati o nQueue：类似于D ispatch Queue。你定义想要执行的任务，并添加任务Operati o n到Operati o nQueue，后者负责调度和执行这些任务。和G ran d C entral D ispatch一样，Operati o nQueue也管理了线程，同样高效。Operati o nQueue是Co c o a版本的并发D ispatch Queue，由N SOperati o nQueue类实现。D ispatch Queue总是按先进先出的顺序执行任务，而Operati o nQueue在确定任务执行顺序时，还会考虑其它因素。最主要的一个因素是指定任务是否依赖于另一个任务的完成。你在定义任务时配置依赖性，从而创建复杂的任务执行顺序图。

性能测试简报

1、mongo-java-driver升级优化

某产品性能测试中发现mongo-java-driver-2.7.2.jar在高并发时，mongo写入存在性能瓶颈，通过线程监控发现有大量blocked现象。

升级驱动版本为mongo-java-driver-2.9.3.jar，性能得到一定提升。建议升级驱动版本，尽量使用最新的稳定版本。

2、mysql-connector-java驱动升级优化

某产品性能测试，发现Java堆内存不断增加，Jmap查看堆内存时发现com.mysql.jdbc.JDBC4PreparedStatement存在内存泄露。

将MySQL驱动版本从mysql-connector-java-5.1.5-bin.jar升级至

性能测试组

成立于2010年7月，为杭研各产品提供性能

测试解决方案，包括设计性能测试方案、定

位产品性能问题、优化产品性能以及评估上

线风险。目前致力于完善性能测试体系、推

进性能测试自动化、积累和沉淀性能测试知

识。

mysql-connector-java-5.1.14-bin.jar解决该问题。

在使用第三方工具时，建议及时更新，不要使用过老的版本。

3、String拼接方式会影响性能

Java中，String拼接有多种方式，常见的是String+、StringBuilder以及StringBuffer，在我们编程过程中可能喜欢简单的String+方式，但是使用不当的情况下，高并发时会导致性能问题。String+ 拼接方式对于不同类型的拼接场景处理方式是不一样的。

1）当String拼接的是字符串常量时，编译器会在编译阶段自动优化。

String test = "this " + "is " + "a " + "test " + "string"

编译器会把它视为：String test = "this is a test string"

2）当拼接的字符串中有变量时，执行步骤首先会创建一个StringBuilder，然后执行append(),再执行StringBuilder.toString()。当并发高时，会有大量的StringBuilder创建，然后丢弃，成为垃圾对象，影响性能。

更坏的情况是，当你在循环内使用String+时，StringBuilder对象的生成是在for循环内部的，会导致每次循环都生成StringBuilder对象，产生更多垃圾对象。

因此在拼接字符串变量时，尽量用 StringBuffer 或 StringBuilder。

4、网络中断造成cpu0使用率很高的问题

使用Sysbench测试MySQL性能时，发现cpu0软中断过高，导致cpu0跑满，tps上不去。排除是其他设备中断的影响，确定是网卡的问题。

最后，针对单队列网卡多CPU环境下软中断不均衡问题，启用RPS/RFS

设置，类似于多队列网卡的功能，把软中断分散到各个CPU，

从软件上分散了多CPU系统上网络数据接收的负载，提高了网络性能。

5、System.currentTimeMillis()高并发调用代价高

System.currentTimeMillis()在Java中是最常用的获取系统时间的方法，它返回从UTC 1970年1月1日0时开始经过的毫秒数。在某项目的性能测试中，定位问题的过程发现它似乎有较大性能损耗，当时开发的实现在for循环里每次都调用一下。

通过实验证明高并发调用System.currentTimeMillis()会有一定的CPU损耗，并发高的毫秒级接口建议通过以下策略优化：

策略一：如果对时间精确度要求不高可以使用独立线程缓存时间戳。

策略二：将当前时间赋值给counter，counter进行单独计时。

参考：博文链接

6、CPU密集型服务在部署时注意资源隔离

某产品的线上服务出现一定比例的响应时间大于2s的请求（线上压力较小的情况下），通过逐层定位发现是tomcat所在服务器同时跑一个视频编解码服务，该服务造成其中2个CPU使用率达80%左右。停止该视频编解码服务后，观察一天线上请求日志，响应时间均在10ms以下，问题解决。

建议：CPU密集型服务如视频转换、图形图像处理等，在部署时最好单独部署，或做好资源隔离。

团队代码规范实践之路

又到了一年一度新人入职的时候了，很多团队再次开始为规范新人的代码水平犯愁。代码规范的好处相信大家都知道，就不再重复了。那么如何高效地达到这一目标，不让部门制定的代码规范沦为一纸空文呢？今天我向大家介绍杭研质量保障部近期的编码规范检查经验，希望能有所帮助。

我们的代码规范检查实践是基于Checkstyle工具。Checkstyle是一款针对Java的轻量级代码检查工具，历经多年发展已经达到了很成熟的阶段，跟多种开发工具能很好地集成在一起，支持强大的自定义检查规则，对于杭研后台制订的Java编码规范，仅有两三点不支持。

Checkstyle的详细介绍参考官网：

http://checkstyle.sourceforge.

孔庆云

2009年加入网易，拥有两年多基于Ruby On Rails的

质量管理平台开发经验，参与过网易云阅读后台多个

版本的接口测试工作。2011年下半年开始投入到移

动自动化测试工作中，基于开源工具Robotium搭建

了Android自动化测试框架并进行推广，同时也在进

行iOS自动化测试相关工作。

net/，感兴趣的童鞋可以深入了解一下。

检查流程

1、团队就Checkstyle检查规则达成一致，制订Checkstyle规则文件。

2、开发人员本地使用规则文件在Eclipse中进行自查，争取把错误消灭在代码提交之前。

3、Jenkins中使用Checkstyle插件定时检查SVN代码库并把检查结果推送给团队成员。

4、在前期，检查结果出来后需要有专人跟进修改，直到团队养成习惯。

图 1 代码检查流程示意图

至于Checkstyle在 Eclipse/Jenkins插件的安装、配置和使用详情，可以参考我的这篇博文：博文链接，此处不再赘述。

实践成果

我们在测试开发组内的Dagger、Emmagee开源项目以及一些自动化测试代码项目中进行了试用，运行一个多月以来，效果显著。

首先，团队的编码规范程度得到了提升，代码规范检查能够完全按照团队所制定规则执行。

如在Orange项目中，使用了上述检查模型后，代码检查的错误率直线下降，很快就从200+变成了如今的零错误。Jenkins中检查趋势图如图2所示：

图2 Orange代码检查趋势图

其次也是显而易见的，检查效率也大幅提升，用Jenkins自动检查替代了痛苦的人肉Review。

除了上述的收获，我们也有一些心得体会：

1、常见代码规范错误

表 1 常见代码规范错误列表

错误类型说明修改方法WhitespaceAfterCheck逗号、分号后面没有空格Eclipse格式化解决WhitespaceAroundCheck加号、等号周围没有包含空格Eclipse格式化解决LocalVariableNameCheck变量命名不规范手工修改变量名称JavadocTypeCheck类缺少注释手工为类添加注释 ConstantNameCheck 类型变量没有大写手工统一修改变量名

2、修改代码的工作量情况

我们也对被检查的项目统计了修改代码的工作量，一些项目的错误数看着非常的多，其实修改起来还是比较快的，一些空格相关的错误通过Eclipse格式化就可以自动修改完成，变量命名错误的问题也可以通过在Eclipse中一次修改完变量的所有引用解决。

表 2 各项目代码修改工作量

项目文件个数错误个数修改耗时(小时)

Dagger611 1.5

Emmagee925 1.5

Orange2168 2.5

UI自动测试项目402153

后台接口测试项目743694

3、不同类型项目的规范差异

含有测试代码的项目中常会使用TestNG等工具，存在@Test(groups ={ "pass", "online" })等语法，这时候})两个符号之间默认是紧跟的，这里}后面

需要空格的规则就有些不适用，会导致检查出来很多错误。另外一些开发项目中可能会存在直接引入的开源代码包，包名不是https://www.wendangku.net/doc/d516018398.html,ease开头，这种情况下，如果默认检查包名https://www.wendangku.net/doc/d516018398.html,ease开头的话会出现很多错误。所以规范在制定初稿后可以试用一段时间再确定最终版本，也可以去除一些确实不适合团队的规范。

4、发现的开发人员代码问题

在接口测试代码的检测过程中，我们也发现开发的一些代码在接口方法、参数命名等方面没有按照编码规范。

后续展望

1、杭研质量保障部制定统一编码规范， 部门内所有代码提交都能自动经过代码规范检查。

2、测试工程师熟悉编码规范检查相关工具/工作流程后，尝试帮助产品项目组提高编码规范检查效率。

3、Java之外的编程语言，比如C/C++，Ruby等，也可以考虑采用类似的高效方式检查编码规范。

侯本文

2012年1月毕业于北京航空航天大学，2月份入职网易

杭州研究院-质量保障部-性能测试组，从事杭研产品的

性能测试工作。参与过DDB、Lofter性能测试，目前主

要负责901网易云课堂的性能测试工作。

初步探索前端性能测试

WEB产品的前端页面加载速度是影响用户体验的重要因素。为了提升

页面的加载速度，让用户体验更顺畅，需要进行前端性能测试。

评估原则：

1. Yahoo 34条黄金法则

以Yahoo网站性能优化的34条黄金法则为原则，前端的性能优化主要从以下几个方面进行：

第一点：减少HTTP请求的数目，包含避免404页面、避免使用空内容的图片和请求、移除重复脚本和使用CSS Sprites（减少图像请求的有效方法）等。

第二点：使浏览器渲染更加流畅，通过分别优化HTML、JavaScript、CSS来实现。

第三点：优化单个HTTP请求，包含通过减少DNS查找次数、避免重定向等方式缩短请求时间；通过压缩文件、优化图片以及减少cookie大小等方式减少接收数据量大小；通过使用缓存AJAX结果、配置过期时间以及Etag等方式有效的利用缓存。

2. 度量页面速度的指标

页面的加载速度的度量主要有三个关键指标：

First Impression Time：从用户提交请求到第一时间观察到页面开始加载的时间，这是一项重要指标，该时间越短，用户越早看到浏览器中的内容，心理上的等待时间会越短。

OnLoad Time：从用户提交请求到浏览器触发OnLoad事件的时间，在该时间之前完成了页面初始化以及所有引用对象的下载。该时间是比较重要的性能优化对象，OnLoad Time越低，页面加载速度越快，用户等待时间越短。

Total Load Time：从用户提交请求到页面完全加载所消耗的总时间，为OnLoad Time加上OnLoad事件之后额外加载的内容所花费时间。

分析工具：

常用的前端页面分析工具有：YSlow、PageSpeed、Dynatrace。

YSlow

YSlow是完全基于Yahoo 34条黄金法则开发的浏览器插件，它选取了其中的23条规则作为基本规则集，同时用户可以定制自己的规则集进行评估

测试。支持Chrome和Firefox两个浏览器，Chrome下直接安装插件即可，Firefox上的YSlow插件需要基于Firebug使用。YSlow评分的结果通过Grade A到F显示，Grade A说明完全满足要求，Grade F说明存在很严重的问题。

PageSpeed

PageSpeed是Google开发的评价网页前端性能的插件，也以Yahoo提出的34条黄金法则为基准，但是在黄金法则的基础上进行了更人性化的选取，比如说并不是所有的网站都有经费使用CDN，故PageSpeed没有加入CDN检测这一条规则。同样可以支持Firefox和Chrome浏览器，和YSlow类似，Firefox 下的PageSpeed也需要Firebug的支持。PageSpeed是通过分数来评判页面的整体性能，对于每一个小规则分为四类评判：

高优先级（红色原点）：这些建议意味着相对小的开发成本就能换来非常大的潜在性能提升，你应该首要关注这些条目。

中优先级（红色三角形）：这些建议意味着较小的产出或者比较大的实施难度，你应当次要关注这些条目。

状况良好的或者低优先级的（绿色勾）：如果有显示相关建议的 (显示一个+号)，那他们或许只有非常小的产出，你可以在你完成了更高优先级的建议之后再来审视这些条目。

仅仅只是些信息（蓝色叹号），可能是这些条目无法在当前页面应用或者在测试过程中出了些小问题。

Dynatrace

DynaTrace Ajax Edition 是一个强大的底层追踪、前端性能分析工具，该工具不仅能够记录浏览器的请求在网络中的传输时间、前端页面的渲染时

间、DOM 方法执行时间以及 JavaScript 代码的解析和执行时间，还可以跟踪 JavaScript 从执行开始，经过本地的 XMLHttpRequest、发送网络请求、再到请求返回的全过程。它的评价包括Cache、网络、Server端、JavaScript代码四个大类，每个大类都有A~F六个等级。

案例分析：

1. 总体评估

对三个页面使用YSlow、PageSpeed以及Dynatrace进行总体评估，测试结果如下表：

页面YSlow Score PageSpeed Score Dynatrace Score

页面191 A9787 B

页面286 B9489 B

页面369 D6050 E

页面1：A（90分以上），表示该页面性能很好，基本完全满足页面的评估原则，可优化点很少。

页面2：B（80~90分），该页面存在一些不完全满足评估原则的优化点，可以进一步提高页面性能。

页面3：D（70~60分），该页面存在一些完全不满足评估原则的优化点，对该点进行优化，可以大幅度提升页面性能。

2. 34条法则案例

以上面的页面3作为案例，从每一条原则角度去分析哪些因素导致评分结

果没有满足要求。

从图1看到，PageSpeed中使用浏览器缓存、启用压缩、压缩JavaScript 三项都是红色圆点标记，这些建议意味着相对小的开发成本就能换来非常大的潜在性能提升，是应该首要关注的条目。YSlow的结果见图2，有6项的等级为F，跟PageSpeed的建议有部分重复。

图1 PageSpeed测试结果 图2 YSlow测试结果

根据这两个工具的结果数据，并结合公司的现状，给出以下优化建议：

? 开启Gzip压缩：

在nginx.conf中增加配置：gzip on，需要压缩的类型有：

gzip_types text/plain application/x-javascript text/css text/ javascript application/x-httpd-php image/jpeg image/gif image/png;

? 增加过期时间：

同样在Nginx对应虚拟站点中设置：

location ~ ^/(s|res|h)/{ root /home/space/webroot-study; expires 7d;}

? 减少HTTP请求：

这里Http请求过多的原因是因为前端CSS、JS没有进行打包合并，导致所有的存在的几十个甚至上百个JS都会请求，解决方法即使用公司的打包工具进行打包合并。

?配置Cookie free：

该项的意思是对于静态资源的请求是不需要传送cookie的，对于该原则的解决方法是把静态资源放在独立的域名下。

3. Dynatrace响应时间案例

我们选取了外国的一个网站，利用Dynatrace对页面速度进行分析，具体结果见图3。

图3 利用Dynatrace分析外国的一个网站

上图中红色表示该值严重超过了可接受范围，黄色表示警戒线，绿色表示结果良好。通过这些数据，可以看出该页面存在严重的性能问题，并且主要

时间消耗在建立连接和网络上。具体是哪些请求连接建立时间过长以及网络时间消耗过多，我们可以进入Dynatrace的Network视图和Time Line视图进一步查看。

分析上图标红处：

# of Request 192 ：该页面请求数目过多。

Connect 5162ms ：连接时间过长，可能存在一些无法建立连接的请求，需要进入Network视图进行细致定位。

Total Load Time 13650ms ：总加载时间过长，减去OnLoad Time后还剩下接近11s，说明OnLoad触发后，执行的其他请求过多过慢。

φ Wait 3537ms ：每个请求的平均等待时间过长，一是因为请求处理太慢，二是因为请求数目太多导致，需要优化。

结束语：

在本文中我们介绍了前端页面检测的原则以及工具，通过案例分析找到问题点并给出解决方案，这是前端性能测试的第一步，比较简单，但是收到了不错的效果。下一步我们将介绍前端性能测试自动化平台，通过Selenium + 测试工具 + ShowSlow平台 + Jenkins，实现前端性能测试的持续集成。

移动客户端测试10问

引言: 本文从测试人员的角度出发，提出了10个在测试移动App过程中需要考虑的问题，内容涉及App使用的平台和设备、数据操作、网络、基本操作、升级、报错和安全性等诸多问题，能为移动客户端测试人员提供一个基本的思维过程。

Q：App在什么平台上使用？App是干什么的？

A：每个App在不同的平台上会有不同的风格，也会有不同的特性和限制。主流的智能平台会提供相应操作系统的API以支持App运行，但是系统也会限制App的某些功能。即使同一款App在不同平台上运行效果也是千差万别，可能同个App的不同平台版本的实现功能也是有差异的。所以首先要确认

余琦

2009年加入网易，专注于移动产品测试，参与杭研的

多个移动产品测试，现在正在参与网易云阅读产品的

测试，混迹于移动互联网大潮之中，各种类型产品都有

涉猎兴趣浓厚，但是所学所想自感不够深入流于表面，

移动互联网技术发展日新月异，甚为惶恐，还得努力学

习。