[转载]
2.5整体规划
性能测试规划的重点是时间、质量、成本等项目管理要素。
2.5.1常见的性能测试工具
Loadrunner:是一种预测系统行为和性能的负载测试工具,目前很多公司执行性能测试的首选工具.
Rational performance: rational系列产品之一,功能非常强大,和loadrunner竞争比较激烈.
QALoad:compu ware公司的产品
Webload:专门用于web性能测试的工具
WAS:全称是Microsoft Web Application Stress Tool,微软提供的免费性能测试工具
Apache JMeter :开源的性能测试工具
openSTA:开源的性能测试工具
2.5.2测试结果记录规范管理
测试结果数据是分析系统瓶颈的主要依据,大量的测试结果文件要进行规范管理,统一文件的命名规范.例如:2007-1-12-dbtest-oracleserver-50-once
2.5.3测试环境管理与维护
执行性能测试尽量不要破坏用户环境,而且要预先制定相应的备份/恢复策略,以便系统发生意外时可以恢复到测试前的状态.
性能测试很有可能产生大量的垃圾数据,消除垃圾数据是测试结事后首当其冲的工作
测试时还要监控测试机的使用情况,除非保证场景消耗的资源不会超出测试机的负载能力,否则就应该认真监控测试机,因为一旦测试机发生瓶颈,所有测试结果均无实际意义.
2.5.4测试分析与经验总结
主要关注性能测试规划与设计、测试用例设计、测试工具与技术、性能分析等方面。
性能测试用例的设计分析：可用性、执行效果、执行时间、还应该分析用例的设计方法、设计思路等。
对于瓶颈：应用系统、数据库、web服务器等有时会因配置参数不正确导致系统性能不高，可积累解决这方面问题的经验，以便于以后快速解决问题。
1．随着压力的加大，吞吐率的曲线在增加到一定的时候，出现变化缓慢，甚至平坦的状态，很有可能标明网络出现带宽瓶颈。类似地，当压力加大时，点击率/TPS曲线出现变化缓慢或平坦的趋势，很有可能服务器开始出现瓶颈。
2．吞吐率与TPS具有很强的关联性：如果随着压力的加大，吞吐率和TPS的变化呈大体一致的趋势，即一起增加，说明在测试的压力下，系统没有出现显著的性能瓶颈。
3.1性能分析的步骤
1．首先从响应时间做为分析性能的起点。查看响应时间以判断是否满足用户对性能的期望。
2．考察系统的瓶颈是在网络环节还是在服务器环节。
针对服务器分析主要涉及应用程序、web服务器、数据库服务器、操作系统等。
首先应该分析业务或者用户事务的响应时间，根据测试结果来分析哪些业务真正变慢了，然后分析web资源的处理情况，最后对页面组成元素的响应时间进行分解。
3.1.1用户事务分析
1．查看结果综述图：查看事务的平均响应时间，以及事务的通过率
2．查看事务综述图和事务平均响应时间分析图：查看事务通过和失败的数值，来判断是程序算法出现问题还是服务器存在内存泄漏现象。
3．每秒通过事务数分析图：可确定系统在任何给定时刻的实际事务负载。当发现每秒通过的事务数减少时，就需要更加深入的分析，配合服务器监控数据一起分析。
4．事务性能摘要图：重点关注事务的平均和最大执行时间，如果其范围不在用户可以接受的时间范围内，需要进行原因分析。
5．事务响应时间与负载分析图：正在运行的虚拟用户和平均事务响应时间图的组合，通过它可以看出在任一时间点事务响应时间与用户数目的关系，从而掌握系统在用户并发方面的性能数据，为扩展应用系统提供参考，对分析具有渐变负载的测试场景比较有用。
6．事务响应时间分布情况分布图：预先定义相关事务可以接受的最小和最大事务响应时间，则可以使用此图确定服务器性能是否在可以接受的范围内。
3.1.2web资源分析
1．点击率图：每秒点击次数，即点击率图显示在场景运行过程中虚拟用户每秒向web服务器提交的HTTP请求数，可依据点击次数来评估虚拟用户产生的负载量，还可将其与”平均事务响应时间”图进行比较，以查看点击次数对事务性能产生的影响。
系统点击率下降通常表明服务器的响应速度在变慢。
2．吞吐率图：显示场景运行过程中服务器每秒的吞吐量。度量单位是字节，表示虚拟用户在任何给定的某一秒上从服务器获得的数据量。
点击率：每秒服务器处理的HTTP申请数
吞吐率：客户端每秒从服务器获得的总数据量。
每秒HTTP响应数图还能返回其他各类状态码信息，通过分析状态码，可以判断服务器在压力下的运行情况。
常见的http状态代码：从200-505均有其含义。如202：已经接受请求，但处理尚未完成。
3．每秒连接数图：显示在运行过程中每秒新建立的TCP/IP连接数。新连接数应该是每秒点击次数的一小部分，理想情况下，很多的HTTP请求都应该使用同一连接，而不是每个请求都新打开一个连接。
3.1.3网页元素细分
通过它可深入地分析网站上那些下载很慢的图像或中断的链接等有问题的元素。
页面分解总图：可显示某一具体事务在测试过程的响应情况，进而分析相关的事务运行是否正常。
1．下载时间细分：查看静态gif图片和动态的jsp代码。
2．组件细分（随时间变化）：可以选择不同的元素查看测试过程中其下载时间的变化曲线。适用于需要在客户端下载控制较多的页面，通过分析控件的响应时间，很容易就能发现哪些控件不稳定或者比较耗时。
3．下载时间细分（随时间变化）：查看jsp页面主要时间花在如receive,first buffer,connection等。
下载时间细分：宏观，整个测试过程页面元素响应时间的统计分析结果
下载时间细分（随时间变化）：微观，显示场景运行过程中每一秒内页面元素响应时间的统计结果。
4．第一次缓冲时间细分（随时间变化）：可查看页面运行时间主要花在服务器还是网络传输上。
服务器分析通常从web服务器和数据库服务器入手。
服务器分析的第一步，分析测试工具对web服务器和数据库服务器相关计数器的监控结果，然后确定在压力下是web服务较慢还是数据处理较慢。
Web服务较慢：查看web服务器的各种参数配置，如最大连接数、最大内存等是否设置的合理。查看内存、CPU、硬盘
数据处理较慢：一般是数据库配置发生问题，或是硬件资源配置太低。如oracle,要查看内存配置、运行模式等信息。
4.1数据库调优策略
1．修改sql语句中影响速度的写法
2．增加或者修改索引
针对表间的连接创建索引
针对查找建立索引
使用索引时，遵守以下原则可达到更好的效果
第一：一般建立在多个字段上的一个组合索引优于针对单个字段建立的多个索引，根据值匹配条件创建的索引也需要遵循同样的原则：
第二：创建组合索引时，精确匹配的字段放在非精确匹配字段前面，取值范围大的字段放在取值范围小的字段前面，可以提高查询速度，如身份证字段应该放在性别字段前面。
第三：索引并不是越多越好，当数据库记录较多时，意味着数据库要付出的开销将会很大，从而降低数据库其他方面的性能。
3．调整相应数据库的系统参数（系统投产生的调优，通常由厂商的配合完成）
一般检查项为：复杂语句支持，大对象功能支持，并发查询性能，吞吐量，数据迁移（导出备份）。
4.2weblogic/oracle相关分析
主要监控：%processor,
Avalable Mbytes(空闲内存), JVM内存，connection Delay Time（数据库连接池建立数据库连接的时间）
Oracle运行平台AIX监控（unix），cpu的使用率（cpu utilization），disk traltic(磁盘负载)，page-in,page-out
rate的使用情况。
以及oracle本身相关报告：相看缓冲区调整缓存，应用程序的i/o操作。
4.3性能测试用例设计要基于用户语言
即满足用户要求又相对全面的性能测试用例，设计时要基于“用户语言”，易于用户理解的、大纲形式的测试用例，这样涉及的技术语言不多，用户很容易看懂。这样使得用户在现场测试阶段能够提出很多改进建议，并同意对用例进行调整（删减近一半的用例），可以为后期执行测试节约成本。
性能测试实施的特点之一就是不会严格按照测试用例来执行，通常是在项目中对用户进行一定的调整，然后再去执行，对于测试用例进行调整，删除、修改、增加，这是很正常的，基本成本来进行设计和执行。
