Web 性能测试需求分析方法
这是一个会议系统, 面向市场推广活动, 看到广告的人, 都可能会来参加该会议, 但是会议支持人数的上限 1000.
-- 从每小时访问量, 再根据业务逻辑, 推算各典型业务可能的压力. 推算出性能测试指标.
大量用户可能因为广告效应， 访问量比较大， 估计高峰时段, 每小时访问量： 2W ~ 5 W, 以 2w 为例。毛估：
30% 会直接离开
70% 会逗留 - 其中40% 浏览页面(8000左右)，10%（2000 左右） 加入/离开会议， 5%(1000 ) 填写登记表 ， 5%（1000） 填写调查表， 0.1 %(20) 安排会议。
因此典型业务的大概估计是：
关键页面： 每小时 8000, 每秒 2 page 左右. 首页加上进来马上离开的人，每秒最多 10 page. 模拟并发时， 并发用户之间时延 100 ms – 500ms的高斯时间. 操作动作时延以实际录制时延为准。
登陆: 包含加入会议有个对登记者的验证过程， 估计最大并发数在每秒10 个以内.
安排会议： 安排会议的并发量应该会非常少，估计最大并发数在每秒5 个以内.
加入会议： 通常我们一个会议人数限制在1000 人， 由于我们通常提早15分钟通知， 估计加入峰值在15 分钟内。 最多15 分钟(900s) 加入 1000 人。 最多每秒加 2 个人。并发用户时延可考虑在 100ms - 500ms 。
离开会议： 离开会议会产生高峰， 1000 人估计会在2 分钟内退出， 退出后的调查页面估计有20% 会在2 分钟内同时提交。 退出返回页面要求支持瞬间每秒 10 个并发。 调查页面支持每秒 10 并发.
根据以上分析，系统对并发量要求很低! 所以并发上几乎没有问题。 关键参数是响应时间和出错率。 我们需要类比在用户典型行为下的响应时间和出错率！比较同类网站的响应时间.
QA 的测试重点就是：
1. 关键模块的单独压力测试(没有时延)， 先保证不存在代码错误问题。
2. 典型用户行为的测试，重点关注响应时间和出错率。 实现性能优化.
3. 典型用户行为下的稳定性测试
4. 比较同类网站的响应时间.
第二篇：web项目性能测试方案
web项目性能测试方案
任务：
测试JBOSS环境下UBSS项目的性能
目标：测试缴费部分（前台缴费，IC卡充值）在并发数从50-100递增的性能指标，不要求对结果进行分析
步骤：
1.搭建测试环境，要求与真实环境大概一致（关注在现有license情况下，UBSS系统支持的最大并发数）
2.准备数据脚本（SQL和存储过程）
3.准备测试脚本（Vuser scrī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.软件环境
项目 信息 备注
操作系统 window xp 应用主机
linux 数据库主机
数据库 oracle10G
中间件 EOS5.3 for JBOSS
测试工具 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 window xp pentium4 3.2GHz memory 1G generator+controoler
测试报告
由anilys自动生成
---------------------------------------------------------------
系统性能测试方案
1引言
1.1编写目的
编写本方案的目的是用于指导XXXX系统的性能测试,主要从测试环境、测试工具、测试策略、测试具体执行方法、任务与进度表等事先计划和设计。
1.2适用范围
XXXX系统性能测试组
XXXX系统开发组
XXXX系统性能优化组
1.3参考资料
系统性能测试指南
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（Mercury Interactive）公司的LoadRunner7.5.1创建虚拟用户脚本工具Virtual User Generator
MI（Mercury Interactive）公司的LoadRunner7.5.1创建、运行实际场景工具Controller
MI（Mercury Interactive）公司的LoadRunner7.5.1分析测试结果工具Analysis
性能监视器（MicroSoft Win2000自带）
5.2测试方法
5.2.1反应时间的性能测试
测试结果分析：
5.2.2CPU、Memory的性能测试
条件：
1.客户端情况
2. 应用服务器情况
3.数据库服务器情况
测试结果分析：
5.2.3负载的性能测试（压力测试）
测试结果分析：
5.2.4可靠性测试
测试结果分析：
5.2.5网络性能测试
对网络性能的测试，如网络流量、每秒采样数、网络延迟等。
6测试完成准则
系统满足各项性能要求、能满足实际使用情况并提供测试报告
7任务与进度表
8提交的文档和报告
XXXX系统性能测试方案
XXXX系统性能测试报告
XXXX系统性能测试脚本
软件系统性能测试方案
1引言
1.1编写目的
编写本方案的目的是用于指导XXXX系统的性能测试,主要从测试环境、测试工具、测试策略、测试具体执行方法、任务与进度表等事先计划和设计。
1.2适用范围
XXXX系统性能测试组
XXXX系统开发组
XXXX系统性能优化组
1.3参考资料
系统性能测试指南
1.4术语和缩写词
缩写、术语
解释
性能测试
（performance testing）
运行这些测试通常要确定程序运行有多快，以便确定是否需要优化
负载测试
(load testing)
通过在面临很多资源要求的系统上运行，攻击被测程序或系统
可靠性测试
(reliability testing)
持续进行的性能测试，目标是发现短序列程序测试遗漏的情况
……
2系统介绍
3测试环境
3.1网络拓扑图
3.2硬件环境
3.3软件环境
4测试范围与主要内容
测试范围：
如：XXXX系统各项性能指标，反应时间的性能测试、CPU、Memory的性能测试、负载的性能测试（压力测试）、可靠性测试
主要检测内容：
如：
1. 典型应用的反应时间
2. 客户端、服务器的CPU、Memory使用情况
3. 服务器的响应速度
4. 系统支持的最优负载数量
5. 网络指标
6. 系统可靠性测试
5测试工具和测试方法
5.1测试工具
MI（Mercury Interactive）公司的LoadRunner7.5.1创建虚拟用户脚本工具Virtual User Generator
MI（Mercury Interactive）公司的LoadRunner7.5.1创建、运行实际场景工具Controller
MI（Mercury Interactive）公司的LoadRunner7.5.1分析测试结果工具Analysis
性能监视器（MicroSoft Win2000自带）
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、Transation Sunmmary（事务综述）
对事务进行综合分析是性能分析的第一步，通过分析测试时间内用户事务的成功与失败情况，可以直接判断出系统是否运行正常。
2、Average Transaciton Response Time（事务平均响应时间）
“事务平均响应时间”显示的是测试场景运行期间的每一秒内事务执行所用的平均时间，通过它可以分析测试场景运行期间应用系统的性能走向。
例：随着测试时间的变化，系统处理事务的速度开始逐渐变慢，这说明应用系统随着投产时间的变化，整体性能将会有下降的趋势。
3、Transactions per Second（每秒通过事务数/TPS）
“每秒通过事务数/TPS”显示在场景运行的每一秒钟，每个事务通过、失败以及停止的数量，使考查系统性能的一个重要参数。通过它可以确定系统在任何给定时刻的时间事务负载。分析TPS主要是看曲线的性能走向。
将它与平均事务响应时间进行对比，可以分析事务数目对执行时间的影响。
例：当压力加大时，点击率/TPS曲线如果变化缓慢或者有平坦的趋势，很有可能是服务器开始出现瓶颈。
4、Total Transactions per Second（每秒通过事务总数）
“每秒通过事务总数”显示在场景运行时，在每一秒内通过的事务总数、失败的事务总署以及停止的事务总数。
5、Transaction Performance Sunmmary（事务性能摘要）
“事务性能摘要”显示方案中所有事务的最小、最大和平均执行时间，可以直接判断响应时间是否符合用户的要求。
重点关注事务的平均和最大执行时间，如果其范围不在用户可以接受的时间范围内，需要进行原因分析。
6、Transaction Response Time Under Load（事务响应时间与负载）
“事务响应时间与负载”是“正在运行的虚拟用户”图和“平均响应事务时间”图的组合，通过它可以看出在任一时间点事务响应时间与用户数目的关系，从而掌握系统在用户并发方面的性能数据，为扩展用户系统提供参考。此图可以查看虚拟用户负载对执行时间的总体影响，对分析具有渐变负载的测试场景比较有用。
7、Transaction Response Time(Percentile)（事务响应时间(百分比)）
“事务响应时间(百分比)”是根据测试结果进行分析而得到的综合分析图，也就是工具通过一些统计分析方法间接得到的图表。通过它可以分析在给定事务响应时间范围内能执行的事务百分比。
8、Transaction Response Time(Distribution)（事务响应时间(分布)）
“事务响应时间(分布)”显示在场景运行过程中，事务执行所用时间的分布，通过它可以了解测试过程中不同响应时间的事务数量。如果系统预先定义了相关事务可以接受的最小和最大事务响应时间，则可以使用此图确定服务器性能是否在可以接受的范围内。
Web Resources（Web资源分析）
Web资源分析是从服务器入手对Web服务器的性能分析。
1、Hits per Second（每秒点击次数）
“每秒点击次数”，即使运行场景过程中虚拟用户每秒向Web服务器提交的HTTP请求数。
通过它可以评估虚拟用户产生的负载量，如将其和“平均事务响应时间”图比较，可以查看点击次数对事务性能产生的影响。通过对查看“每秒点击次数”，可以判断系统是否稳定。系统点击率下降通常表明服务器的响应速度在变慢，需进一步分析，发现系统瓶颈所在。
2、Throughput（吞吐率）
“吞吐率”显示的是场景运行过程中服务器的每秒的吞吐量。其度量单位是字节，表示虚拟用在任何给定的每一秒从服务器获得的数据量。
可以依据服务器的吞吐量来评估虚拟用户产生的负载量，以及看出服务器在流量方面的处理能力以及是否存在瓶颈。
“吞吐率”图和“点击率”图的区别：
“吞吐率”图，是每秒服务器处理的HTTP申请数。
“点击率”图，是客户端每秒从服务器获得的总数据量。
3、HTTP Status Code Summary（HTTP状态代码概要）
“HTTP状态代码概要”显示场景或会话步骤过程中从Web服务器返回的HTTP状态代码数，该图按照代码分组。HTTP状态代码表示HTTP请求的状态。
4、HTTP Responses per Second（每秒HTTP响应数）
“每秒HTTP响应数”是显示运行场景过程中每秒从Web服务器返回的不同HTTP状态代码的数量，还能返回其它各类状态码的信息，通过分析状态码，可以判断服务器在压力下的运行情况，也可以通过对图中显示的结果进行分组，进而定位生成错误的代码脚本。
5、Pages Downloader per Second（每秒下载页面数）
“每秒下载页面数”显示场景或会话步骤运行的每一秒内从服务器下载的网页数。使用此图可依据下载的页数来计算Vuser生成的负载量。
和吞吐量图一样，每秒下载页面数图标是Vuser在给定的任一秒内从服务器接收到的数据量。但是吞吐量考虑的各个资源极其大小（例，每个GIF文件的大小、每个网页的大小）。而每秒下载页面数只考虑页面数。
注：要查看每秒下载页数图，必须在R-T-S那里设置“每秒页面数(仅HTML模式)”。
6、Retries per Second（每秒重试次数）
“每秒重试次数”显示场景或会话步骤运行的每一秒内服务器尝试的连接次数。
在下列情况将重试服务器连接：
A、初始连接未经授权
B、要求代理服务器身份验证
C、服务器关闭了初始连接
D、初始连接无法连接到服务器
E、服务器最初无法解析负载生成器的IP地址
7、Retries Summary（重试次数概要）
“重试次数概要”显示场景或会话步骤运行过程中服务器尝试的连接次数，它按照重试原因分组。将此图与每秒重试次数图一起使用可以确定场景或会话步骤运行过程中服务器在哪个时间点进行了重试。
8、Connections（连接数）
“连接数”显示场景或会话步骤运行过程中每个时间点打开的TCP/IP连接数。
借助此图，可以知道何时需要添加其他连接。
例：当连接数到达稳定状态而事务响应时间迅速增大时，添加连接可以使性能得到极大提高（事务响应时间将降低）。
9、Connections Per Second（每秒连接数）
“每秒连接数”显示方案在运行过程中每秒建立的TCP/IP连接数。
理想情况下，很多HTTP请求都应该使用同一连接，而不是每个请求都新打开一个连接。通过每秒连接数图可以看出服务器的处理情况，就表明服务器的性能在逐渐下降。
10、SSLs Per Second（每秒SSL连接数）
“每秒SSL连接数”显示场景或会话步骤运行的每一秒内打开的新的以及重新使用的SSL连接数。当对安全服务器打开TCP/IP连接后，浏览器将打开SSL连接。
Web Page Breakdown（网页元素细分）
“网页元素细分”主要用来评估页面内容是否影响事务的响应时间，通过它可以深入地分析网站上那些下载很慢的图形或中断的连接等有问题的
元素。
1、Web Page Breakdown（页面分解总图）
“页面分解”显示某一具体事务在测试过程的响应情况，进而分析相关的事务运行是否正常。
“页面分解”图可以按下面四种方式进行进一步细分：
1)、Download Time Breaddown（下载时间细分）
“下载时间细分”图显示网页中不同元素的下载时间，同时还可按照下载过程把时间进行分解，用不同的颜色来显示DNS解析时间、建立连接时间、第一次缓冲时间等各自所占比例。
2)、Component Breakdown(Over Time)（组件细分(随时间变化)）
“组件细分”图显示选定网页的页面组件随时间变化的细分图。通过该图可以很容易的看出哪些元素在测试过程中下载时间不稳定。该图特别适用于需要在客户端下载控件较多的页面，通过分析控件的响应时间，很容易就能发现那些控件不稳定或者比较耗时。
3)、Download Time Breakdown(Over Time)（下载时间细分(随时间变化)）
“下载时间细分(随时间变化)” 图显示选定网页的页面元素下载时间细分（随时间变化）情况，它非常清晰地显示了页面各个元素在压力测试过程中的下载情况。
“下载时间细分”图显示的是整个测试过程页面元素响应的时间统计分析结果，“下载时间细分(随时间变化)”显示的事场景运行过程中每一秒内页面元素响应时间的统计结果，两者分别从宏观和微观角度来分析页面元素的下载时间。
4)、Time to First Buffer Breakdown(Over Time)（第一次缓冲时间细分(随时间变化)）
“第一次缓冲时间细分(随时间变化)”图显示成功收到从Web服务器返回的第一次缓冲之前的这段时间，场景或会话步骤运行的每一秒中每个网页组件的服务器时间和网络时间（以秒为单位）。可以使用该图确定场景或会话步骤运行期间服务器或网络出现问题的时间。
First Buffer Time：是指客户端与服务器端建立连接后，从服务器发送第一个数据包开始计时，数据经过网络传送到客户端，到浏览器接收到第一个缓冲所用的时间。
2、Page Component Breakdown（页面组件细分）
“页面组件细分”图显示每个网页及其组件的平均下载时间（以秒为单位）。可以根据下载组件所用的平均秒数对图列进行排序，通过它有助于隔离有问题的组件。
3、Page Component Breakdown(Over Time)（页面组件分解(随时间变化)）
“页面组件分解(随时间变化)”图显示在方案运行期间的每一秒内每个网页及其组件的平均响应时间 （以秒为单位）。
4、Page Download Time Breakdown（页面下载时间细分）
“页面下载时间细分”图显示每个页面组件下载时间的细分，可以根据它确定在网页下载期间事务响应时间缓慢是由网络错误引起还是由服务器错误引起。
“页面下载时间细分”图根据DNS解析时间、连接时间、第一次缓冲时间、SSL握手时间、接收时间、FTP验证时间、客户端时间和错误时间来对每个组件的下载过程进行细分。
5、Page Download Time Breakdown(Over Time)（页面下载时间细分(随时间变化)）
“页面下载时间细分(随时间变化)”图显示方案运行期间，每一秒内每个页面组件下载时间的细分。使用此图可以确定网络或服务器在方案执行期间哪一时间点发生了问题。
“页面组件细分(随时间变化)”图和“页面下载时间细分(随时间变化)”图通常结合起来进行分析：首先确定有问题的组件，然后分析它们的下载过程，进而定位原因在哪里。
6、Time to First Buffer Breakdown（第一次缓冲时间细分）
“第一次缓冲时间细分”图显示成功收到从Web服务器返回的第一次缓冲之前的这一段时间内的每个页面组件的相关服务器/网路时间。如果组件的下载时间很长，则可以使用此图确定产生的问题与服务器有关还是与网络有关。
网络时间：定义为第一个HTTP请求那一刻开始，直到确认为止所经过的平均时间。
服务器时间：定义为从收到初始HTTP请求确认开始，直到成功收到来自Web服务器的一次缓冲为止所经过的平均时间。
7、Time to First Buffer Breakdown(Over Time)（第一次缓冲时间细分(随时间变化)）
“第一次缓冲时间细分(随时间变化)”图显示成功收到从Web服务器返回的第一个缓冲之前的这段时间内，场景运行的每一秒中每个网页组件的服务器时间和网络时间。可以使用此图确定场景运行期间服务器或网络出现问题的时间点。
8、Downloader Component Size(KB)（已下载组件大小）
“已下载组件大小”图显示每个已经下载的网页组建的大小。通过它可以直接看出哪些组件比较大并需要进一步进行优化以提高性能。
性能测试（并发负载压力）测试分析－简要篇
在论坛混了多日，发现越来越多的性能测试工程师基本上都能够掌握利用测试工具来作负载压力测试，但多数人对怎样去分析工具收集到的测试结果感到无从下手，下面我就把个人工作中的体会和收集到的有关资料整理出来，希望能对大家分析测试结果有所帮助。
分析原则：
? 具体问题具体分析（这是由于不同的应用系统，不同的测试目的，不同的性能关注点）
? 查找瓶颈时按以下顺序，由易到难。
服务器硬件瓶颈-〉网络瓶颈（对局域网，可以不考虑）-〉服务器操作系统瓶颈（参数配置）-〉中间件瓶颈（参数配置，数据库，web服务器等）-〉应用瓶颈（SQL语句、数据库设计、业务逻辑、算法等）
注：以上过程并不是每个分析中都需要的，要根据测试目的和要求来确定分析的深度。对一些要求低的，我们分析到应用系统在将来大的负载压力（并发用户数、数据量）下，系统的硬件瓶颈在哪儿就够了。
? 分段排除法 很有效
分析的信息来源：
?1 根据场景运行过程中的错误提示信息
?2 根据测试结果收集到的监控指标数据
一．错误提示分析
分析实例：
1 ?Error: Failed to connect to server “10.10.10.30:8080″: [10060] Connection
?Error: timed out Error: Server “10.10.10.30″ has shut down the connection prematurely
分析：
?A、应用服务死掉。
（小用户时：程序上的问题。程序上处理数据库的问题）
?B、应用服务没有死
（应用服务参数设置问题）
例：在许多客户端连接Weblogic应用服务器被拒绝，而在服务器端没有错误显示，则有可能是Weblogic中的server元素的AcceptBacklog属性值设得过低。如果连接时收到connection refused消息，说明应提高该值，每次增加25％
?C、数据库的连接
(1、在应用服务的性能参数可能太小了 2、数据库启动的最大连接数（跟硬件的内存有关）)
2 Error: Page download timeout (120 seconds) has expired
分析：可能是以下原因造成
?A、应用服务参数设置太大导致服务器的瓶颈
?B、页面中图片太多
?C、在程序处理表的时候检查字段太大多
二．监控指标数据分析
1．最大并发用户数：
应用系统在当前环境（硬件环境、网络环境、软件环境（参数配置））下能承受的最大并发用户数。
在方案运行中，如果出现了大于3个用户的业务操作失败，或出现了服务器shutdown的情况，则说明在当前环境下，系统承受不了当前并发用户的负载压力，那么最大并发用户数就是前一个没有出现这种现象的并发用户数。
如果测得的最大并发用户数到达了性能要求，且各服务器资源情况良好，业务操作响应时间也达到了用户要求，那么OK。否则，再根据各服务器的资源情况和业务操作响应时间进一步分析原因所在。
2．业务操作响应时间：
? 分析方案运行情况应从平均事务响应时间图和事务性能摘要图开始。使用“事务性能摘要”图，可以确定在方案执行期间响应时间过长的事务。
? 细分事务并分析每个页面组件的性能。查看过长的事务响应时间是由哪些页面组件引起的？问题是否与网络或服务器有关？
? 如果服务器耗时过长，请使用相应的服务器图确定有问题的服务器度量并查明服务器性能下降的原因。如果网络耗时过长，请使用“网络监视器”图确定导致性能瓶颈的网络问题
性能测试之场景设计思想
前段时间有幸收到珠海X公司性能题目，呵呵，以下是对公司产品性能测试的总结。个人认为有关性能测试场景问题，其实更佳着重于对性能测试目的考究。
验证测试是用于验证在特定的场景、时间、压力、环境和操作方式下系统能够正常的运行，服务器、应用系统和网络环境等软硬件设施还能否良好的支撑这些情况下用户的使用。验证性测试主要针对有明确的压力目标和预期结果，验证系统在这种压力下的各方面反映能够达到预期结果。
主要分以下几种：
压力测试：已知系统高峰期使用人数，验证各事务在最大并发数（通过高峰期人数换算）下事务响应时间能够达到客户要求。系统各性能指标在这种压力下是否还在正常数值之内。系统是否会因这样的压力导致不良反应（如：宕机、应用异常中止等）。
Ramp Up 增量设计：如并发用户为75人，系统注册用户为1500人，以5％－7％作为并发用户参考值。一般以每15s加载5人的方式进行增压设计，该数值主要参考测试加压机性能，建议Run几次。以事务通过率与错误率衡量实际加载方式。
Ramp Up增量设计目标： 寻找已增量方式加压系统性能瓶颈位置，抓住出现的性能拐点时机，一般常用参考Hits点击率与吞吐量、CPU、内存使用情况综合判断。模拟高峰期使用人数，如早晨的登录，下班后的退出，工资发送时的消息系统等。
另一种极限模拟方式，可视为在峰值压力情况下同时点击事务操作的系统极限操作指标。加压方式不变，在各脚本事务点中设置同集合点名称（如：lr_rendzvous("same"
;）在场景设计中，使用事务点集合策略。以同时达到集合点百分率为标准，同时释放所有正在Run的Vuser。
稳定性测试：已知系统高峰期使用人数、各事务操作频率等。设计综合测试场景，测试时将每个场景按照一定人数比率一起运行，模拟用户使用数年的情况。并监控在测试中，系统各性能指标在这种压力下是否能保持正常数值。事务响应时间是否会出现波动或随测试时间增涨而增加。系统是否会在测试期间内发生如宕机、应用中止等异常情况。
根据上述测试中，各事务条件下出现性能拐点的位置，已确定稳定性测试并发用户人数。仍然根据实际测试服务器（加压机、应用服务器、数据服务器三方性能），估算最终并发用户人数。
场景设计思想：从稳定性测试场景的设计意义，应分多种情况考虑：
针对同一个场景为例，以下以公文附件上传为例简要分析场景设计思想：
1）场景一：已压力测试环境下性能拐点的并发用户为设计测试场景，目的验证极限压力情况下测试服务器各性能指标。
2）场景二：根据压力测试环境中CPU、内存等指标选取服务器所能承受最大压力的50%来确定并发用户数。
测试方法：采用1)Ramp Up-Load all Vusers simultaneously
2)Duration-Run Indefinitely
3)在Sechedule-勾选Initalize all Vusers before Run
容错性测试：通过模拟一些非正常情况（如：服务器突然断电、网络时断时续、服务器硬盘空间不足等），验证系统在发生这些情况时是否能够有自动处理机制以保障系统的正常运行或恢复运行措施。如有HA（自动容灾系统），还可以专门针对这些自动保护系统进行另外的测试。验证其能否有效触发保护措施。
问题排除性测试：通过原有案例或经验判断，针对系统中曾经发生问题或怀疑存在隐患的模块进行验证测试。验证这些模块是否还会发生同样的性能问题。如：上传附件模块的内存泄露问题、地址本模块优化、开启Tivoli性能监控对OA系统性能的影响等等。
测评测试是用于获取系统的关键性能指标点，而进行的相关测试。主要是针对预先没有明确的预期测试结果，而是要通过测试获取在特定压力场景下的性能指标（如：事务响应时间、最大并发用户数等）。
评测事务交易时间：为获取某事务在特定压力下的响应时间而进行的测试活动。通过模拟已知客户高峰期的各压力值或预期所能承受的压力值，获取事务在这种压力下的响应时间。
评测事务最大并发用户数：为获取某事务在特定系统环境下所能承受的最大并发用户数而进行的测试活动。通过模拟真实环境或直接采用真实环境，评测在这种环境下事务所能承受的最大并发用户数。判定标准阈值需预先定义（如响应时间，CPU占用率，内存占用率，已出现点击率峰值，已出现吞吐量峰值等）。
评测系统最大并发用户数：为获取整个系统所能够承受的最大并发用户数而进行的的测试活动。通过预先分析项目各主要模块的使用比率和频率，定义各事务在综合场景中所占的比率，以比率方式分配各事务并发用户数。模拟真实环境或直接采用真实环境，评测在这种环境下系统所能承受的最大并发用户数。判定标准阀值预先定义（如响应时间，CPU占用率，内存占用率，已出现点击率峰值，已出现吞吐量峰值等）。取值标准以木桶法则为准（并发数最小的事务为整个系统的并发数）。
评测不同数据库数据量对性能的影响：针对不同数据库数据量的测试，将测试结果进行对比，分析发现数据库中各表的数据量对事务性能的影响。得以预先判断系统长时间运行后，或某些模块客户要求数据量较大时可能存在的隐患。
问题定位测试在通过以上测试或用户实际操作已经发现系统中的性能问题或怀疑已存在性能问题。需通过响应的测试场景重现问题或定义问题。如有可能，可以直接找出引起性能问题所在的代码或模块。
该类测试主要还是通过测试出问题的脚本场景，并可以增加发现和检测的工具，如开启Tivoli性能监控、开启HeapDump输出、Linux资源监控命令等。并在场景运行过程中辅以手工测试。