web项目性能测试方案.docx

《web项目性能测试方案.docx》由会员分享，可在线阅读，更多相关《web项目性能测试方案.docx（16页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。

1、web 工程性能测试方案任务：测试 JBOSS 环境下 UBSS 工程的性能目标：测试缴费局部前台缴费，IC 卡充值在并发数从 50-100 递增的性能指标，不要求对结果进展分析步骤：1. 搭建测试环境，要求与真实环境或许全都关注在现有license 状况下，UBSS 系统支持的最大并发数2. 预备数据脚本SQL 和存储过程3. 预备测试脚本Vuser scrpts,scenario 4.进展性能测试测试范围针对 UBSS 工程，抽取对系统影响最大、最为典型的业务交易，构建场景，以此评判系统的整体性能和实际性能表现a. 用户前台缴费b. 标准用户 IC 卡充值测试内容1. 基准测试概念：检查每

2、个业务的基准响应时间系统整体空闲，无额外进程运行并占用系统资源 方法：单用户运行业务屡次，猎取该业务的平均响应时间序号 功能名称 并发用户数 循环次数 操作间隔 循环间隔1-1前台缴费1100331-2IC 卡充值1100332. 单个交易负载测试概念：设定负载序列，并发用户数为 X20,30,50,.,收集系统单个交易在不同负载级别的性能表现方法：设置并发用户数等于 X，关键步骤处设置并发点，每个用户运行 N 个 iteration，猎取平均响应时间和吞吐量用户登陆方式：每 2 秒登陆 2 个序号 功能名称 并发用户数 循环次数 操作间隔 循环间隔2-1前台缴费550332-2前台缴费105

3、0332-3前台缴费155033注：响应时间超过 30S2-4前台缴费205033注：堵塞，不进展测试2-5IC 卡充值550332-6IC 卡充值1050332-7IC 卡充值1550332-8IC 卡充值2050333. 组合交易负载测试概念：多个交易组合在一起，设定负载序列，并发数为X20,30,50,.，收集系统在不同负载级别的性能表现方法：设置并发总数，各用户数按比例安排，每个用户运行N 分钟，猎取平均响应时间和吞吐量序号功能名称并发用户总数 比例 持续时间 操作间隔 循环间隔3-1前台缴费，IC 卡充值52：320m333-2前台缴费，IC 卡充值102：320m333-3前台缴费

4、，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 12G3. 软件环境工程 信息 备注操作系统 window xp 应用主机linux

5、数据库主机数据库 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测试

6、报告由 anilys 自动生成系统性能测试方案1 引言1.1 编写目的编写本方案的目的是用于指导XXXX 系统的性能测试,主要从测试环境、测试工具、测试策略、测试具体执行方法、任务与进度表等事先打算和设计。1.2 适用范围XXXX 系统性能测试组XXXX 系统开发组XXXX 系统性能优化组1.3 参考资料缩写、术语性能测试performance testing 负载测试Load testing牢靠性测试reliability testing解释运行这些测试通常要确定程序运行有多快，以便确定是否需要优化通过在面临很多资源要求的系统上运行， 攻击被测程序或系统持续进展的性能测试，目标是觉察短序列程

7、序测试遗漏的状况系统性能测试指南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 测试工具MIMercury Interactive公司的 LoadRunner7.5.1 创立虚拟用户脚本工具V

8、irtual User GeneratorMIMercury Interactive公司的 LoadRunner7.5.1 创立、运行实际场景工具ControllerMIMercury Interactive公司的LoadRunner7.5.1 分析测试结果工具Analysis 性能监视器MicroSoft Win2023 自带5.2 测试方法5.2.1 反响时间的性能测试处理点或大事期望的反响时间实际反映时间平均值至少 3 次上次或上版本实际反映时间平均值至少 3 次测试结果分析： 5.2.2CPU、Memory 的性能测试条件：1. 客户端状况2. 应用效劳器状况3.数据库效劳器状况测试结

9、果分析：5.2.3 负载的性能测试压力测试输入/动作5 个用户操作10 个用户操作20 个用户操作30 个用户操作50 个用户操作测试结果分析：任务描述连续运行时间 故障发生的时刻故障描述任务A 无故障运行的平均时间间隔统计分析CPU 小时5.2.4 牢靠性测试输出/响应能否正常运行测试结果分析：5.2.5 网络性能测试对网络性能的测试，如网络流量、每秒采样数、网络延迟等。 6 测试完成准则系统满足各项性能要求、能满足实际使用状况并供给测试报告 7 任务与进度表8 提交的文档和报告XXXX 系统性能测试方案XXXX 系统性能测试报告XXXX 系统性能测试脚本软件系统性能测试方案1 引言1.1

10、编写目的编写本方案的目的是用于指导 XXXX 系统的性能测试,主要从测试环境、测试工具、测试策略、测试具体执行方法、任务与进度表等事先打算和设计。1.2 适用范围XXXX 系统性能测试组XXXX 系统开发组XXXX 系统性能优化组1.3 参考资料系统性能测试指南1.4 术语和缩写词缩写、术语解释性能测试performance testing运行这些测试通常要确定程序运行有多快，以便确定是否需要优化负载测试(load testing)通过在面临很多资源要求的系统上运行，攻击被测程序或系统牢靠性测试(reliability testing)持续进展的性能测试，目标是觉察短序列程序测试遗漏的状况2

11、系统介绍3 测试环境3.1 网络拓扑图3.2 硬件环境3.3 软件环境4 测试范围与主要内容测试范围：如：XXXX 系统各项性能指标，反响时间的性能测试、CPU、Memory 的性能测试、负载的性能测试压力测试、牢靠性测试主要检测内容： 如：1. 典型应用的反响时间2. 客户端、效劳器的 CPU、Memory 使用状况3. 效劳器的响应速度4. 系统支持的最优负载数量5. 网络指标6. 系统牢靠性测试5 测试工具和测试方法5.1 测试工具MIMercury Interactive公司的 LoadRunner7.5.1 创立虚拟用户脚本工具Virtual User GeneratorMIMerc

12、ury Interactive公司的 LoadRunner7.5.1 创立、运行实际场景工具 Controller MIMercury Interactive公司的 LoadRunner7.5.1 分析测试结果工具 Analysis性能监视器MicroSoft Win2023 自带5.2 测试方法5.2.1 反响时间的性能测试处理点或大事期望的反响时间实际反映时间平均值至少 3 次上次或上版本实际反映时间平均值至少3 次 测试结果分析：5.2.2 CPU、Memory 的性能测试条件：1. 客户端状况2. 应用效劳器状况 3.数据库效劳器状况测试结果分析：5.2.3 负载的性能测试压力测试输入

13、/动作输出/响应能否正常运行10 个用户操作20 个用户操作30 个用户操作50 个用户操作100 个用户操作测试结果分析：5.2.4 牢靠性测试任务描述连续运行时间建议 72 小时故障发生的时刻故障描述统计分析任务A 无故障运行的平均时间间隔CPU 小时任务A 无故障运行的最小时间间隔CPU 小时任务A 无故障运行的最大时间间隔CPU 小时 测试结果分析：5.2.5 网络性能测试对网络性能的测试，如网络流量、每秒采样数、网络延迟等。6 测试完成准则系统满足各项性能要求、能满足实际使用状况并供给测试报告7 任务与进度表8 提交的文档和报告XXXX 系统性能测试方案XXXX 系统性能测试报告XX

14、XX 系统性能测试脚本成功的 Web 应用系统性能测试性能测试是 Web 应用系统的一项重要质量保证措施。在现实中，很多 Web 性能测试工程由于性能测试需求定义不合理或不明确，导致性能测试工程不能到达预期目标或进度超期。本文针对 Web应用系统的技术架构和系统使用特点，探讨如何有效实施性能测试过程，并重点介绍如何分析获得合理的性能测试需求，最终对 Web 应用系统性能进展科学、准确的评估。1 引言基于 Web 效劳器的应用系统由于供给扫瞄器界面而无须安装，大大降低了系统部署和升级本钱，得以普遍应用。目前，很多企业的核心业务系统均是Web 应用，但当Web 应用的数据量和访问用户量日益增加，系

15、统不得不面临 性能和牢靠性方面的挑战。因此，无论是Web 应用系统的开发商或最终用户，都要求在上线前对系统进展性能，室验实 TI 国中科学评价系统的性能，从而降低系统上线后的性能风险。在很多性能测试工程中，由于不能合理定义系统的性能测试需求，不能建立和真实环境相符的负载模型，不能科学分析性能测试结果，导致性能测试工程持续时间很长或不能真正评价系统性能并提出性能改进措施。本文在总结很多 Web 应用系统性能测试实践阅历和教训的根底上，从与性能测试工具无关的角度介绍 Web 应用系统性能测试的方法和实施过程，以及如何定义合理的性能测试需求。1.1 术语定义性能测试：通过模拟大量扫瞄器客户端同时访问

16、Web 效劳器，获得系统的性能数据。虚拟用户：模拟扫瞄器向 Web 效劳器发送恳求并接收响应的一个进程或线程。响应时间：扫瞄器向 Web 效劳器提交一个恳求到收到响应之间的间隔时间。思考时间：扫瞄器在收到响应后到提交下一个恳求之间的间隔时间。恳求成功率：Web 效劳器正确处理的恳求数量和接收到的恳求数量的比。吞吐量：单位时间内 Web 效劳器成功处理的 页面或 恳求数量。在线用户：用户通过扫瞄器访问登录 Web 应用系统后，并不退出该应用系统。通常一个Web 应用效劳器的在线用户对应 Web 应用效劳器的一个 Session。并发用户数：Web 效劳器在一段时间内为处理扫瞄器恳求而建立的 连接

17、数或生成的处理线程数。当全部在线用户发送 恳求的思考时间为零时，Web 效劳器的并发用户数等于在线用户数。性能分析名词解释LoadRunnerTransactions用户事务分析用户事务分析是站在用户角度进展的根底性能分析。1、Transation Sunmmary事务综述对事务进展综合分析是性能分析的第一步，通过分析测试时间内用户事务的成功与失败状况，可以直接推断出系统是否运行正常。2、Average Transaciton Response Time事务平均响应时间“事务平均响应时间”显示的是测试场景运行期间的每一秒内事务执行所用的平均时间，通过它可以分析测试场景运行期间应用系统的性能走向

18、。例：随着测试时间的变化，系统处理事务的速度开头渐渐变慢，这说明应用系统随着投产时间的变化，整体性能将会有下降的趋势。3、Transactions per Second每秒通过事务数/TPS“每秒通过事务数/TPS”显示在场景运行的每一秒钟，每个事务通过、失败以及停顿的数量， 使考察系统性能的一个重要参数。通过它可以确定系统在任何给定时刻的时间事务负载。分 析 TPS 主要是看曲线的性能走向。将它与平均事务响应时间进展比照，可以分析事务数目对执行时间的影响。例：当压力加大时，点击率/TPS 曲线假设变化缓慢或者有平坦的趋势，很有可能是效劳器开头消灭瓶颈。4、Total Transactions

19、 per Second每秒通过事务总数“每秒通过事务总数”显示在场景运行时，在每一秒内通过的事务总数、失败的事务总署以及停顿的事务总数。5、Transaction Performance Sunmmary事务性能摘要“事务性能摘要”显示方案中全部事务的最小、最大和平均执行时间，可以直接推断响应时间是否符合用户的要求。重点关注事务的平均和最大执行时间，假设其范围不在用户可以承受的时间范围内，需要进展缘由分析。6、Transaction Response Time Under Load事务响应时间与负载“事务响应时间与负载”是“正在运行的虚拟用户”图和“平均响应事务时间”图的组合，通过它可以看出在

20、任一时间点事务响应时间与用户数目的关系，从而把握系统在用户并发方面的性能数据，为扩展用户系统供给参考。此图可以查看虚拟用户负载对执行时间的总体影响，对分析具有渐变负载的测试场景比较有用。7、Transaction Response Time(Percentile)事务响应时间(百分比)“事务响应时间(百分比)”是依据测试结果进展分析而得到的综合分析图，也就是工具通过一些统计分析方法间接得到的图表。通过它可以分析在给定事务响应时间范围内能执行的事务百分比。8、Transaction Response Time(Distribution)事务响应时间(分布)“事务响应时间(分布)”显示在场景运行过

21、程中，事务执行所用时间的分布，通过它可以了解测试过程中不同响应时间的事务数量。假设系统预先定义了相关事务可以承受的最小和最大事务响应时间，则可以使用此图确定效劳器性能是否在可以承受的范围内。Web ResourcesWeb 资源分析Web 资源分析是从效劳器入手对 Web 效劳器的性能分析。1、Hits per Second每秒点击次数“每秒点击次数”，即使运行场景过程中虚拟用户每秒向Web 效劳器提交的 恳求数。通过它可以评估虚拟用户产生的负载量，如将其和“平均事务响应时间”图比较，可以查看点 击次数对事务性能产生的影响。通过对查看“每秒点击次数”，可以推断系统是否稳定。系统点击率下降通常说

22、明效劳器的响应速度在变慢，需进一步分析，觉察系统瓶颈所在。2、Throughput吞吐率“吞吐率”显示的是场景运行过程中效劳器的每秒的吞吐量。其度量单位是字节，表示虚拟用在任何给定的每一秒从效劳器获得的数据量。可以依据效劳器的吞吐量来评估虚拟用户产生的负载量，以及看出效劳器在流量方面的处理力量以及是否存在瓶颈。“吞吐率”图和“点击率”图的区分：“吞吐率”图，是每秒效劳器处理的 申请数。“点击率”图，是客户端每秒从效劳器获得的总数据量。 3、 Status Code Summary 状态代码概要“ 状态代码概要”显示场景或会话步骤过程中从 Web 效劳器返回的 状态代码数， 该图依据代码分组。

23、状态代码表示 恳求的状态。4、 Responses per Second每秒 响应数“每秒 响应数”是显示运行场景过程中每秒从 Web 效劳器返回的不同 状态代码的数量，还能返回其它各类状态码的信息，通过分析状态码，可以推断效劳器在压力下的运行状况，也可以通过对图中显示的结果进展分组，进而定位生成错误的代码脚本。5、s Downloader per Second每秒下载页面数“每秒下载页面数”显示场景或会话步骤运行的每一秒内从效劳器下载的网页数。使用此图可依据下载的页数来计算 Vuser 生成的负载量。和吞吐量图一样，每秒下载页面数图标是 Vuser 在给定的任一秒内从效劳器接收到的数据量。但

24、是吞吐量考虑的各个资源极其大小例，每个GIF 文件的大小、每个网页的大小。而每秒下载页面数只考虑页面数。注：要查看每秒下载页数图，必需在R-T-S 那里设置“每秒页面数(仅 HTML 模式)”。6、Retries per Second每秒重试次数“每秒重试次数”显示场景或会话步骤运行的每一秒内效劳器尝试的连接次数。在以下状况将重试效劳器连接：A、初始连接未经授权B、要求代理效劳器身份验证C、效劳器关闭了初始连接D、初始连接无法连接到效劳器E、效劳器最初无法解析负载生成器的IP 地址7、Retries Summary重试次数概要“重试次数概要”显示场景或会话步骤运行过程中效劳器尝试的连接次数，它

25、依据重试缘由分 组。将此图与每秒重试次数图一起使用可以确定场景或会话步骤运行过程中效劳器在哪个时间点进展了重试。8、Connections连接数“连接数”显示场景或会话步骤运行过程中每个时间点翻开的TCP/IP 连接数。借助此图，可以知道何时需要添加其他连接。例：当连接数到达稳定状态而事务响应时间快速增大时，添加连接可以使性能得到极大提高事务响应时间将降低。9、Connections Per Second每秒连接数“每秒连接数”显示方案在运行过程中每秒建立的TCP/IP 连接数。抱负状况下，很多 恳求都应当使用同一连接，而不是每个恳求都翻开一个连接。通过每秒连接数图可以看出效劳器的处理状况，就

26、说明效劳器的性能在渐渐下降。10、SSLs Per Second每秒 SSL 连接数“每秒 SSL 连接数”显示场景或会话步骤运行的每一秒内翻开的的以及重使用的SSL 连接数。当对安全效劳器翻开 TCP/IP 连接后，扫瞄器将翻开 SSL 连接。Web Breakdown网页元素细分“网页元素细分”主要用来评估页面内容是否影响事务的响应时间，通过它可以深入地分析网站上那些下载很慢的图形或中断的连接等有问题的元素。1、Web Breakdown页面分解总图“页面分解”显示某一具体事务在测试过程的响应状况，进而分析相关的事务运行是否正常。 “页面分解”图可以按下面四种方式进展进一步细分：1)、Do

27、wnload Time Breaddown下载时间细分“下载时间细分”图显示网页中不同元素的下载时间，同时还可依据下载过程把时间进展分 解，用不同的颜色来显示DNS 解析时间、建立连接时间、第一次缓冲时间等各自所占比例。2)、Component Breakdown(Over Time)组件细分(随时间变化)“组件细分”图显示选定网页的页面组件随时间变化的细分图。通过该图可以很简洁的看出哪 些元素在测试过程中下载时间不稳定。该图特别适用于需要在客户端下载控件较多的页面， 通过分析控件的响应时间，很简洁就能觉察那些控件不稳定或者比较耗时。3) 、Download Time Breakdown(Ov

28、er Time)下载时间细分(随时间变化)“下载时间细分(随时间变化)” 图显示选定网页的页面元素下载时间细分随时间变化状况，它格外清楚地显示了页面各个元素在压力测试过程中的下载状况。“下载时间细分”图显示的是整个测试过程页面元素响应的时间统计分析结果，“下载时间细分(随时间变化)”显示的事场景运行过程中每一秒内页面元素响应时间的统计结果，两者分别从宏观和微观角度来分析页面元素的下载时间。4) 、Time to First Buffer Breakdown(Over Time)第一次缓冲时间细分(随时间变化)“第一次缓冲时间细分(随时间变化)”图显示成功收到从 Web 效劳器返回的第一次缓冲之

29、前的这段时间，场景或会话步骤运行的每一秒中每个网页组件的效劳器时间和网络时间以秒 为单位。可以使用该图确定场景或会话步骤运行期间效劳器或网络消灭问题的时间。 First Buffer Time：是指客户端与效劳器端建立连接后，从效劳器发送第一个数据包开头计时， 数据经过网络传送到客户端，到扫瞄器接收到第一个缓冲所用的时间。2、 Component Breakdown页面组件细分“页面组件细分”图显示每个网页及其组件的平均下载时间以秒为单位。可以依据下载组件所用的平均秒数对图列进展排序，通过它有助于隔离有问题的组件。3、 Component Breakdown(Over Time)页面组件分解(

30、随时间变化)“页面组件分解(随时间变化)”图显示在方案运行期间的每一秒内每个网页及其组件的平均响应时间 以秒为单位。4、 Download Time Breakdown页面下载时间细分“页面下载时间细分”图显示每个页面组件下载时间的细分，可以依据它确定在网页下载期间事务响应时间缓慢是由网络错误引起还是由效劳器错误引起。“页面下载时间细分”图依据 DNS 解析时间、连接时间、第一次缓冲时间、SSL 握手时间、接收时间、FTP 验证时间、客户端时间和错误时间来对每个组件的下载过程进展细分。5、 Download Time Breakdown(Over Time)页面下载时间细分(随时间变化)“页面

31、下载时间细分(随时间变化)”图显示方案运行期间，每一秒内每个页面组件下载时间的细分。使用此图可以确定网络或效劳器在方案执行期间哪一时间点发生了问题。“页面组件细分(随时间变化)”图和“页面下载时间细分(随时间变化)”图通常结合起来进展分析：首先确定有问题的组件，然后分析它们的下载过程，进而定位缘由在哪里。6、Time to First Buffer Breakdown第一次缓冲时间细分“第一次缓冲时间细分”图显示成功收到从 Web 效劳器返回的第一次缓冲之前的这一段时间内的每个页面组件的相关效劳器/网路时间。假设组件的下载时间很长，则可以使用此图确定产生的问题与效劳器有关还是与网络有关。网络时

32、间：定义为第一个 恳求那一刻开头，直到确认为止所经过的平均时间。效劳器时间：定义为从收到初始 恳求确认开头，直到成功收到来自 Web 效劳器的一次缓冲为止所经过的平均时间。7、Time to First Buffer Breakdown(Over Time)第一次缓冲时间细分(随时间变化)“第一次缓冲时间细分(随时间变化)”图显示成功收到从 Web 效劳器返回的第一个缓冲之前的这段时间内，场景运行的每一秒中每个网页组件的效劳器时间和网络时间。可以使用此图确定场景运行期间效劳器或网络消灭问题的时间点。8、Downloader Component Size(KB)已下载组件大小“已下载组件大小”图

33、显示每个已经下载的网页组建的大小。通过它可以直接看出哪些组件比较大并需要进一步进展优化以提高性能。性能测试并发负载压力测试分析简要篇在论坛混了多日，觉察越来越多的性能测试工程师根本上都能够把握利用测试工具来作负载压力测试，但多数人对怎样去分析工具收集到的测试结果感到无从下手，下面我就把个人工作中的体会和收集到的有关资料整理出来，期望能对大家分析测试结果有所帮助。分析原则： 具体问题具体分析这是由于不同的应用系统，不同的测试目的，不同的性能关注点 查找瓶颈时按以下挨次，由易到难。效劳器硬件瓶颈-网络瓶颈对局域网，可以不考虑-效劳器操作系统瓶颈参数配置-中间件瓶颈参数配置，数据库，web 效劳器等

34、-应用瓶颈SQL 语句、数据库设计、业务规律、算法等注：以上过程并不是每个分析中都需要的，要依据测试目的和要求来确定分析的深度。 对一些要求低的，我们分析到应用系统在将来大的负载压力并发用户数、数据量下，系统的硬件瓶颈在哪儿就够了。 分段排解法 很有效分析的信息来源：1 依据场景运行过程中的错误提示信息2 依据测试结果收集到的监控指标数据一错误提示分析分析实例：1 Error: Failed to connect to server “10.10.10.30:8080: 10060 ConnectionError: timed out Error: Server “10.10.10.30 ha

35、s shut down the connection prematurely分析：A、应用效劳死掉。小用户时：程序上的问题。程序上处理数据库的问题B、应用效劳没有死应用效劳参数设置问题例：在很多客户端连接Weblogic 应用效劳器被拒绝，而在效劳器端没有错误显示，则有可能是 Weblogic 中的 server 元素的 AcceptBacklog 属性值设得过低。假设连接时收到connection refused 消息，说明应提高该值，每次增加25C、数据库的连接(1、在应用效劳的性能参数可能太小了 2、数据库启动的最大连接数跟硬件的内存有关) 2 Error: download timeo

36、ut (120 seconds) has expired分析：可能是以下缘由造成A、应用效劳参数设置太大导致效劳器的瓶颈B、页面中图片太多C、在程序处理表的时候检查字段太大多二监控指标数据分析 1最大并发用户数：应用系统在当前环境硬件环境、网络环境、软件环境参数配置下能承受的最大并发用户数。在方案运行中，假设消灭了大于 3 个用户的业务操作失败，或消灭了效劳器 shutdown 的状况，则说明在当前环境下，系统承受不了当前并发用户的负载压力，那么最大并发用户数就是前一个没有消灭这种现象的并发用户数。假设测得的最大并发用户数到达了性能要求，且各效劳器资源状况良好，业务操作响应时间也到达了用户要求

37、，那么 OK。否则，再依据各效劳器的资源状况和业务操作响应时间进一步分析缘由所在。2. 业务操作响应时间： 分析方案运行状况应从平均事务响应时间图和事务性能摘要图开头。使用“事务性能摘要”图，可以确定在方案执行期间响应时间过长的事务。 细分事务并分析每个页面组件的性能。查看过长的事务响应时间是由哪些页面组件引起的？问题是否与网络或效劳器有关？ 假设效劳器耗时过长，请使用相应的效劳器图确定有问题的效劳器度量并查明效劳器性能下降的缘由。假设网络耗时过长，请使用“网络监视器”图确定导致性能瓶颈的网络问题性能测试之场景设计思想前段时间有幸收到珠海X 公司性能题目，呵呵，以下是对公司产品性能测试的总结。

38、个人认为有关性能测试场景问题，其实更佳着重于对性能测试目的讲究。验证测试是用于验证在特定的场景、时间、压力、环境和操作方式下系统能够正常的运 行，效劳器、应用系统和网络环境等软硬件设施还能否良好的支撑这些状况下用户的使用。验证性测试主要针对有明确的压力目标和预期结果，验证系统在这种压力下的各方面反映能 够到达预期结果。主要分以下几种：压力测试：系统顶峰期使用人数，验证各事务在最大并发数通过顶峰期人数换算 下事务响应时间能够到达客户要求。系统各性能指标在这种压力下是否还在正常数值之内。系统是否会因这样的压力导致不良反响如：宕机、应用特别中止等。Ramp Up 增量设计：如并发用户为 75 人，系

39、统注册用户为 1500 人，以 57作为并发用户参考值。一般以每 15s 加载 5 人的方式进展增压设计，该数值主要参考测试加压机性能，建议 Run 几次。以事务通过率与错误率衡量实际加载方式。Ramp Up 增量设计目标： 查找已增量方式加压系统性能瓶颈位置，抓住消灭的性能拐点时机，一般常用参考Hits 点击率与吞吐量、CPU、内存使用状况综合推断。模拟顶峰期使用人数，如早晨的登录，下班后的退出，工资发送时的消息系统等。另一种极限模拟方式，可视为在峰值压力状况下同时点击事务操作的系统极限操作指标。加压方式不变，在各脚本领务点中设置同集合点名称如： lr_rendzvous(“same“; 在

40、场景设计中，使用事务点集合策略。以同时到达集合点百分率为标准，同时释放全部正在Run 的 Vuser。稳定性测试：系统顶峰期使用人数、各事务操作频率等。设计综合测试场景，测试时将每个场景依据肯定人数比率一起运行，模拟用户使用数年的状况。并监控在测试中，系统各性能指标在这种压力下是否能保持正常数值。事务响应时间是否会消灭波动或随测试时间增涨而增加。系统是否会在测试期间内发生如宕机、应用中止等特别状况。依据上述测试中，各事务条件下消灭性能拐点的位置，已确定稳定性测试并发用户人数。仍旧依据实际测试效劳器加压机、应用效劳器、数据效劳器三方性能，估算最终并发用户人数。场景设计思想：从稳定性测试场景的设计

41、意义，应分多种状况考虑：针对同一个场景为例，以下以公文附件上传为例简要分析场景设计思想：1） 场景一：已压力测试环境下性能拐点的并发用户为设计测试场景，目的验证极限压力状况下测试效劳器各性能指标。2） 场景二：依据压力测试环境中 CPU、内存等指标选取效劳器所能承受最大压力的50%来确定并发用户数。测试方法：承受 1)Ramp Up-Load all Vusers simultaneously 2)Duration-Run Indefinitely3)在 Sechedule-勾选 Initalize all Vusers before Run容错性测试：通过模拟一些非正常状况如：效劳器突然断电

42、、网络时断时续、效劳器硬盘空间缺乏等，验证系统在发生这些状况时是否能够有自动处理机制以保障系统的正常 运行或恢复运行措施。如有 HA自动容灾系统，还可以特地针对这些自动保护系统进展另外的测试。验证其能否有效触发保护措施。问题排解性测试：通过原有案例或阅历推断，针对系统中曾经发生问题或疑心存在隐患的模块进展验证测试。验证这些模块是否还会发生同样的性能问题。如：上传附件模块的内存泄露问题、地址本模块优化、开启Tivoli 性能监控对 OA 系统性能的影响等等。测评测试是用于猎取系统的关键性能指标点，而进展的相关测试。主要是针对预先没有明确的预期测试结果，而是要通过测试猎取在特定压力场景下的性能指标

43、如：事务响应时间、最大并发用户数等。评测事务交易时间：为猎取某事务在特定压力下的响应时间而进展的测试活动。通过模拟客户顶峰期的各压力值或预期所能承受的压力值，猎取事务在这种压力下的响应时 间。评测事务最大并发用户数：为猎取某事务在特定系统环境下所能承受的最大并发用户数 而进展的测试活动。通过模拟真实环境或直接承受真实环境，评测在这种环境下事务所能承 受的最大并发用户数。判定标准阈值需预先定义如响应时间，CPU 占用率，内存占用率， 已消灭点击率峰值，已消灭吞吐量峰值等。评测系统最大并发用户数：为猎取整个系统所能够承受的最大并发用户数而进展的的测 试活动。通过预先分析工程各主要模块的使用比率和频

44、率，定义各事务在综合场景中所占的 比率，以比率方式安排各事务并发用户数。模拟真实环境或直接承受真实环境，评测在这种 环境下系统所能承受的最大并发用户数。判定标准阀值预先定义如响应时间，CPU 占用率， 内存占用率，已消灭点击率峰值，已消灭吞吐量峰值等。取值标准以木桶法则为准并发数最小的事务为整个系统的并发数。评测不同数据库数据量对性能的影响：针对不同数据库数据量的测试，将测试结果进展 比照，分析觉察数据库中各表的数据量对事务性能的影响。得以预先推断系统长时间运行后， 或某些模块客户要求数据量较大时可能存在的隐患。问题定位测试在通过以上测试或用户实际操作已经觉察系统中的性能问题或疑心已存 在性能问题。需通过响应的测试场景重现问题或定义问题。如有可能，可以直接找出引起性能问题所在的代码或模块。该类测试主要还是通过测试出问题的脚本场景，并可以增加觉察和检测的工具，如开启Tivoli 性能监控、开启HeapDump 输出、Linux 资源监控命令等。并在场景运行过程中辅以手工测试。