性能测试从零开始.docx

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

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

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

被测系统在指定环境下，是否达到预期性能指标？

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

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

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

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

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

如何在当前的开发测试过程中，避免此类的性能问题将来再次发生？等等。这些问题实际上促使性能测试进入了一个定量分析的层次。

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

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

实现性能度量的准备工作

性能度量

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

度量数据有哪些呢？

拓扑节点度量数据

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

网络性能数据

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

Web服务器HTTP请求性能数据

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

应用服务器交易性能数据

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

数据库监控报表

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

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

基准环境度量数据

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

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

性能场景200K400K600K800K

性能场景

200K

400K

600K

800K

基础数据

基础数据

基础数据

基础数据

UploadFile

223ms

355ms

458ms

552ms

DownloadFile

84

115

151

199

SearchFile

54

61

62

66

DeleteFile

74

77

87

90

周期迭加度量数据

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

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

性能场景

8月3日版本

8月31日

版本

9月10日版本

9月24日版本

UploadFile

223ms

253

254

278

DownloadFile

84

97

90

97

SearchFile

74

76

78

80

DeleteFile

54

54

55

58

度量方式

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

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

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

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

案例分析

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

客户端处理时间：浏览器处理时间，忽略

网络响应时间：54ms，相比15S，可以忽略

Web服务器时间：0.56S/HttpRequest

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

数据库处理时间：connecttime+Sqlparsetime+sqlexecutetime=1.4S

总响应时间=页面时间+网络时间+Web处理时间+SMTP