性能测试规划建议书

性能测试规划建议书响应时间我把“响应时间”的概念确定为“对恳求作出响应所需要的时间”，把响应时间作为“呈现时间”和“系统响应时间”两个局部。其中“呈现时间”取决于数据在被客户端收到响应数据后呈现页面所消耗的时间、而“响应时间”指J2EE应用效劳器从恳求发出开头到客户端承受到数据所消耗的时间。性能测试一般不关注“呈现时间”，由于呈现时间很大程度上取决于客户端的表现。在这里我们没有使用很多性能测试定义中的概念——“系统响应时间”定义为“应用系发出开头到客户端接收到最终一个字节数据所消耗的时间”，没有使用这种标准的缘由是可以使用一些编程技巧在数据尚未完全接收完成时进展呈现来削减用户感受到的响应时间对于HNDLZCGLXT 的这个工程中我们针对C/S系统承受前者标准，对于B/S我们照旧承受后一种标准。并发用户数我把“并发用户数”与“同时在线数”进展区分对待，我的“并发用户数”的标准是：“并发用户数”前，必需〔必要〕先对用户的业务进展分解、分析出典型的业务场景〔也就是用户最常使用、最关注的业务操作〕，然后基于场景承受某些方法〔有多种计算并发用户数的数学模型与公式〕获得“并发用户数”。这样做的缘由是：假设一个应用系统、最顶峰有500500人却不是并发用户数、由于假设在一个时间点上、有50%的人在填写简单的表格〔填写表格动作对效劳“提交”动作的时候才会对效劳器系统构成压力40%的〔、还10%的人挂在线上，没有任何操作在发呆：〕〔没有对效劳器构成压力的动作〕。因40%的人真正对效劳器产生了压力，从这里例子可以看出、并发用户数关心的是不但是业务并发用户数、还取决于业务规律、业务场景。因此我们需要本文第六局部4、5、6。吞吐量我把吞吐量定义为“单位时间内系统处理的客户恳求的数量”，直接表达软件系统的性能承载力量，对于交互式应用系统来说、吞吐量反映的是效劳器承受的压力、在容量规划的测试中、吞吐量是一个重要指标、它不但反映在中间件、数据库上、更加表达在硬件上。我们在以下方面利用这个指标：J2EE应用系统的连接池、数据库事务发生频率、事务发生次数。用来帮助分析性能瓶颈、参照本文其次局部总的RBI方法。性能计数器性能计数器式描述效劳器或操作系统性能的一些数据指针例如对WINDOWS 来说使用内存数、CPU使用率、进程时间等都是常见的计数器。web效劳器计数器、EJB2JSFJMS性能计数器。找到这些指针是使用性能计数器的第一步、关键是找到性能瓶颈、确定系统阀值、供给优化建议才是性能计数器使用的关键。性能计数器简单而繁多、与代码上下文环境、系统配置状况、系统架构、开发方式、使用到的标准实现、工具、类库版本都有严密的联系、在此不作赘述。思考时间我把思考时间确定为“休眠时间”。从业务系统的角度来说，这个时间指的是用户在惊醒操作时、每个恳求之间的时间间隔、从自动化测试的角度来说、要真实的测试仿真用户操作、就必需在测试脚本中让各个操作之间等待一段时间、表达在脚本上就是在操作之间放置一个Think的函数，表达为脚本中两个恳求语句之间的间隔时间、不同的测试工具供给了不同的函数或方法来实现思考时间、比方HPLoadRuner和IBMRationalPerformanceTest方式就完全不同。性能测试方法论SEI负载测试打算过程目标：产生一个清楚、好理解、可验证的负载测试打算6个区域：目标、用户、用例、生产环境、测试环境、测试场景工具都支持。需有文檔协作RBI方法目标：快速识别性能瓶颈内容：重点测试“吞吐量”指标，由于RBI80%的系统性能瓶颈由吞吐量造成。依据网络、硬件、数据库、应用效劳器、代码的挨次自上而下分析性能、HP、、有特地的工具实现RBI。性能下降曲线分析法下文。确定性能阀值。内容：通过单用户区域、性能平坦区域、压力区域、性能拐点进展监控和分析。工具都支持。IBM报表功能更强。HP〔LoadRuner〕性能分析法特点：侧重于该厂商的性能分析方法、主要表达在需求收集、VU脚本。缺点：没有对测试打算阶段、测试设计时间的具体行为、方法、目的进展描述。方法局LoadRuner产品的特性上。不能通用。IBRationalP软件测试方法特点：软件产品生命周期RUP的实现、侧重于迭代测试、宽广的方法论。可适合任意测试环境及方法、工具。缺点：需要依据测试环境进展剪裁、难以把握、但把握后格外成熟、高质量。工具：涉及到IBMRational测试环境的全部软件、功能强大。PTGM性能测试模型内容：一个格外适合行业用户〔电力、金融、政务、制造〕的性能测试过程模型。标准测试上下文方面很优秀。包括以下环节：前期预备、工具引入、测试打算、测试设计与开发、测试执行与治理、测试分析。工具：可以使用任意商业工具全部署测试流程、不限于任何厂商工具的局限、也可以OpenSource倾向使用多个产品的整合、综合使用、扬长避短。性能测试方法性能测试性能测试方法通过模拟生产运行的业务压力气和使用场景组合测试性能是否能够满足需要。具备三个特点：这种方法的目的是验证系统是否具有系统宣称具有的力量。这种方法需要事先了解被测试系统典型场景、并确定性能目标。这种方法要求在已确定的环境下运行使用IBMRationalPerformancetercuryLoadRunOpenSTAApachebJmete、QALoad、TagUniJavaTestRuner负载测试负载测试用来测定系统饱和状态、确定阀值。其特点有：到如“10秒”，“效劳器平均CPU65%”等指标。这种性能测试方法需要在给定的测试环境下进展，通常也需要考虑被测系统的业务压力气和典型场景、另外HPMercuryLoadRuner须选择典型场景。

使用该方法进展“加压”的时候必这种性能测试方法一般用来了解系统的性能容量，或者是协作性能调优的时候来使用。特别是该工程的WeblogicServrOracl数据库的性能调优。压力测试压力测试方法测试目标系统在肯定饱和状态下，例如CPU、内存等在饱和状态下、系统能够处理的session力量，以及系统是否会消灭错误。该方法需要在系统cache调优与pool优化方面着手。该方法具备以下特点：该方法的目的是检查系统处于压力状况下的，应用的表现。如增加VU数量、节是检验此时的应用表现，重点在于有无错误信息产生，系统对应用的响应时间等。该方法通过模拟负载在实现压力。这种模拟需要考虑的层面很多、首先、模拟必OracleIJVMGCConnPoo等。“什么样的平台定义一个多长的压力测试时间让其稳定运行才是科学的？”配置测试配置测试方式是指在测试前、测试中、测试后三个时间段通过对被测系统的软件硬件安排原则。它具备以下特点：该方法的目的是了解各个不同的因素对系统性能影响的程度、从而推断出最值得进展的调优操作。该方法不同于与“功能测试”中涉及到的“配置测试”。什么时候暂停、什么时候完毕才是运用这个方法的关键。同时也是HNDLZCGLXT考虑性能测试效劳供货商的关键。并发测试该方法通过仿真用户的并发访问，测试多用户环境并发访问同一个应用、同一个模块或者数据记录时系统是否存在死锁或者其他性能问题。该方法特点是：可以觉察应用系统的全局性性能问题。Compuware公司的DevPartneEJ-Technologe司的JProflQUEST公司的JProb工具等。并发测试一般关注的问题是：牢靠性测试〔80%~90%的使用率70%~90%环境下运行该应用系统。应用系统运行起来后，加载业务压力使应用系统资源到达90%。比方：该J2EE系统中设置的JDBC3027。应用系统运行起来后结合业务状况来设定一个运行时间。比方：电力资产系统要MTBF〔平均无故障时间〕10000小时、那么我们可以认定该系统的运行时间至“不行靠”。一般状况下J2EE90%~100%3天左右没有错误就可以认定该MTBF指标已经到达。失效恢复测试该方法是针对有HACMP等冗余备份和EdgeServerforJ2EE系统设计的。该方法考虑系统失效恢复的时间、用户受到多大程度、多大范围的影响，并将其量化。该方法有以下特点：一般的关键业务都会承受双机热备或负载均衡方式来实现。能不能使用”需要说明的是，对于HNDLZCGLXT的这个工程来说，负载均衡需要认真考虑其实现方式，这影响到性能的调优。可以考虑使用F5等硬件技术方式、也可以考虑使用IBMWebSphereEdgeServr商业版本的软件技术方式。否则单纯对EJB容器Server作集群没有意义。性能测试分析方法该局部着重于PTGM方法论力量验证力量验证一般承受这样的描述：“该系统是否能在A条件下具备B力量？”。这里强调以下内容：充分预备以下内容：硬设备、软件环境、网络条件、根底数据充分预备测试场景、典型的场景包括操作序列、并发用户数量条件、用例。该局部包括使用到上述测试方法：性能测试方法、牢靠性测试、压力测试、失效恢复测试规划性能试方法是：负载测试、配置测试、压力测试。性能调优一个标准的性能调优过程是：确定基准环境、基准负载和基准性能指针。调整系统运行环境和实现方法，执行测试。记录测试结果、进展分析在J2EE性能测试中有很多常见的错误J2EE/EJB技术上的应用，在效劳启动的时候，没有留意到测试之前首先进展一段时间的预热。这是由于JAVA语t术特性打算的，这种技术允许第一次运行应用的时候将字节码