web项目性能测试方案.docx
《web项目性能测试方案.docx》由会员分享,可在线阅读,更多相关《web项目性能测试方案.docx(26页珍藏版)》请在冰豆网上搜索。
web项目性能测试方案
web项目性能测试方案
任务:
测试JBOSS环境下UBSS项目的性能
目标:
测试缴费部分(前台缴费,IC卡充值)在并发数从50-100递增的性能指标,不要求对结果进行分析
步骤:
1.搭建测试环境,要求与真实环境大概一致(关注在现有license情况下,UBSS系统支持的最大并发数)
2.准备数据脚本(SQL和存储过程)
3.准备测试脚本(Vuserscrīpts,scenario)
4.进行性能测试
测试范围
针对UBSS项目,抽取对系统影响最大、最为典型的业务交易,构建场景,以此评判系统的整体性能和实际性能表现
a.用户前台缴费
b.标准用户IC卡充值
测试内容
1.基准测试
概念:
检查每个业务的基准响应时间(系统整体空闲,无额外进程运行并占用系统资源)
方法:
单用户运行业务多次,获取该业务的平均响应时间
序号功能名称并发用户数循环次数操作间隔循环间隔
1-1 前台缴费 1 100 3 3
1-2 IC卡充值 1 100 3 3
2.单个交易负载测试
概念:
设定负载序列,并发用户数为X{20,30,50,....},收集系统单个交易在不同负载级别的性能表现
方法:
设置并发用户数等于X,关键步骤处设置并发点,每个用户运行N个iteration,获取平均响应时间和吞吐量
用户登陆方式:
每2秒登陆2个
序号功能名称并发用户数循环次数操作间隔循环间隔
2-1 前台缴费 5 50 3 3
2-2 前台缴费 10 50 3 3
2-3 前台缴费 15 50 3 3 注:
响应时间超过30S
2-4 前台缴费 20 50 3 3 注:
阻塞,不进行测试
2-5 IC卡充值 5 50 3 3
2-6 IC卡充值 10 50 3 3
2-7 IC卡充值 15 50 3 3
2-8 IC卡充值 20 50 3 3
3.组合交易负载测试
概念:
多个交易组合在一起,设定负载序列,并发数为X{20,30,50,....},收集系统在不同负载级别的性能表现
方法:
设置并发总数,各用户数按比例分配,每个用户运行N分钟,获取平均响应时间和吞吐量
序号 功能名称 并发用户总数 比例 持续时间操作间隔循环间隔
3-1 前台缴费,IC卡充值 5 2:
3 20m 3 3
3-2 前台缴费,IC卡充值 10 2:
3 20m 3 3
3-3 前台缴费,IC卡充值 15 2:
3 20m 3 3
3-4 前台缴费,IC卡充值 20 2:
3 20m 3 3
性能指标
1.主机系统性能指标
CPU使用率
内存占用率
磁盘读写
2.数据库性能指标(略),可直接看应用系统所在主机情况
3.中间件指标(略),可直接看应用系统所在主机情况
4.业务指标
平均响应时间
最长响应时间
吞吐率
衩测系统环境描述
1.系统架构
J2EE架构,多层结构,即展示层、应用服务层、数据服务层
2.主机环境
主机名 型号 主机IP CPU数 内存 磁盘 用途
数据库主机 192.168.1.8
应用主机 192.168.1.33 1 2G
3.软件环境
项目 信息 备注
操作系统 windowxp 应用主机
linux 数据库主机
数据库 oracle10G
中间件 EOS5.3forJBOSS
测试工具 LoadRunner8.1 破解
4.数据库环境
数据库实例 orcl
数据规模
用户数量:
837,060
客户数量:
857,043
帐户数量:
832,727
未缴费帐单:
403,839
IC卡用户信息:
404,607
发票数量:
1,169,600
用户表具信息:
846,999
计费策略:
845,771
已缴费帐单:
5,593,951
5,测试客户机
序号 IP 操作系统 配置 用途
1 192.168.1.30 windowxp pentium43.2GHzmemory1G generator+controoler
测试报告
由anilys自动生成
---------------------------------------------------------------
系统性能测试方案
1引言
1.1编写目的
编写本方案的目的是用于指导XXXX系统的性能测试,主要从测试环境、测试工具、测试策略、测试具体执行方法、任务与进度表等事先计划和设计。
1.2适用范围
XXXX系统性能测试组
XXXX系统开发组
XXXX系统性能优化组
1.3参考资料
缩写、术语
解释
性能测试(performancetesting)
运行这些测试通常要确定程序运行有多快,以便确定是否需要优化
负载测试(Loadtesting)
通过在面临很多资源要求的系统上运行,攻击被测程序或系统
可靠性测试(reliabilitytesting)
持续进行的性能测试,目标是发现短序列程序测试遗漏的情况
系统性能测试指南
1.4术语和缩写词
2系统介绍
3测试环境
3.1网络拓扑图
3.2硬件环境
3.3软件环境
4测试范围与主要内容
测试范围:
如:
XXXX系统各项性能指标,反应时间的性能测试、CPU、Memory的性能测试、负载的性能测试(压力测试)、可靠性测试
主要检测内容:
如:
1.典型应用的反应时间
2.客户端、服务器的CPU、Memory使用情况
3.服务器的响应速度
4.系统支持的最优负载数量
5.网络指标
6.系统可靠性测试
5测试工具和测试方法
5.1测试工具
MI(MercuryInteractive)公司的LoadRunner7.5.1创建虚拟用户脚本工具VirtualUserGenerator
MI(MercuryInteractive)公司的LoadRunner7.5.1创建、运行实际场景工具Controller
MI(MercuryInteractive)公司的LoadRunner7.5.1分析测试结果工具Analysis
性能监视器(MicroSoftWin2000自带)
5.2测试方法
5.2.1反应时间的性能测试
处理点或事件
期望的反应时间
实际反映时间平均值(至少3次)
上次或上版本实际反映时间平均值(至少3次)
测试结果分析:
5.2.2CPU、Memory的性能测试
条件:
1.客户端情况
2.应用服务器情况
3.数据库服务器情况
测试结果分析:
5.2.3负载的性能测试(压力测试)
输入/动作
输出/响应
能否正常运行
5个用户操作
10个用户操作
20个用户操作
30个用户操作
50个用户操作
……
测试结果分析:
5.2.4可靠性测试
任务描述
连续运行时间
故障发生的时刻
故障描述
统计分析
任务A无故障运行的平均时间间隔
(CPU小时)
测试结果分析:
5.2.5网络性能测试
对网络性能的测试,如网络流量、每秒采样数、网络延迟等。
6测试完成准则
系统满足各项性能要求、能满足实际使用情况并提供测试报告
7任务与进度表
8提交的文档和报告
XXXX系统性能测试方案
XXXX系统性能测试报告
XXXX系统性能测试脚本
软件系统性能测试方案
1引言
1.1编写目的
编写本方案的目的是用于指导XXXX系统的性能测试,主要从测试环境、测试工具、测试策略、测试具体执行方法、任务与进度表等事先计划和设计。
1.2适用范围
XXXX系统性能测试组
XXXX系统开发组
XXXX系统性能优化组
1.3参考资料
系统性能测试指南
1.4术语和缩写词
缩写、术语
解释
性能测试
(performancetesting)
运行这些测试通常要确定程序运行有多快,以便确定是否需要优化
负载测试
(loadtesting)
通过在面临很多资源要求的系统上运行,攻击被测程序或系统
可靠性测试
(reliabilitytesting)
持续进行的性能测试,目标是发现短序列程序测试遗漏的情况
……
2系统介绍
3测试环境
3.1网络拓扑图
3.2硬件环境
3.3软件环境
4测试范围与主要内容
测试范围:
如:
XXXX系统各项性能指标,反应时间的性能测试、CPU、Memory的性能测试、负载的性能测试(压力测试)、可靠性测试
主要检测内容:
如:
1.典型应用的反应时间
2.客户端、服务器的CPU、Memory使用情况
3.服务器的响应速度
4.系统支持的最优负载数量
5.网络指标
6.系统可靠性测试
5测试工具和测试方法
5.1测试工具
MI(MercuryInteractive)公司的LoadRunner7.5.1创建虚拟用户脚本工具VirtualUserGenerator
MI(MercuryInteractive)公司的LoadRunner7.5.1创建、运行实际场景工具Controller
MI(MercuryInteractive)公司的LoadRunner7.5.1分析测试结果工具Analysis
性能监视器(MicroSoftWin2000自带)
5.2测试方法
5.2.1反应时间的性能测试
处理点或事件
期望的反应时间
实际反映时间平均值(至少3次)
上次或上版本实际反映时间平均值(至少3次)
测试结果分析:
5.2.2CPU、Memory的性能测试
条件:
1.客户端情况
2. 应用服务器情况
3.数据库服务器情况
测试结果分析:
5.2.3负载的性能测试(压力测试
输入/动作
输出/响应
能否正常运行
10个用户操作
20个用户操作
30个用户操作
50个用户操作
100个用户操作
……
测试结果分析:
5.2.4可靠性测试
任务描述
连续运行时间
建议72小时
故障发生的时刻
故障描述
……统计分析
任务A无故障运行的平均时间间隔
(CPU小时)
任务A无故障运行的最小时间间隔
(CPU小时)
任务A无故障运行的最大时间间隔
(CPU小时)
测试结果分析:
5.2.5网络性能测试
对网络性能的测试,如网络流量、每秒采样数、网络延迟等。
6测试完成准则
系统满足各项性能要求、能满足实际使用情况并提供测试报告
7任务与进度表
8提交的文档和报告
XXXX系统性能测试方案
XXXX系统性能测试报告
XXXX系统性能测试脚本
成功的Web应用系统性能测试
性能测试是Web应用系统的一项重要质量保证措施。
在现实中,很多Web性能测试项目由于性能测试
需求定义不合理或不明确,导致性能测试项目不能达到预期目标或进度超期。
本文针对Web应用系统的
技术架构和系统使用特点,探讨如何有效实施性能测试过程,并重点介绍如何分析获得合理的性能测试
需求,最终对Web应用系统性能进行科学、准确的评估。
1引言
基于Web服务器的应用系统由于提供浏览器界面而无须安装,大大降低了系统部署和升级成本,得以普遍应用。
目前,很多企业的核心业务系统均是Web应用,但当Web应用的数据量和访问用户量日益增加,系统不得不面临性能和可靠性方面的挑战。
因此,无论是Web应用系统的开发商或最终用户,都要求在上线前对系统进行性能,室验实TI国中科学评价系统的性能,从而降低系统上线后的性能风险。
在很多性能测试项目中,由于不能合理定义系统的性能测试需求,不能建立和真实环境相符的负载模型,不能科学分析性能测试结果,导致性能测试项目持续时间很长或不能真正评价系统性能并提出性能改进措施。
本文在总结许多Web应用系统性能测试实践经验和教训的基础上,从与性能测试工具无关的角度介绍Web应用系统性能测试的方法和实施过程,以及如何定义合理的性能测试需求。
1.1术语定义
性能测试:
通过模拟大量浏览器客户端同时访问Web服务器,获得系统的性能数据。
虚拟用户:
模拟浏览器向Web服务器发送请求并接收响应的一个进程或线程。
响应时间:
浏览器向Web服务器提交一个请求到收到响应之间的间隔时间。
思考时间:
浏览器在收到响应后到提交下一个请求之间的间隔时间。
请求成功率:
Web服务器正确处理的请求数量和接收到的请求数量的比。
吞吐量:
单位时间内Web服务器成功处理的HTTP页面或HTTP请求数量。
在线用户:
用户通过浏览器访问登录Web应用系统后,并不退出该应用系统。
通常一个Web应用服务器的在线用户对应Web应用服务器的一个Session。
并发用户数:
Web服务器在一段时间内为处理浏览器请求而建立的HTTP连接数或生成的处理线程数。
当所有在线用户发送HTTP请求的思考时间为零时,Web服务器的并发用户数等于在线用户数。
性能分析名词解释——LoadRunner
Transactions(用户事务分析)
用户事务分析是站在用户角度进行的基础性能分析。
1、TransationSunmmary(事务综述)
对事务进行综合分析是性能分析的第一步,通过分析测试时间内用户事务的成功与失败情况,可以直接判断出系统是否运行正常。
2、AverageTransacitonResponseTime(事务平均响应时间)
“事务平均响应时间”显示的是测试场景运行期间的每一秒内事务执行所用的平均时间,通过它可以分析测试场景运行期间应用系统的性能走向。
例:
随着测试时间的变化,系统处理事务的速度开始逐渐变慢,这说明应用系统随着投产时间的变化,整体性能将会有下降的趋势。
3、TransactionsperSecond(每秒通过事务数/TPS)
“每秒通过事务数/TPS”显示在场景运行的每一秒钟,每个事务通过、失败以及停止的数量,使考查系统性能的一个重要参数。
通过它可以确定系统在任何给定时刻的时间事务负载。
分析TPS主要是看曲线的性能走向。
将它与平均事务响应时间进行对比,可以分析事务数目对执行时间的影响。
例:
当压力加大时,点击率/TPS曲线如果变化缓慢或者有平坦的趋势,很有可能是服务器开始出现瓶颈。
4、TotalTransactionsperSecond(每秒通过事务总数)
“每秒通过事务总数”显示在场景运行时,在每一秒内通过的事务总数、失败的事务总署以及停止的事务总数。
5、TransactionPerformanceSunmmary(事务性能摘要)
“事务性能摘要”显示方案中所有事务的最小、最大和平均执行时间,可以直接判断响应时间是否符合用户的要求。
重点关注事务的平均和最大执行时间,如果其范围不在用户可以接受的时间范围内,需要进行原因分析。
6、TransactionResponseTimeUnderLoad(事务响应时间与负载)
“事务响应时间与负载”是“正在运行的虚拟用户”图和“平均响应事务时间”图的组合,通过它可以看出在任一时间点事务响应时间与用户数目的关系,从而掌握系统在用户并发方面的性能数据,为扩展用户系统提供参考。
此图可以查看虚拟用户负载对执行时间的总体影响,对分析具有渐变负载的测试场景比较有用。
7、TransactionResponseTime(Percentile)(事务响应时间(百分比))
“事务响应时间(百分比)”是根据测试结果进行分析而得到的综合分析图,也就是工具通过一些统计分析方法间接得到的图表。
通过它可以分析在给定事务响应时间范围内能执行的事务百分比。
8、TransactionResponseTime(Distribution)(事务响应时间(分布))
“事务响应时间(分布)”显示在场景运行过程中,事务执行所用时间的分布,通过它可以了解测试过程中不同响应时间的事务数量。
如果系统预先定义了相关事务可以接受的最小和最大事务响应时间,则可以使用此图确定服务器性能是否在可以接受的范围内。
WebResources(Web资源分析)
Web资源分析是从服务器入手对Web服务器的性能分析。
1、HitsperSecond(每秒点击次数)
“每秒点击次数”,即使运行场景过程中虚拟用户每秒向Web服务器提交的HTTP请求数。
通过它可以评估虚拟用户产生的负载量,如将其和“平均事务响应时间”图比较,可以查看点击次数对事务性能产生的影响。
通过对查看“每秒点击次数”,可以判断系统是否稳定。
系统点击率下降通常表明服务器的响应速度在变慢,需进一步分析,发现系统瓶颈所在。
2、Throughput(吞吐率)
“吞吐率”显示的是场景运行过程中服务器的每秒的吞吐量。
其度量单位是字节,表示虚拟用在任何给定的每一秒从服务器获得的数据量。
可以依据服务器的吞吐量来评估虚拟用户产生的负载量,以及看出服务器在流量方面的处理能力以及是否存在瓶颈。
“吞吐率”图和“点击率”图的区别:
“吞吐率”图,是每秒服务器处理的HTTP申请数。
“点击率”图,是客户端每秒从服务器获得的总数据量。
3、HTTPStatusCodeSummary(HTTP状态代码概要)
“HTTP状态代码概要”显示场景或会话步骤过程中从Web服务器返回的HTTP状态代码数,该图按照代码分组。
HTTP状态代码表示HTTP请求的状态。
4、HTTPResponsesperSecond(每秒HTTP响应数)
“每秒HTTP响应数”是显示运行场景过程中每秒从Web服务器返回的不同HTTP状态代码的数量,还能返回其它各类状态码的信息,通过分析状态码,可以判断服务器在压力下的运行情况,也可以通过对图中显示的结果进行分组,进而定位生成错误的代码脚本。
5、PagesDownloaderperSecond(每秒下载页面数)
“每秒下载页面数”显示场景或会话步骤运行的每一秒内从服务器下载的网页数。
使用此图可依据下载的页数来计算Vuser生成的负载量。
和吞吐量图一样,每秒下载页面数图标是Vuser在给定的任一秒内从服务器接收到的数据量。
但是吞吐量考虑的各个资源极其大小(例,每个GIF文件的大小、每个网页的大小)。
而每秒下载页面数只考虑页面数。
注:
要查看每秒下载页数图,必须在R-T-S那里设置“每秒页面数(仅HTML模式)”。
6、RetriesperSecond(每秒重试次数)
“每秒重试次数”显示场景或会话步骤运行的每一秒内服务器尝试的连接次数。
在下列情况将重试服务器连接:
A、初始连接XX
B、要求代理服务器身份验证
C、服务器关闭了初始连接
D、初始连接无法连接到服务器
E、服务器最初无法解析负载生成器的IP地址
7、RetriesSummary(重试次数概要)
“重试次数概要”显示场景或会话步骤运行过程中服务器尝试的连接次数,它按照重试原因分组。
将此图与每秒重试次数图一起使用可以确定场景或会话步骤运行过程中服务器在哪个时间点进行了重试。
8、Connections(连接数)
“连接数”显示场景或会话步骤运行过程中每个时间点打开的TCP/IP连接数。
借助此图,可以知道何时需要添加其他连接。
例:
当连接数到达稳定状态而事务响应时间迅速增大时,添加连接可以使性能得到极大提高(事务响应时间将降低)。
9、ConnectionsPerSecond(每秒连接数)
“每秒连接数”显示方案在运行过程中每秒建立的TCP/IP连接数。
理想情况下,很多HTTP请求都应该使用同一连接,而不是每个请求都新打开一个连接。
通过每秒连接数图可以看出服务器的处理情况,就表明服务器的性能在逐渐下降。
10、SSLsPerSecond(每秒SSL连接数)
“每秒SSL连接数”显示场景或会话步骤运行的每一秒内打开的新的以及重新使用的SSL连接数。
当对安全服务器打开TCP/IP连接后,浏览器将打开SSL连接。
WebPageBreakdown(网页元素细分)
“网页元素细分”主要用来评估页面内容是否影响事务的响应时间,通过它可以深入地分析网站上那些下载很慢的图形或中断的连接等有问题的
元素。
1、WebPageBreakdown(页面分解总图)
“页面分解”显示某一具体事务在测试过程的响应情况,进而分析相关的事务运行是否正常。
“页面分解”图可以按下面四种方式进行进一步细分:
1)、DownloadTimeBreaddown(下载时间细分)
“下载时间细分”图显示网页中不同元素的下载时间,同时还可按照下载过程把时间进行分解,用不同的颜色来显示DNS解析时间、建立连接时间、第一次缓冲时间等各自所占比例。
2)、ComponentBreakdown(OverTime)(组件细分(随时间变化))
“组件细分”图显示选定网页的页面组件随时间变化的细分图。
通过该图可以很容易的看出哪些元素在测试过程中下载时间不稳定。
该图特别适用于需要在客户端下载控件较多的页面,通过分析控件的响应时间,很容易就能发现那些控件不稳定或者比较耗时。
3)、DownloadTimeBreakdown(OverTime)(下载时间细分(随时间变化))
“下载时间细分(随时间变化)”图显示选定网页的页面元素下载时间细分(随时间变化)情况,它