性能测试培训——基础知识

性能测试培训（一）

——基础知识

1.软件性能测试的概念

1.1软件性能与性能测试

软件性能：覆盖面广泛，对一个系统而言，包括执行效率、资源占用、稳定性、安全性、兼容性、可扩展性、可靠性等。

性能测试：为保证系统运行后的性能能够满足用户需求，而开展的一系列的测试组织工作。

1.2不同角色对软件性能的认识

用户眼中的软件性能：

?软件对用户操作的响应时间

如用户提交一个查询操作或打开一个web页面的链接等。

?业务可用度，或者系统的服务水平如何

管理员眼中的软件性能：

开发人员眼中的软件性能：

1.3性能测试的对象

服务器端：

?负载均衡系统；

?服务器（单机、双机热备、集群）；

?存储系统、灾备中心；

?数据库、中间件。

网络端：

?核心交换设备、路由设备；

?广域网络、专线网络、局域网络、拨号网络等；

应用系统：

由此可见，性能测试是一个系统性的工作，被测对象包括系统运行时使用的所有软硬件。但在实际操作时，将根据项目的特点，选择特定的被测对象。

1.4性能测试的目标

评价系统当前的性能：

?系统刚上线使用，即处于试运行时，用户需要确定当前系

统是否满足验收要求；

?系统已经运行一段时间，如何保证一直具有良好的性能。分析系统瓶颈、优化系统：

?用户提出业务操作响应时间长，如何定位问题，调整性能；

?系统运行一段时间后，速度变慢，如何寻找瓶颈，进而优

化性能。

预见系统未来性能、容量可扩充性：

?系统用户数增加或业务量增加时，当前系统是否能够满足

需求，如果不能，需要进行哪些调整？提高硬件配置？增

加应用服务器？提高数据库服务器的配置？或者是需要对

代码进行调整？

1.5性能测试的分类

按照测试压力级别：

?负载测试；

?压力测试；

按照测试实施目标：

?应用在客户端的测试；

?应用在网络的测试；

?应用在服务器端的测试；

按照测试实施策略：

?并发性能测试；

?疲劳强度测试；

?大数据量测试；

?失效恢复测试。

其他分类：

?并发测试；

?执行效率测试；

?资源占用测试；

?容量测试；

?网络测试；

?稳定性测试。

1.5.1负载测试

负载测试是为了确定系统在各种工作负载下的性能，目标是测试当负载逐渐增加时，系统的性能变化，并最终确定在满足性能指标的情况下，系统所能承受的最大负载量。

如：系统在保证一定的响应时间（或稳定性）的情况下，能够允许多少并发用户访问。

系统的各项指标包括：响应时间、CPU负载、内存使用等如何决定系统的性能。

1.5.2压力测试

压力测试通过确定一个系统的瓶颈或者不能接受的性能点，来获得系统能提供的最大的服务级别的测试。通俗的讲，压力测试是为了发现在什么条件下，应用程序的性能会变得不可接受。

1.5.3并发性能测试

并发性能测试是一般意义上的负载压力测试。

1.5.4疲劳强度测试

疲劳强度测试是通过一定时间长度的负载压力测试，使测试者能够了解系统是否可以满足7*24小时运行的需要。疲劳强度测试属于可靠性测试的范畴。

1.5.5大数据量测试

大数据量测试是测试应用程序随着数据库数据量级数增加的情况下的性能表现。

1.5.6失效恢复测试

失效恢复测试是针对有冗余备份或负载均衡的系统来说的。检验当系统局部发生故障时，系统灾备措施是否可以正常启动，用户是否可以继续使用。通过实施失效恢复测试，评估系统的健壮性和可恢复性。

2.性能测试策略

2.1.应用在客户端的测试

2.1.1.实现机制

通过在一台或几台PC机上模拟成百上千的虚拟用户同时执行业务的情景，对应用程序进行测试。通过可重复的、真实的测试，能够彻底的度量应用程序的性能，确定问题所在。

2.1.2.常用工具

?商业测试工具

LoadRunner, Rational Robot，QALoad,Silk

Performor

?开源（OpenSource）测试工具

Apache Jmeter,OpentSTA…

?自主开发测试程序或者测试工具

2.1.

3.自动化性能测试的优势

2.1.4.测试工具使用的基本步骤

?录制业务流程，形成测试脚本；

?修改调试脚本；

?执行性能测试。

2.1.5.测试脚本执行策略

性能测试脚本应本着一一对应的原则录制业务，即一个脚本仅针对一项业务录制。

测试脚本执行策略应按照以下顺序执行：

1、单一脚本单用户执行；

2、单一脚本多用户执行；

3、采用增殖的方式集成混合脚本，且仅使用单用户执行；

4、混合脚本多用户执行。

2.2.应用在网络的测试

2.2.1.网络仿真技术

网络仿真技术的作用是模拟网络的吞吐量、延时、抖动、错包、丢包等性能特性，从而在测试环境下就可以得到设备或软件在实际的网络环境下的表现，并在发现性能问题时，对每个数据包进行分析，从而可以快速的找到问题所在。

2.2.2.网络性能监控

2.2.2.1.测试目标

?分析关键应用程序的性能；

?定位问题的根源是在客户端、服务器、应用程序还是网络；

?哪些应用程序占用大量带宽；

?哪些应用程序导致系统瓶颈或资源竞争；

?哪些应用程序产生了最大的网络流量。

2.2.2.2.常用工具

?Compuware：Network Vantage

?HP：Network Node Manager

?IBM:Tivoli

2.2.2.

3.工作原理

在客户端、应用服务器端、数据库服务器端等处部署捕捉点采集数据，并利用管理工具对采集到的数据进行分析。

?捕捉点：Agent被动监听数据包来实现实时数据采集

?分析：Agent Manager完成对所跟踪到的数据的分析

2.2.2.4.响应时间的计算

上图为响应时间的示意图。图中共设置四个捕捉点，客户端在第0秒发出请求，服务器在第0.31秒接收到客户端的请求，服务器响应请求后，在第2.11秒时发送响应结果，客户端在第3秒时接收到响应结果。因此，上图中的响应时间应为3秒。

注意，在应用逻辑路径上多点数据采集，以便于在任何两个节点间进行数据整合，测量分段的响应时间，分析应用故障。

2.2.2.5.实现方法

?探针

采集、存储数据，并根据应用对数据进行分类。设置的原则是根据网络组成和监控要求。

?探针管理器

管理配置探针，设定数据采集与上传时间，汇总收集的数据。

?时间服务器

对探针进行时针同步

?交互界面

数据展示平台

2.3.应用在服务器端的测试

2.3.1.对服务器操作系统的监控

对服务器操作系统的监控内容如下：

?CPU

?内存& SWAP

?磁盘管理

?网络

?文件系统

?活动的进程

2.3.2.对数据库的监控

对数据库的监控内容如下：

?监控数据库系统中关键的资源

?监测读写页面的使用情况

?监控超出共享内存缓冲区的操作数

?监测上一轮询期间作业等待缓冲区的时间

?跟踪共享内存中物理日志和逻辑日志的缓冲区的使用

率

?监控磁盘的数据块使用情况以及被频繁读写的热点区

域

?监控用户事务或者表空间监控事务日志

?监控数据库锁资源

?监测关键业务的数据表的表空间增长

?监控SQL执行情况

2.3.3.对中间件的监控

对中间件的监控，需要分析具体的中间件的特性，以确定监控内容。如：IBM的MQ，则需要监控其Client信息、队列信息、服务信息等。

2.3.4.监控方法

?监控工具

spotslight、tivoli、nmon、siteview

?操作系统本身自带命令

如：vmstat ,iostat,netstat,top,topas

3.性能测试需求分析

3.1.原始需求与测试目标的制定

3.2.测试强度估算

80～20原理：每个工作日中80％的业务在20％的时间内完成。举例：

每年业务量集中在8个月，每个月20个工作日，每个工作日8小时，即每天80%的业务在1.6(8*0.2)小时完成。

去年全年处理业务约100万笔，其中15％的业务处理中每笔业务需对应用服务器提交7次请求；其中70％的业务处理中每笔业务需对应用服务器提交5次请求；其余15％的业务处理中每笔业务需对应用服务器提交3次请求。根据以往统计结果，每年的业务增量为

15％，考虑到今后3年业务发展的需要，测试需按现有业务量的两倍进行。

每年总的请求数：

(100x15%x7+100x70%x5+100x15%x3)x2=1000万次/年

每天请求数：

1000/160(8*20)=6.25万次/天

每秒请求数：

(62500x80%)/(8x3600x20%)=8.68次/秒

即服务器处理请求的能力应达到9次/秒

几个关键数据:

?全年业务总量；

?各类业务请求次数；

?各类业务所占百分比；

?交易发生时间；

?年业务增量。

3.3.测试需求分析方法

3.3.1.任务分布图

关注点：

?有哪些交易任务；

?在一天的某些特定时刻系统都有哪些主要操作。

根据上图所示，性能测试应选择黄色部分标识的业务场景及其业务强度；且分为两个测试场景执行。

3.3.2.交易混合图

关注点：

?高峰期有哪些操作？

?中间件操作有多少？数据库操作有多少？

?如果任务失败，那么商业风险有多少？

选择依据：

?高负载

?高吞吐量

?高数据库I/O

?高商业风险

3.3.3.用户概况分析

关注点：

?哪些任务是每个用户都要执行的?

?针对不同角色的用户，他们的任务是什么?

?针对每个用户，不同任务的比例如何?

如上图所示，此种方法可用于计算不同的用户所操作的业务种类以及业务种类间的分配比例。根据此图，可制定测试场景的执行策略。

4.性能测试工作组织流程4.1.性能测试前期调研

4.1.1.环境调研

?了解工作环境

?了解软硬件设备

?了解相关人员及职责

?了解项目背景

?了解进度计划

4.1.2.业务调研

?核心业务功能

?用户使用习惯

?业务交易量

?业务交易分布

?数据量/增量

4.1.3.系统调研

?系统架构

?开发语言

?通信协议

?实际使用情况

?物理部署

?操作系统

?关键参数

?数据库

?中间件

?软件部署结构

4.1.4.需求调研

测试目的：

?测试对象

?测试类型

测试指标：

?用户并发数

?事务吞吐率

?响应时间

?资源使用情况

?高可用

?可扩展性

?可靠／稳定性

?产品对比

4.2.性能测试方案设计

4.2.1.建立业务模型

?分析系统所可能存在的瓶颈和原因；

?分析历史交易数据来确定各业务交易类型所占的比例；

?对每一类业务的访问或交易，选取最有代表性的操作步骤；

?最终目的是建立一个能够逼真模拟系统实际运行场景的业

务模型；

4.2.2.建立数据模型

?依据业务模型准备测试数据和基础数据，具体的数据类型

和数据量需要根据选择的交易类别或性能测试场景设置而

定；

?数据容量符合实际运行情况；

?尽量模拟真实业务数据；

?能贯穿各相关系统，保证业务流程的顺畅正确；

4.2.3.建立监控模型

?性能测试的目的不仅仅是获得关键业务的性能指标，同时

也要通过性能测试监控主机、数据库、中间件的各个性能

指标，从而发现性能瓶颈，为进一步的性能调优提供准确

的参考数据；

?监控对象及指标选择；

监控工具选择：

?监控程序对待测系统产生较小的压力；

?监控程序获取的数据便于分析和统计；

?监控分实时监控和非实时监控；

4.2.4.建立测试模型

?负载生成方式

?测试工具选择

?一般应该采取基准测试、单业务负载测试、混合负载测

试的顺序来执行。这样做的好处，在单业务负载测试是

就可以发现各个系统本身的性能缺陷，而混合负载测试

时将重点检查各个业务相互影响导致的性能缺陷；4.2.5.建立执行模型

系统的性能测试必须要用户、硬件厂家、中间件厂家、数据库厂家紧密配合，才能保证整个测试工作的成功。因此，只有建立一套规范的性能测试流程，明确各个角色的工作职责，才能使性能测试工作有序、高效的开展。

公司内部则需要软件开发工程师、数据库工程师、软件测试工程师、协调人员的紧密配合。

4.3.测试环境搭建

?测试环境＝硬件环境＋软件环境＋网络环境；

?硬件环境与系统实际运行的硬件环境尽量保持一致；

?软件版本与系统实际运行的软件版本必须保持一致；

?尽可能的使用独立网络；

?待测软件版本相对稳定；

?测试相关的数据从生产环境导出；

?测试环境是可用的；

当测试环境发生变化时，所得到的测试结果，仅能够作为测试环境变化后的参考，决不能作为推断依据。如：在当前的硬件环境下得到的测试结果，不能作为硬件提高后，肯定能够提高性能的推断依据。

注意事项：

?多次测试时，操作系统、被测软件、中间件、数据库应保

持相同的版本号；

?各类参数保持一致性；

?环境变化应做详细记录；

?应先分析测试结果，推断瓶颈原因，制订优化方案后，方

能修改测试环境。

4.4.测试数据准备

?基本数据类型

系统用户数据：登陆系统使用的帐户名-口令等，数量与虚拟用户数一致。

业务数据：每个虚拟用户模拟真实用户进行操作时使用到的数