文章多数来自互联网,若有冒犯的地方,请朋友们说明下,我会及时删除该文章!

(一)性能测试从零开始——LoadRunner入门与提升

上一篇 / 下一篇  2011-04-19 10:39:13 / 个人分类:LoadRunner

(一)性能测试从零开始——LoadRunner入门与提升
 

第11章 定量分析及诊断——建立性能度量模型

  以loadrunner为主导的性能测试可以获知被测系统的基本性能信息,比如:

  ● 被测系统在指定环境下,是否达到预期性能指标?

  ● 被测系统是否存在性能瓶颈?

  这只是对被测系统的一个定性判断,而作为性能测试的专业人员,我们需要给客户更详细更有建设意义的信息,比如:

  ● 性能瓶颈存在于被测系统的哪个节点,模块甚至代码行?可以给出解决建议吗?

  ● 当前系统经过性能调整后,可以减少多少响应时间?

  ● 被测系统上线后,随着数据容量的增加和硬件环境的变化,是否可能遇到性能拐点,又如何应对?

  ● 如何在当前的开发测试过程中,避免此类的性能问题将来再次发生?

  等等。这些问题实际上促使性能测试进入了一个定量分析的层次。

  简单来说,定性分析主要是“发现问题”,而定量分析不但要“定位问题”,最好还能“解决问题”,甚至要在当下“避免问题”,在将来“预测问题”。

  对软件系统做性能定量分析是一个高级软件人员的优秀素质,这不仅仅是在Loadrunner层次上纯熟地使用技巧,更需要软件各个领域的深厚专业知识,而且还要有和各个团队角色耐心细致交流的能力。

11.1  实现性能度量的准备工作

11.1.1  性能度量

  显而易见,能够实现性能定量分析的前提是要有数据,而且是详细而全面的性能数据。就像一个医术高明的大夫,往往会在诊断前和病人谈话交流,在充分了解病人的体质、症状、病史之后,才能对症下药,因人施方。

  度量数据有哪些呢?

  1.拓扑节点度量数据

  针对一个B/S四层架构的系统,比较典型的有:

  ● 网络性能数据

  包括当前局域网网络带宽,测试过程中网络的平均流量,峰值流量,占用带宽百分比等。

  ● Web服务器HTTP请求性能数据

  包括HTTP服务器的基本配置、线程池数目、http Get/Post请求的个数、响应时间等。

  ● 应用服务器交易性能数据

  交易定义因具体应用而定,一般包括处理的transaction的个数,transaction的处理最大时间、平均时间等。

  ●数据库监控报表

  数据库的基本配置信息、topSQL、BreakDown等。

  等等。

  由上可见,节点度量数据一般都会在系统各个节点上进行采集。这是因为,度量分析的根本目的是将定性测试中得到的整个系统响应时间进行细分,需要知道到底哪个环节模块消耗的资源最大,占用的响应时间最长。我们能分析并定位瓶颈到什么层次,取决于度量数据采集点下钻到达的位置。

  2.基准环境度量数据

  在节点度量数据的基础上,将同样的性能测试场景运行在不同的软硬件基准环境下,得出系统的基准环境度量数据,它会反映当前软件系统在何种配置环境下获得最优的性能表现。

  比如,在不同数据容量配置下,对在线文件管理系统进行性能测试(如表11-1所示)。

11-1 数据容量性能度量

性能场景 

200K
基础数据 

400K
基础数据 

600K
基础数据 

800K
基础数据 

Upload File 

223 ms 

355 ms 

458 ms 

552 ms 

Download File 

84 

115 

151 

199 

Search File 

54 

61 

62 

66 

Delete File 

74 

77 

87 

90 

  3.周期迭加度量数据

  在节点度量数据的基础上,将同样的性能测试场景运行在软件产品生命周期中各个可测版本上,得出被测产品的周期迭加度量数据,它会反映当前软件系统随着版本的更新而性能变化的趋势。

  比如,在不同测试版本上,对在线文件管理系统进行性能测试(如表11-2所示)。

性能场景 

83版本 

831版本 

910日版本 

924日版本 

Upload File 

223 ms 

253 

254 

278 

Download File 

84 

97 

90 

97 

Search File 

74 

76 

78 

80 

Delete File 

54 

54 

55 

58 

11.1.2  度量方式

  有了度量数据后,我们将采用不同的方式对其进行分析,来达到性能度量的目的。

  1.使用下钻细分法进行瓶颈定位

  我们用层层下钻的方式来进行性能的定量分析

  一级下钻

  某交易的系统响应时间=客户端处理时间+网络时间+Web服务器时间+应用处理时间+数据库时间

  案例分析

  例子:比如某邮件系统的Web发送邮件的总共耗费时间为4秒,根据度量数据,进行一级下钻:

  ● 客户端处理时间:浏览器处理时间,忽略

  ● 网络响应时间:54ms,相比15S,可以忽略

  ● Web服务器时间:0.56S/Http Request

  ● SMTP服务邮件发送处理时间:未知

  ● 数据库处理时间:connect time+Sql parse time+ sql execute time=1.4S

  总响应时间=页面时间+网络时间+Web处理时间+SMTP邮件服务处理时间+数据库处理时间

  4S=0+0+0.56+ SMTP应用服务时间+1.4

  SMTP应用服务时间=40.561.4≈2S

  二级下钻

  下面,尝试将SMTP服务时间进一步下钻细分。

  SMTP服务架构如图11-1所示。

图11-1  SMTP Service Architecture

  大致可把SMTP处理分为几个阶段:

  SMTP服务时间=认证时间+SMTP Local Queue入队时间+Outbound处理时间

  在各个模块上进行监测,时间细分为2S≈0.02S+1.2S+0.7S。

  由于Job Queue上花费了1.2S,那么说明邮件队列还有调优的空间。

  2.使用正交图来预测性能拐点

  两个因素A和B,B的变化会导致A的变化,那么可以以A为纵轴,B为横轴,建立二维正交图来观察A和B之间的影响作用大小及发展趋势。

  比如在上面的基准环境度量数据例子中,A为性能响应时间,B为基础容量数据,以upload file测试案例为例,可以绘制如图11-2所示的曲线图。

图11-2  容量—性能变化曲线

  从以上曲线可知,随着数据容量的增加,性能响应时间增加幅度较少,这是一个斜率小于1的曲线,因此,可以预测在将来容量增加的一段时间内,应该不会存在容量拐点和瓶颈。

  在上面的周期迭加度量数据例子中,A为性能时间,而B为版本周期。以download  file测试案例为例,可以绘制如图11-3所示的曲线图。

  上面的曲线反映了一个问题,第二个版本相比第一个版本出现了较大幅度的性能衰退,而在第三个版本和第四个版本中得到解决,并加以控制。

图11-3  版本—性能变化曲线

  总结

  数据是性能量化分析最重要的基础和前提。要想做到量化分析,需要在不同的时间和空间内重复执行性能测试,并收集详细而全面的度量数据。在某种程度上来说,没有采集度量数据的性能测试是毫无意义的。

  案例分析  性能bug定量分析实际案例

  Bug标题:1.1版本升级到1.2后login action发生40%的性能衰减。

  测试环境:某Web订票系统1.2版本。

  场景描述:50用户ramp并发login运行一个小时,thinktime 500毫秒。

  测试结果:1.2版本Login Service花费时间为4.2秒,而1.1版本同样的场景案例则花费2.4秒。

  对1.2版本上采集的性能度量数据进行下钻细分,Oracle DB的AWR TOP SQL report捕捉到一条sql语句耗时达1.5秒。

  select username,password from ocs_data.auth_users where NLSSORT(username,'NLS_SORT=GENERIC_M_CI') = NLSSORT('ocsadmin', 'NLS_SORT=GENERIC_M_CI')

  对比1.1版本的AWR Report,发现这是一条1.2版本新引入的sql语句。1.1版本同样作用的sql语句为:

  select username,password from ocs_data.auth_users where username= 'ocsadmin'

  耗时仅为50毫秒。

  解决建议:

  新sql语句耗时时间较长,是由于where使用了新的字段表达式,而使得原有的字段索引没有排上用场。建议建立新的字段索引。

  Bug总结:

  上面的bug分析逻辑清楚,直接揭示瓶颈根源,定位到了语句级别。能完成这样的量化分析,依赖于以下几个基础条件:

  ● 节点数据采集点详细而全面,在oracle DB上使用awr 进行sql语句采集,这为sql语句性能分析提供了数据基础。

  ● 周期数据持续采集形成对比基准。在1.1和1.2版本中持续进行性能回归测试,直接将新旧版本上top sql进行对比,这为瓶颈定位提供了逻辑条件。

 


TAG:

FighterLqs的个人空间 引用 删除 FighterLqs   /   2013-10-22 10:00:47
5
fuping860731的个人空间 引用 删除 fuping860731   /   2011-04-19 18:24:30
我之前是做开发的,现在刚转做测试,想在自动化测试上有所发展,共同学习
jenery的个人空间 引用 删除 jenery   /   2011-04-19 17:15:51
5
七星海棠的个人空间 引用 删除 七星海棠   /   2011-04-19 16:48:28
5
 

评分:0

我来说两句

congyu15

congyu15

自动化测试工具学习ING,做了近两年的手工测试,对于自动化测试一知半解。希望同行的兄弟姐妹们能够帮助我、指导我学习自动化测试工具,你们的一字一句都是我成长的源泉。感谢你们的无私奉献、乐此不疲!

日历

« 2024-03-22  
     12
3456789
10111213141516
17181920212223
24252627282930
31      

数据统计

  • 访问量: 33364
  • 日志数: 126
  • 建立时间: 2010-11-24
  • 更新时间: 2012-02-17

RSS订阅

Open Toolbar