web项目性能测试方案

web项目性能测试方案任务：测试JBOS郵境下UBSS项目的性能目标：测试缴费部分（前台缴费，IC卡充值）在并发数从 50-100递增的性能指标，不要求 对结果进行分析步骤：1搭建测试环境，要求与真实环境大概一致（关注在现有license情况下，UBSS系统支持的最大并发数）2准备数据脚本（SQL和存储过程）3. 准备测试脚本（Vuser scr i pts,scer）ario4进行性能测试测试范围针对UBSS项目，抽取对系统影响最大、最为典型的业务交易，构建场景，以此评判系统的 整体性能和实际性能表现a. 用户前台缴费b. 标准用户IC卡充值测试内容1. 基准测试概念：检查每个业务的基准响应时间（系统整体空闲，无额外进程运行并占用系统资源）方法：单用户运行业务多次，获取该业务的平均响应时间序号 功能名称 并发用户数 循环次数 操作间隔 循环间隔1-1前台缴费1100331-2IC 卡充值1100332. 单个交易负载测试概念：设定负载序列，并发用户数为X 20,30,50,.,收集系统单个交易在不同负载级别的性能表现方法：设置并发用户数等于X,关键步骤处设置并发点，每个用户运行 N个iteration，获取平均响应时间和吞吐量用户登陆方式：每 2秒登陆2个序号功能名称并发用户数循环次数操作间隔循环间隔2-1前台缴费550332-2前台缴费1050332-3前台缴费155033注：响应时间超过 30S2-4前台缴费205033注：阻塞，不进行测试2-5IC卡充值550332-6IC卡充值1050332-7IC卡充值1550332-8IC卡充值2050333. 组合交易负载测试概念：多个交易组合在一起，设定负载序列，并发数为X 20,30,50,.，收集系统在不同负载级别的性能表现方法：设置并发总数，各用户数按比例分配，每个用户运行N分钟，获取平均响应时间和吞吐量序号功能名称并发用户总数 比例 持续时间 操作间隔 循环间隔3-1前台缴费，IC卡充值52： 320m333-2前台缴费，IC卡充值102： 320m333-3前台缴费，IC卡充值152： 320m333-4前台缴费，IC卡充值202： 320m33性能指标1. 主机系统性能指标CPU 使用率 内存占用率 磁盘读写2. 数据库性能指标（略），可直接看应用系统所在主机情况3. 中间件指标（略），可直接看应用系统所在主机情况4. 业务指标平均响应时间 最长响应时间 吞吐率衩测系统环境描述1. 系统架构J2EE架构，多层结构，即展示层、应用服务层、数据服务层2. 主机环境主机名 型号主机IP CPU数内存磁盘用途数据库主机 192.168.1.8应用主机 192.168.1.33 1 2G3. 软件环境项目 信息 备注操作系统 window xp 应用主机linux 数据库主机 数据库 oracle10G 中间件 EOS5.3 for JBOSS 测试工具 LoadRunner8.1 破解4. 数据库环境 数据库实例 orcl数据规模用户数量： 837,060客户数量： 857,043帐户数量： 832,727 未缴费帐单： 403,839IC 卡用户信息： 404,607 发票数量： 1,169,600 用户表具信息： 846,999 计费策略： 845,771 已缴费帐单： 5,593,9515，测试客户机序号 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 参考资料缩写、术语解释性能测试(performanee testing)运行这些测试通常要确定程序运行有多 快，以便确定是否需要优化负载测试(Load testing)通过在面临很多资源要求的系统上运行， 攻击被测程序或系统可靠性测试(reliability testing)持续进行的性能测试，目标是发现短序列 程序测试遗漏的情况系统性能测试指南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 测试工具Ml( Mercury In teractiveUser Gen eratorMI ( Mercury In teractiveCon trollerMI( Mercury In teractive）公司的LoadRu nn er7.5.1创建虚拟用户脚本工具Virtual）公司的LoadRunner7.5.1创建、运行实际 场景工具）公司的LoadRunner7.5.1 分析测试结果工具 Analysis性能监视器（Microsoft Win2000自带）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 术语和缩写词缩写、术语解释性能测试( 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 GeneratorMI （ Mercury Interactive ）公司的 LoadRunner7.5.1 创建、运行实际场景工具 ControllerMI （ 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个用户操作测试结果分析：524可靠性测试任务描述连续运行时间建议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服务器的并发用户数 等于在线用户数。性能分析名词解释LoadRunnerTransactions （用户事务分析）用户事务分析是站在用户角度进行的基础性能分析。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 Seco nd （每秒点击次数）每秒点击次数”，即使运行场景过程中虚拟用户每秒向Web服务器提交的HTTP请求数。通过它可以评估虚拟用户产生的负载量， 如将其和 “平均事务响应时间 ”图比较， 可以查看点 击次数对事务性能产生的影响。通过对查看 “每秒点击次数 ”，可以判断系统是否稳定。系统 点击率下降通常表明服务器的响应速度在变慢，需进一步分析，发现系统瓶颈所在。2、Throughput （吞吐率）“吞吐率 ”显示的是场景运行过程中服务器的每秒的吞吐量。 其度量单位是字节， 表示虚拟用 在任何给定的每一秒从服务器获得的数据量。可以依据服务器的吞吐量来评估虚拟用户产生的负载量， 以及看出服务器在流量方面的处理 能力以及是否存在瓶颈。“吞吐率”图和“点击率 ”图的区别：吞吐率”图，是每秒服务器处理的HTTP申请数。“点击率 ”图，是客户端每秒从服务器获得的总数据量。3、HTTP Status Code Summary（ HTTP状态代码概要）“ HTT状态代码概要”显示场景或会话步骤过程中从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 Seco nd（每秒 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服务器返回的第一个缓冲之前的这段时间内，场景运行的每一秒中每个网页组件的服务器时间和网络时间。可以使用此图确定场景运行期间服务器或网络出现问题的时间点。&Downloader Component Size（KB）（已下载组件大小）已下载组件大小”图显示每个已经下载的网页组建的大小。通过它可以直接看出哪些组件比较大并需要进一步进行优化以提高性能。性能测试（并发负载压力）测试分析-简要篇在论坛混了多日，发现越来越多的 性能测试 工程师基本上都能够掌握利用测试工具来作负载 压力测试，但多数人对怎样去分析工具收集到的测试结果感到无从下手，下面我就把个人工作中的体会和收集到的有关资料整理出来，希望能对大家分析测试结果有所帮助。分析原则：? 具体问题具体分析（这是由于不同的应用系统，不同的测试目的，不同的性能关注点）? 查找瓶颈时按以下顺序，由易到难。服务器硬件瓶颈 -网络瓶颈（对局域网，可以不考虑）-服务器操作系统瓶颈（参数配置） -中间件瓶颈（参数配置，数据库， web 服务器等） -应用瓶颈（ SQL 语句、数据 库设计、业务逻辑、算法等）注：以上过程并不是每个分析中都需要的，要根据测试目的和要求来确定分析的深度。 对一些要求低的，我们分析到应用系统在将来大的负载压力（并发用户数、数据量）下，系 统的硬件瓶颈在哪儿就够了。? 分段排除法 很有效分析的信息来源：?1 根据场景运行过程中的错误提示信息?2 根据测试结果收集到的监控指标数据一错误提示分析分析实例：1 ?Error: Failed to connect to server“ 10.10 10.30080C8o0nnection?Error: timed out Error: Serverw10hafts1Sh80dow n the connection prematurely分析：?A、应用服务死掉。（小用户时：程序上的问题。程序上处理数据库的问题）?B、应用服务没有死（应用服务参数设置问题）例：在许多客户端连接 Weblogic 应用服务器被拒绝，而在服务器端没有错误显示，则有 可能是 Weblogic 中的 server 元素的 AcceptBacklog 属性值设得过低。如果连接时收到conn ection refused消息，说明应提高该值，每次增加25%?C、数据库的连接（1、在应用服务的性能参数可能太小了2、数据库启动的最大连接数（跟硬件的内存有关）2 Error: Page dow nl oad timeout （120 sec on ds） 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_ren dzvous（same;）在场景设计中，使用事务点集合策略。 以同时达到集合点百分率为标准， 同时释放所有正在 Run 的 Vuser。稳定性测试：已知系统高峰期使用人数、各事务操作频率等。设计综合测试场景，测试时将每个场景按照一定人数比率一起运行，模拟用户使用数年的情况。并监控在测试中，系统各性能指标在这种压力下是否能保持正常数值。事务响应时间是否会出现波动或随测试时间增涨而增加。系统是否会在测试期间内发生如宕机、应用中止等异常情况。根据上述测试中，各事务条件下出现性能拐点的位置，已确定稳定性测试并发用户人数。仍然根据实际测试服务器（加压机、应用服务器、数据服务器三方性能），估算最终并发用 户人数。场景设计思想：从稳定性测试场景的设计意义，应分多种情况考虑：针对同一个场景为例，以下以公文附件上传为例简要分析场景设计思想：1）场景一：已压力测试环境下性能拐点的并发用户为设计测试场景，目的验证极限压 力情况下测试服务器各性能指标。2） 场景二：根据压力测试环境中 CPU内存等指标选取服务器所能承受最大压力的50% 来确定并发用户数。测试方法：采用 1)Ramp Up-Load all Vusers simultaneously2）Duration-Run Indefinitely3）在 Sechedule-勾选 Initalize all Vusers before Run容错性测试：通过模拟一些非正常情况（如：服务器突然断电、网络时断时续、服务器 硬盘空间不足等） ，验证系统在发生这些情况时是否能够有自动处理机制以保障系统的正常 运行或恢复运行措施。如有HA （自动容灾系统），还可以专门针对这些自动保护系统进行另外的测试。验证其能否有效触发保护措施。问题排除性测试： 通过原有案例或经验判断， 针对系统中曾经发生问题或怀疑存在隐患 的模块进行验证测试。 验证这些模块是否还会发生同样的性能问题。 如： 上传附件模块的内 存泄露问题、地址本模块优化、开启Tivoli性能监控对0A系统性能的影响等等。测评测试是用于获取系统的关键性能指标点， 而进行的相关测试。 主要是针对预先没有 明确的预期测试结果， 而是要通过测试获取在特定压力场景下的性能指标 （如：事务响应时 间、最大并发用户数等）。评测事务交易时间： 为获取某事务在特定压力下的响应时间而进行的测试活动。通过模拟已知客户高峰期的各压力值或预期所能承受的压力值，获取事务在这种压力下的响应时 间。评测事务最大并发用户数： 为获取某事务在特定系统环境下所能承受的最大并发用户数 而进行的测试活动。 通过模拟真实环境或直接采用真实环境， 评测在这种环境下事务所能承 受的最大并发用户数。判定标准阈值需预先定义（如响应时间，CPU占用率，内存占用率，已出现点击率峰值，已出现吞吐量峰值等）。评测系统最大并发用户数： 为获取整个系统所能够承受的最大并发用户数而进行的的测 试活动。 通过预先分析项目各主要模块的使用比率和频率， 定义各事务在综合场景中所占的 比率， 以比率方式分配各事务并发用户数。 模拟真实环境或直接采用真实环境， 评测在这种 环境下系统所能承受的最大并发用户数。判定标准阀值预先定义 （如响应时间，CPU占用率,内存占用率，已出现点击率峰值，已出现吞吐量峰值等）。取值标准以木桶法则为准（并发 数最小的事务为整个系统的并发数）。评测不同数据库数据量对性能的影响： 针对不同数据库数据量的测试， 将测试结果进行对比，分析发现数据库中各表的数据量对事务性能的影响。 得以预先判断系统长时间运行后， 或某些模块客户要求数据量较大时可能存在的隐患。问题定位测试在通过以上测试或用户实际操作已经发现系统中的性能问题或怀疑已存在性能问题。 需通过响应的测试场景重现问题或定义问题。 如有可能， 可以直接找出引起性 能问题所在的代码或模块。该类测试主要还是通过测试出问题的脚本场景， 并可以增加发现和检测的工具， 如开启 Tivoli 性能监控、开启 HeapDump 输出、 Linux 资源监控命令等。并在场景运行过程中辅以手 工测试。